Apache Cassandra 6.0 вышла в alpha и на этот раз разговор не только про скорость, масштабирование и прочие дежурные добродетели распределённой базы. Куда важнее другое: часть работы, которую команды годами держали в приложениях, скриптах и операционных рутинах, теперь переезжает внутрь самой СУБД. Для тех, кто живёт с крупными кластерами и сложной бизнес-логикой, это новость не из серии «ещё шесть галочек в release notes», а вполне прикладной сдвиг.
Как пишет The New Stack, в центре релиза Apache Cassandra 6.0 шесть изменений: транзакции Accord, Transactional Cluster Metadata, автоматизированный repair, framework для ограничений на уровне схемы, словарное сжатие Zstandard и новый подход к compaction с курсорами. Общая идея у этого набора одна: Cassandra пытается меньше перекладывать на плечи команды то, что база данных давно должна была делать сама.
Меньше самодельной координации
Самая заметная история здесь — Accord. Это leaderless-протокол консенсуса, который приносит в Cassandra ACID-транзакции со strict serializable isolation для операций через несколько partition. Если убрать красивую терминологию, смысл простой: там, где разработчики раньше писали собственную координацию между несколькими ключами и сервисами, теперь появляется шанс отдать часть этой головной боли базе.
Для Cassandra это чувствительная тема. Система давно отлично чувствует себя в сценариях, где важны доступность, горизонтальное масштабирование и предсказуемая работа под большой нагрузкой. Но как только бизнес-операция расползается на несколько partition, начинается знакомый аттракцион: приложение само следит за порядком шагов, само разгребает частичные отказы, само пытается не испортить консистентность. Accord не обещает магически отменить всю прикладную логику, да и в текущем виде требует аккуратного проектирования схемы. Но сам факт, что Cassandra берёт на себя multi-partition transaction semantics, для многих команд важнее ещё одного процента в бенчмарке.
Не менее важное изменение, хотя и куда менее кликбейтное, — Transactional Cluster Metadata, или TCM. Раньше Cassandra в значительной степени полагалась на Gossip Protocol и eventual consistency для распространения метаданных по кластеру: membership, token ownership, schema changes и решения о размещении данных расходились по узлам со временем, без жёсткого порядка. В Cassandra 6.0 появляется Cluster Metadata Service с упорядоченным журналом изменений. Для операторов это означает более предсказуемые операции со схемой и топологией, а для бизнеса — меньше шансов получить весёлые сюрпризы в момент, когда кластер и так занят чем-то важным.
По сути, релиз бьёт по двум хроническим источникам расходов: самописной координации в приложении и ручной координации на стороне эксплуатации. И это, пожалуй, более зрелый ход, чем бесконечная гонка за новыми модными сценариями. Cassandra 5.0 в своё время добавляла, например, native vector indexing и storage-attached indexes, укрепляя позиции в AI-нагрузках. Apache Cassandra 6.0 выглядит иначе: она меньше пытается понравиться презентации для инвесторов и больше — людям, которым потом дежурить с этим кластером ночью.
Операторам тоже решили помочь
Третье крупное изменение — automated repair orchestration. Repair в Cassandra не факультативная опция, а базовая санитария: именно он выравнивает реплики и помогает не доводить eventual consistency до неприятных последствий. Проблема в том, что исторически repair часто требовал внешней оркестрации, расписаний, дисциплины и аккуратности. Иными словами, база честно говорила: «это критично, но организуете как-нибудь сами». В Cassandra 6.0 ремонт кластера встраивается в саму систему как штатный сервис. Поддерживаются full и incremental repair, появляются защитные механизмы, а сама процедура меньше зависит от того, не забыл ли кто-то обновить cron, Terraform или внутреннюю wiki трёхлетней давности.
Для разработчиков здесь есть и четвёртый пункт — constraints framework. Ограничения теперь можно описывать на уровне схемы и проверять при записи, а не только дублировать в каждом сервисе. The New Stack приводит характерные примеры: сравнения вроде > и <, проверки NOT NULL, длины, JSON и регулярных выражений. Идея очевидная, но полезная: если некорректные данные можно отфильтровать ближе к базе, не нужно размазывать один и тот же validation-код по микросервисам. Это не заменяет здравый смысл в приложении, но хотя бы убирает часть расхождений между «как задумано» и «что реально доезжает до кластера».
Пятый пункт — Zstandard dictionary compression для SSTable. Здесь релиз говорит уже на языке экономики инфраструктуры. Вместо только общего сжатия Cassandra сможет использовать заранее обученные словари для повторяющихся паттернов в данных. Смысл не в том, чтобы похвастаться новым алгоритмом, а в том, чтобы лучше сжимать предсказуемые наборы данных без безумия в сопровождении. Для операторов это означает новые задачи по жизненному циклу словарей и наблюдаемости, но выигрыш понятный: экономия на хранении и более аккуратная работа с большими объёмами данных.
Шестое изменение — cursor-based compaction. Compaction и без того один из самых важных фоновых процессов в Cassandra, а заодно один из тех, что любит съедать память и провоцировать лишнюю работу garbage collector. Новый low-allocation path переводит процесс в более потоковую модель с повторным использованием cursor-like readers и writers вместо постоянного создания временных объектов в памяти. Для пользователей это почти невидимая инженерная кухня, но именно такие штуки потом превращаются в более ровное поведение узлов под нагрузкой и меньшее количество разбирательств в стиле «почему кластер снова решил пожить своей жизнью».
Если смотреть на Apache Cassandra 6.0 без релизного пафоса, получается довольно взрослая картина. Проект не столько добавляет экзотические возможности, сколько чинит старый контракт с пользователем: меньше ручной координации, меньше самодельной автоматики, больше встроенных гарантий и предсказуемости. Открытый вопрос теперь не в том, хороши ли сами идеи, а в том, насколько быстро команды, привыкшие держать критичные механизмы снаружи, решатся вернуть их обратно в базу.