Как сэкономить на масштабировании, переехав с Cassandra на Scylla DB

Базы данных и системы хранения

СУБД: графовые, объектные и другие

Миграции данных
Базы данных / другое
Machine Learning
ML

Доклад принят в программу конференции

Мнение Программного комитета о докладе

Целевая аудитория

System Engineer, ML-разработчики, системные администраторы.

Тезисы

Наш сервис вычисляет инференс моделей машинного обучения в транзакционном режиме. Как БД для наших сервисов мы использовали Cassandra:12 нод по 10 ядер и 32 Гб памяти. Немного цифр: среднее число запросов 600 RPS, в пиковых нагрузках — 800 RPS, ежедневная загрузка данных 500 Гб, нагрузка на базу от 50 000 до 100 000 RPS, желаемое время ответа БД меньше 100мс.

В начале 2020 мы столкнулись с пределами масштабирования: перестало хватать кластеров, появились всплески latency (из-за garbage collection), фантомные данные, увеличилось время загрузки (11-12 часов). У нас был выбор: масштабироваться за счет железа, но с каждым разом это будет все дороже и есть предел, или мигрировать. Мы выбрали миграцию базы с Cassandra на Scylla DB и думали, что мигрируем за пару спринтов...

Расскажем, как инсталлировали кластеры, делали реплики, настраивали мониторинг и где возникли проблемы из-за которых все растянулось на 4 месяца.

System Engineer платформы ML и облачных решений.

OneFactor

OneFactor разрабатывает сервисы искусственного интеллекта на данных мобильных операторов для банков, ритейлеров, телекома, платежных систем и страховых компаний.

Видео