Почему ScyllaDB обгоняет Cassandra на том же железе и где у этого цена

Две базы говорят на одном языке запросов, хранят данные в одном формате и строят кластер по одной схеме. На бумаге ScyllaDB подают как ускоренную Cassandra, переписанную с Java на C++. Но за лозунгом о кратном превосходстве скрывается архитектурный выбор, реальные истории миграций гигантов и неудобные нюансы, о которых маркетинг помалкивает. Разберём честно, откуда берётся разница в скорости на одинаковом железе, что показывают боевые внедрения и почему в 2025 году выбор между этими базами перестал быть очевидным.

Откуда растёт разница в производительности

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

Cassandra написана на Java и работает поверх виртуальной машины Java. Это даёт переносимость и зрелую экосистему, но платит за это двумя вещами. Первая это паузы сборщика мусора, которые периодически замораживают работу и портят хвостовые задержки. Вторая это неоптимальное управление потоками и в целом относительно низкая утилизация железа из-за ограничений виртуальной машины. Cassandra исторически оптимизирована под широкое распределение по множеству мелких узлов, и её сборщики мусора заточены именно под такой сценарий.

ScyllaDB написана на C++ поверх асинхронного фреймворка, и её главное архитектурное отличие это шардирование на ядро процессора. Вместо шардирования по узлу, как у Cassandra, каждое ядро обслуживает свой собственный кусок данных и свои запросы, минимизируя накладные расходы на блокировки и переключения между потоками. Архитектура без разделяемого состояния позволяет задействовать сервер любого размера, хоть на сто, хоть на тысячу ядер, и доходить до полной загрузки процессора. Зерокопирование, собственное управление памятью и планировщики ввода-вывода и процессора с разными приоритетами дополняют картину.

Что показывают реальные сравнения на железе

Самый показательный эксперимент это сравнение, где четыре узла ScyllaDB поставили против сорока узлов Cassandra. На первый взгляд сравнение яблок с апельсинами: четыре машины против сорока совсем других. Но смысл был именно в этом. Из-за шардирования на ядро и собственного управления памятью ScyllaDB умеет выжимать мощное железо, тогда как Cassandra с её сборщиками мусора оптимизирована под множество мелких узлов. Вопрос стоял так: могут ли оба решения показать сопоставимую производительность, при том что Cassandra требует примерно в два с половиной раза больше железа за те же в два с половиной раза большие деньги. По сути на кону стояло сокращение административной нагрузки: мог бы инженер обслуживать четыре сервера вместо сорока.

Свежие сравнения масштабирования показывают, что ScyllaDB держит примерно четырёхкратную пропускную способность Cassandra при стабильно более низких хвостовых задержках на сопоставимой инфраструктуре. Иначе говоря, сопоставимую с Cassandra производительность ScyllaDB выдаёт на заметно меньшем кластере. Шард-ориентированные драйверы добавляют ещё пятнадцать-двадцать пять процентов прироста. Реальные миграции подтверждают цифры. Один билионный каталог товаров получил шестикратный рост производительности, ужав кластер на семьдесят процентов. Сеть фанатских магазинов заменила пятьдесят пять узлов Cassandra всего шестью узлами ScyllaDB. А крупный мессенджер перевёл триллионы сообщений с Cassandra на ScyllaDB ради предсказуемых хвостовых задержек.

Где Cassandra держится наравне или впереди

Честность требует показать и обратную сторону, потому что картина не односторонняя. При низкой нагрузке Cassandra иногда слегка обходит ScyllaDB. Причина любопытна: ScyllaDB в простое автоматически запускает больше уплотнений, а её планировщик с тактом в полмиллисекунды по умолчанию бьёт по хвостовой задержке. То есть преимущество ScyllaDB раскрывается под нагрузкой, а не на холостом ходу.

По части функций Cassandra версии 5.0 заметно подтянулась. Она принесла переработанный движок хранения, повышающий эффективность записи и снижающий дисковый ввод-вывод. Появились индексы, привязанные к хранилищу, позволяющие индексировать неключевые колонки, булеву логику, векторные представления для поисковых нагрузок и диапазонные сканирования. Раньше это было слабым местом Cassandra, теперь разрыв сократился. Обе базы к этому моменту обзавелись и векторным поиском.

Есть и аргумент зрелости и сообщества. Cassandra старше, у неё больше пользовательская база и богаче экосистема, а кривая обучения, хоть и круче, опирается на огромный массив накопленных знаний. ScyllaDB как более молодой проект имеет сообщество поменьше, хотя оно быстро растёт и пользуется обширной экосистемой Cassandra.

Почему слова о полной взаимозаменяемости не вполне правда

Лозунг о беспроблемной замене один в один требует оговорок. На практике ScyllaDB накладывает ряд ограничений на запросы в части агрегаций, запросов вхождения и многоколоночных запросов, и в ней встречаются базовые расхождения с более зрелой Cassandra.

В одной реальной миграции команда столкнулась с конкретными проблемами. Функция суммирования давала сбой с колонками, чувствительными к регистру. Сочетание подсчёта с группировкой вело себя иначе, чем в Cassandra, при отсутствии совпадений. Многоколоночные ограничения работали только на префиксе ключа кластеризации. В итоге пришлось переписать множество репозиториев приложения. Правда, у этой вынужденной работы был и плюс: она дала повод заново взглянуть на неоптимизированные запросы, переосмыслить ключи партиционирования и порядок кластеризации. Миграцию при этом облегчают специальные инструменты переноса данных, способные читать из Cassandra и других источников и распределять перенос по узлам кластера обработки.

Почему лицензионный поворот изменил расклад в 2025 году

И вот ключевой сюжет, перевернувший очевидность выбора. ScyllaDB сменила лицензионную модель с открытой на доступную для исходного кода, введя ограничение, при котором бесплатное использование упирается в десять терабайт суммарных данных на всю организацию. Для тех, кто строит крупную распределённую инфраструктуру, это серьёзное последствие: всплывают вопросы долгосрочной масштабируемости, стоимости и контроля со стороны поставщика.

Этот поворот заново разжёг интерес к полностью открытым и общинно управляемым альтернативам. И именно Cassandra версии 5.0 выходит на роль такой альтернативы, сочетая подлинную открытость с производительностью и операционной стабильностью. Появились даже обратные миграции с ScyllaDB на Cassandra, где организации возвращаются ради открытости и снятия лимита на объём данных. Cassandra при этом эволюционировала и больше не несёт прежнего груза мучительной тонкой настройки. Так что в 2025 году выбор это не просто скорость против скорости, а ещё и компромисс между производительностью на единицу железа и открытостью без потолка по данным.

Как взвесить операционную сторону

Операционная нагрузка тоже разнится. ScyllaDB снижает её за счёт автонастройки планировщиков ввода-вывода и распределения памяти под доступные ресурсы, встроенного мониторинга и упрощённых механизмов восстановления. Cassandra исторически требовала ручной настройки и сильно зависела от поведения виртуальной машины Java, а её тонкая настройка была отдельным искусством, хотя версия 5.0 многое в этом упростила.

При выборе стоит честно ответить на несколько вопросов. Каков ожидаемый объём данных и не упрётся ли он в лицензионный лимит ScyllaDB. Насколько критичны предсказуемые хвостовые задержки под высокой нагрузкой, ведь именно там ScyllaDB раскрывается сильнее всего. Какова терпимость к переписыванию запросов при миграции. И насколько важна полная открытость и независимость от единственного поставщика. На каждый из этих вопросов ответ может склонить чашу в свою сторону.

Какой вывод из всего этого следует

Превосходство ScyllaDB на одном и том же железе реально и объясняется архитектурой: шардирование на ядро, нативный C++ без пауз сборщика мусора и собственные планировщики дают кратный выигрыш в пропускной способности и стабильные хвостовые задержки. Истории Discord, крупного каталога товаров и сети магазинов это подтверждают сжатием кластеров в разы. Для нагрузок, где важны предсказуемая низкая задержка и эффективность использования мощного железа, ScyllaDB остаётся крайне сильным выбором.

Но в 2025 году одной скорости уже недостаточно для решения. Cassandra версии 5.0 закрыла значительную часть прежнего отставания по функциям и избавилась от репутации базы, требующей бесконечной настройки, а главное, осталась полностью открытой. Лицензионный лимит ScyllaDB в десять терабайт превратил бывший очевидный выбор в осознанный компромисс. Тот, кто гонится за чистой производительностью на узлах и не упирается в объём, выберет ScyllaDB и не прогадает. А тот, для кого открытость, контроль и отсутствие потолка по данным важнее последних процентов скорости, всё чаще возвращается к зрелой и подросшей Cassandra. Правильного ответа на все случаи здесь нет, есть лишь честное взвешивание того, что для конкретного проекта стоит дороже.