Как мы сломали модель данных из-за TTL в Cassandra

В сфере искусственного интеллекта произошло заметное событие. pkokoshnikov 1 минуту назад Как мы сломали модель данных из-за TTL в Cassandra Средний 8 мин 14 Блог компании Т-Банк Базы данных * Высоконагруженные системы * Кейс Привет! Я Павел Кокошников, главный разработчик в контактных политиках Т-Банка. Расскажу про кейс с Cassandra.

Базу мы выбрали неслучайно: под наш профиль нагрузки, модель доступа и требования к TTL она подходила хорошо. Уже в работе обнаружилась одна особенность TTL, которую мы упустили на этапе проектирования. Из-за нее в полностью исправной базе появлялись логически битые строки.

Технические детали

В статье разберу, как была устроена модель данных, в чем оказалась проблема, какие варианты решения мы рассматривали и какое выбрали в итоге. Описание сервисаНаш сервис контактных политик решает, можно ли отправить клиенту новую коммуникацию. Для этого он поднимает историю событий клиента за последний месяц и прогоняет ее через набор правил.

Данных много: около 50 млн клиентов, до 100 событий на клиента в месяц, у каждого события может быть несколько обновлений статуса. Данные хранятся месяц, после чего удаляются по TTL. Под нагрузкой это примерно 3к RPS на запись и 10к RPS на чтение.

При этом чтение всей истории клиента и применение правил должны укладываться в 100 мс. Почему выбрали CassandraНа этапе выбора мы смотрели на Postgres и Cassandra — обе базы были доступны у нас как сервис. Основной вопрос: какая БД лучше переживет нашу нагрузку и дальнейший рост?

Отраслевые последствия

Сервис должен был выдерживать высокий поток чтения и записи, а через год мы ожидали минимум двукратный рост. Для Postgres это почти наверняка означало бы ручной шардинг со всей сопутствующей сложностью: маршрутизацией запросов, перераспределением данных и дополнительной логикой на стороне приложения. В нашем случае Cassandra выглядела более естественным выбором:основной запрос хорошо укладывался в чтение одной партиции;горизонтальное масштабирование для нее — штатный сценарий;TTL хорошо ложился на задачу хранения событий с ограниченным сроком жизни.

Мы выбрали Cassandra как более практичное решение. Модель данных, операции и схема таблицыДля каждого события храним:client_id — идентификатор клиента;id — идентификатор события;created — время создания;payload — набор атрибутов в JSON, примерно 1 KB;status — текущий статус обработки. По бизнес-требованиям нам нужно было реализовать четыре базовые операции:сохранить событие;обновить статус события;прочитать все события клиента вместе со статусами;автоматически удалить устаревшие данные по TTL.

В Cassandra схема проектируется от запросов. Самый важный запрос для нас — получить все события конкретного клиента. У него нагрузка около 10к RPS, и он должен читать порядка 100 событий быстро и предсказуемо.

Этот прогресс даёт важные сигналы о будущем отрасли, и технологический мир внимательно наблюдает.