Cassandra полезно понимать не как абстрактный NoSQL-класс, а как конкретную архитектурную ставку на доступность, линейный рост записи и проектирование от профиля доступа к данным.
В реальной системе эта глава помогает проектировать таблицы вокруг ключа партиционирования, кластеризующих столбцов и границ партиций, а также подбирать уровень консистентности под критичность операции.
На интервью и в архитектурных обсуждениях она даёт сильный язык для объяснения, почему Cassandra подходит нагрузкам с преобладанием записи и геораспределённым сценариям, но требует дисциплины на стороне чтения.
Практическая польза главы
Модель по запросам
Проектируйте таблицы от профиля доступа: ключ партиционирования, кластеризующие столбцы и границы партиций.
Настраиваемая консистентность
Согласовывайте уровень консистентности с критичностью операции, бюджетом задержек и требованиями продукта.
Операционный цикл
Планируйте компакцию, восстановление реплик, метки удаления и ёмкость как постоянный процесс, а не разовую настройку.
Нарратив на интервью
Показывайте Cassandra как выбор для нагрузок с преобладанием записи и геораспределённых систем с осознанными ограничениями чтения.
Рамка выбора и редакторский фокус
Фокус главы
архитектуре без ведущего узла, настраиваемой консистентности и нагрузках с преобладанием записи
Профиль нагрузки
Смотрите на критичный пользовательский путь: транзакции, чтения по ключу, индексы, задержку 95-го и 99-го перцентилей и восстановление после отказа.
Когда выбирать
Глава должна отвечать, почему этот движок хорош именно для операционного контура, транзакционной обработки OLTP, кэша или модели с преобладанием записи.
Граница и риск
Нельзя обещать универсальность: каждая СУБД имеет цену в консистентности, миграциях, памяти, индексах или операционной дисциплине.
Связать дальше
Сравнивайте с фреймворком выбора СУБД, репликацией/шардингом и соседними операционными движками.
Источник
Apache Cassandra
История проекта, устройство кольца и компромиссы, на которые идут ради доступности и роста.
Apache Cassandra — распределённая ширококолоночная СУБД, которая соединяет идеи Dynamo и Bigtable: равноправные узлы, кольцо токенов, репликацию и хранение, оптимизированное под быстрые записи. Её выбирают не как универсальную базу данных, а как осознанный компромисс в пользу доступности, горизонтального роста и заранее спроектированных чтений.
На первом уровне Cassandra — это с : данные распределяются по , а число копий задаёт .
При проектировании таблиц важны , и : Cassandra позволяет выбирать и для конкретной операции.
Внутри записи проходят через , и , а долгосрочная цена эксплуатации проявляется в и .
Что делает Cassandra особенной
Ширококолонная модель
Данные раскладываются по пространствам ключей и таблицам. Схему проектируют от конкретных запросов: то, что не заложено заранее, потом достаётся дорого.
Архитектура без ведущего узла
Узлы равноправны — нет ведущего, отказ которого останавливает запись. Цена за это: отвечать за консистентность приходится на уровне запроса, а не схемы.
AP и настраиваемая консистентность
Cassandra жертвует строгой согласованностью ради доступности (модель AP). Уровень консистентности выбирают для каждой операции отдельно — критичную запись закрывают кворумом, фоновую читают слабее.
Ограничения и компромиссы
- Сложные соединения таблиц и разовые исследовательские запросы здесь упираются в стену — под них берут другой инструмент.
- Схему строят от будущих чтений; нормализованная модель «на все случаи» в Cassandra превращается в медленные запросы.
- На малых объёмах и при перевесе чтений выгода теряется — Cassandra окупается на больших данных и нагрузках с преобладанием записи.
Кольцо, токены и репликация
Кольцо узлов
Согласованное хеширование
Выберите ключ, чтобы увидеть его распределение по кольцу (RF=3):
Коэффициент репликации RF = 3
Каждый ключ хранится на трёх узлах: владельце диапазона и двух следующих репликах по кольцу.
Путь записи
- Клиент -> любой узел-координатор
- Координатор вычисляет токен ключа
- Токен выбирает владельца диапазона и RF-1 реплик
- Запись параллельно отправляется на нужные реплики
История: ключевые вехи
Facebook открывает код
Cassandra появилась внутри Facebook и в 2008 году стала открытым проектом.
Apache Incubator
Проект перешёл в Apache Incubator и начал развиваться как часть экосистемы Apache.
Проект верхнего уровня Apache
Apache Cassandra получила статус top-level project и стала самостоятельной базой для крупных внедрений.
1.0: первый стабильный мажорный релиз
Релиз 1.0 закрепил Cassandra как зрелую распределённую СУБД для промышленной эксплуатации.
2.0: легковесные транзакции и CQL
Появились легковесные транзакции на базе Paxos и заметные улучшения языка запросов CQL.
3.0: крупное обновление хранения
Внутренний слой хранения был серьёзно переработан, а поведение чтения и записи стало предсказуемее.
4.0: упор на стабильность
Релиз с фокусом на надёжность, предсказуемость и эксплуатационную зрелость.
5.0: индексы хранения и векторные сценарии
Новый мажорный релиз добавил индексы, привязанные к хранению, и возможности для поисковых и AI-нагрузок.
IBM и DataStax
IBM объявила о покупке DataStax, усилив корпоративный контур вокруг экосистемы Cassandra.
Архитектура Cassandra по слоям
Запрос идёт от клиента к координатору, дальше к репликам — и оседает в LSM-подобном хранении: журнал фиксации, таблица в памяти, таблицы хранения. На каждом слое свой компромисс между скоростью записи и стоимостью последующего чтения.
Архитектура кластера
Модель данных
DDL и DML: как проходит запрос
DDL меняет структуру — пространства ключей и таблицы; DML работает с самими данными. Маршруты у них разные, и ниже разобраны основные шаги для каждого типа запроса.
Как запрос проходит через Cassandra
Сравнение цепочки для DDL (структура) и DML (данные)
Активный шаг
1. Узел-координатор принимает запрос
Любой узел кластера может принять DML-запрос и стать координатором.
Работа с данными
- DML работает с данными и индексами, не меняя схему.
- Путь записи оптимизирован для высокой скорости добавления данных.
- Уровень консистентности определяет, сколько реплик подтверждает операцию.
Почему Cassandra выбирают
- Линейный рост: добавили узлы — пропорционально выросла ёмкость и пропускная способность.
- Нет единой точки отказа, поэтому потеря узла не роняет запись.
- Запись остаётся быстрой за счёт LSM-подобной модели хранения.
- Уровень консистентности подбирают под критичность операции, а не фиксируют для всей базы.
Связанные главы
- Фреймворк выбора СУБД - Как определить, когда Cassandra подходит для распределённой нагрузки с преобладанием записи, а когда лучше выбрать другой класс хранилища.
- Репликация и шардинг - Практические решения для размещения реплик, балансировки нагрузки и управления отказами в распределённом слое данных.
- CAP теорема - Откуда берётся выбор между доступностью и консистентностью — теорема CAP объясняет, почему Cassandra встаёт на сторону AP.
- PACELC теорема - Расширяет модель компромиссов на штатный режим: задержку, консистентность и выбор уровня консистентности.
- Jepsen и модели консистентности - Настраиваемая консистентность — это обещание; здесь его проверяют под сетевыми сбоями и разделениями сети, чтобы понять, что Cassandra реально гарантирует.
- Key-Value Database - Практический разбор распределённого слоя ключ-значение с партиционированием и кворумом, близкий к классу задач Cassandra.