Cassandra полезно понимать не как абстрактный NoSQL-класс, а как конкретную архитектурную ставку на доступность, линейный рост записи и проектирование от профиля доступа к данным.
В реальной системе эта глава помогает проектировать таблицы вокруг ключа партиционирования, кластеризующих столбцов и границ партиций, а также подбирать уровень консистентности под критичность операции.
На интервью и в архитектурных обсуждениях она даёт сильный язык для объяснения, почему Cassandra подходит нагрузкам с преобладанием записи и геораспределённым сценариям, но требует дисциплины на стороне чтения.
Практическая польза главы
Модель по запросам
Проектируйте таблицы от профиля доступа: ключ партиционирования, кластеризующие столбцы и границы партиций.
Настраиваемая консистентность
Согласовывайте уровень консистентности с критичностью операции, бюджетом задержек и требованиями продукта.
Операционный цикл
Планируйте компакцию, восстановление реплик, метки удаления и ёмкость как постоянный процесс, а не разовую настройку.
Нарратив на интервью
Показывайте Cassandra как выбор для нагрузок с преобладанием записи и геораспределённых систем с осознанными ограничениями чтения.
Источник
Apache Cassandra
История, архитектура и основные инженерные компромиссы Apache Cassandra.
Apache Cassandra — распределённая ширококолоночная СУБД, которая соединяет идеи Dynamo и Bigtable: равноправные узлы, кольцо токенов, репликацию и хранение, оптимизированное под быстрые записи. Её выбирают не как универсальную базу данных, а как осознанный компромисс в пользу доступности, горизонтального роста и заранее спроектированных чтений.
На первом уровне Cassandra — это с : данные распределяются по , а число копий задаёт .
При проектировании таблиц важны , и : Cassandra позволяет выбирать и для конкретной операции.
Внутри записи проходят через , и , а долгосрочная цена эксплуатации проявляется в и .
Что делает Cassandra особенной
Ширококолонная модель
Данные организованы в пространства ключей и таблицы, которые проектируют под заранее известные запросы.
Архитектура без ведущего узла
Все узлы равноправны, что устраняет единую точку отказа и повышает доступность.
AP и настраиваемая консистентность
Система делает ставку на доступность, а уровень консистентности выбирается отдельно для разных операций.
Ограничения и компромиссы
- Сложные соединения таблиц и разовые исследовательские запросы обычно требуют другого инструмента.
- Таблицы нужно проектировать от будущих чтений, а не от универсальной нормализованной модели.
- Лучше всего 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 теорема - Базовый контекст про компромиссы доступности и консистентности, на которых строится архитектура Cassandra.
- PACELC теорема - Расширяет модель компромиссов на штатный режим: задержку, консистентность и выбор уровня консистентности.
- Jepsen и модели консистентности - Как проверять реальные гарантии распределённых баз данных под сетевыми сбоями и разделениями сети.
- Key-Value Database - Практический разбор распределённого слоя ключ-значение с партиционированием и кворумом, близкий к классу задач Cassandra.