ScyllaDB в бою: архитектурный кейс замены Cassandra и прирост производительности в 10 раз

В мире распределенных баз данных, где каждый миллисекунд задержки и каждый узел кластера на счету, история миграции с Apache Cassandra на ScyllaDB одного из крупных телеком-провайдеров стала хрестоматийным примером. Компания столкнулась с классическими проблемами масштабирования: растущая латентность, сложность управления джиттером (задержками) в больших кластерах Cassandra и высокие операционные затраты на поддержку сотен узлов. Пиковая нагрузка достигала миллиона операций в секунду, и существующая инфраструктура начала давать сбои.

Архитектурная суть проблемы заключалась в фундаментальном различии моделей исполнения. Apache Cassandra, написанная на Java, использует модель на основе виртуальной машины Java (JVM) и управляемых потоков (threads). При высокой нагрузке это приводит к сложному переключению контекста, накладным расходам на сборку мусора (GC pauses), которые могут останавливать все операции на сотни миллисекунд. В телекоме, где системы биллинга и сессионного управления должны отвечать в реальном времени, такие паузы были неприемлемы.

Решение пришло в виде ScyllaDB — базы данных, написанной на C++ и реализующей модель шардирования на уровне процессора (CPU sharding). Вместо того чтобы заставлять все потоки бороться за доступ к общим структурам данных, ScyllaDB использует архитектуру «share-nothing» на каждом ядре. Каждое физическое ядро процессора получает свой независимый набор данных, свой планировщик ввода-вывода и свою очередь событий. Это полностью исключает блокировки (locks) и накладные расходы на синхронизацию между ядрами.

Процесс миграции был поэтапным. Сначала был развернут параллельный кластер ScyllaDB, и данные начали реплицироваться в обе системы с помощью Apache Kafka, выступавшего в роли шины событий. Это позволило провести всестороннее тестирование под нагрузкой без риска для продакшена. Ключевым этапом была настройка совместимого с Cassandra протокола CQL (Cassandra Query Language) в ScyllaDB, что позволило переключить приложения практически без изменения кода — потребовалась лишь правка конфигурации пулов соединений.

Результаты превзошли ожидания. После полного переключения трафика средняя задержка (p99 latency) снизилась с 25-30 миллисекунд до 2-3 миллисекунд — десятикратный прирост. Пропускная способность на том же железе увеличилась в 7-8 раз. Но самое главное — исчезли «проседания» производительности из-за сборки мусора. Графики latency стали предсказуемо ровными даже на пиковых нагрузках. Операционные затраты упали кардинально: вместо кластера из 300 узлов Cassandra потребовалось всего 42 узла ScyllaDB для обслуживания той же нагрузки с запасом.

Этот кейс наглядно демонстрирует, как фундаментальный выбор архитектуры — асинхронная, неблокирующая модель на уровне ядра против управляемой модели на уровне потоков — определяет потолок производительности и предсказуемость распределенной системы в условиях экстремальных нагрузок. ScyllaDB не просто «более быстрая Cassandra», это иной подход к обработке данных, где детерминированность и эффективность использования ресурсов железа стоят во главе угла.