Разбор Cassandra за 1 час

Apache Cassandra — это распределенная NoSQL база данных, созданная для управления огромными объемами данных на многих серверах без единой точки отказа. Ее ключевые преимущества — линейная масштабируемость, отказоустойчивость и высокая доступность. Если у вас есть час, чтобы понять ее суть, давайте сфокусируемся на фундаментальных концепциях, которые отличают Cassandra от реляционных и других NoSQL баз.

**Архитектура: Кольцо и отказоустойчивость (15 минут)**
Забудьте о мастере и подчиненных. Cassandra — это одноранговая (peer-to-peer) распределенная система. Узлы (серверы) организованы в логическое кольцо. Данные автоматически распределяются по всем узлам в кластере. Каждый узел отвечает за определенный диапазон данных. Ключевой параметр — `replication_factor` (RF), например, RF=3. Это означает, что каждая порция данных хранится на трех разных узлах для обеспечения отказоустойчивости. Если один или даже два узла выйдут из строя (при RF=3), данные останутся доступны для чтения и записи. Это основа высокой доступности.

**Модель данных: Не таблицы, а широкие столбцовые хранилища (15 минут)**
В Cassandra есть ключевое пространство (keyspace, аналог базы данных) и таблицы. Но сходство с SQL заканчивается быстро. Первичный ключ в Cassandra состоит из двух частей:

• **Partition Key:** Определяет, на каком узле (в какой партиции) будут храниться данные. Все строки с одинаковым partition key хранятся вместе на одном узле (и его репликах). Это критично для производительности.
• **Clustering Key(s):** Определяет порядок сортировки данных *внутри* одной партиции.

Пример: Таблица `messages` с первичным ключом `(user_id, message_timestamp)`. `user_id` — partition key. Это значит, что все сообщения одного пользователя физически лежат вместе, отсортированные по времени (`message_timestamp`). Запрос «получить последние 10 сообщений для user_id=123» будет невероятно быстрым, так как это чтение из одной последовательной партиции. Но запрос «получить последнее сообщение от всех пользователей» будет очень медленным, так как потребует сканирования всех партиций на всех узлах.

**Запись и чтение: Консистентность и координаторы (15 минут)**
При записи клиент соединяется с любым узлом кластера (координатором). Координатор на основе значения partition key определяет, на какие узлы-реплики нужно отправить данные. Запись происходит очень быстро, так как сначала данные пишутся в commit log (для долговечности), а затем в memory table (memtable). Позже memtable сбрасывается на диск в SSTable (неизменяемый файл). Удалений как таковых нет — ставится «надгробный камень» (tombstone).

Чтение работает похоже: координатор запрашивает данные у нужных реплик. Cassandra позволяет настраивать уровень консистентности (Consistency Level — CL) для каждой операции отдельно. Это компромисс между доступностью и консистентностью. Например:
*  `CL=ONE`: Ответит первая доступная реплика (быстро, но можно получить устаревшие данные).
*  `CL=QUORUM`: Ответит большинство реплик (например, 2 из 3 при RF=3). Гарантирует сильную консистентность для большинства сценариев.
*  `CL=ALL`: Ответят все реплики (самая сильная консистентность, но риск недоступности при падении узла).

**Когда использовать и когда не использовать (10 минут)**
Используйте Cassandra, если:
*  Вам нужна **масштабируемость записи** — добавление узлов линейно увеличивает производительность.
*  Требуется **высокая доступность** и отказоустойчивость.
*  Рабочая нагрузка предсказуема и основана на **запросах по partition key**.
*  Данные имеют временной характер или могут быть денормализованы (например, IoT-телеметрия, история сообщений чата, трекинг событий).

Избегайте Cassandra, если:
*  Вам нужны **сложные JOIN-запросы** или агрегации в реальном времени (это работа для Hadoop/Spark поверх Cassandra или других БД).
*  Требуются **сложные транзакции** (ACID).
*  Часты запросы, которые требуют **сканирования всей таблицы**.
*  Модель данных и паттерны доступа к ней не определены. **В Cassandra вы проектируете таблицы под конкретные запросы**, а не наоборот.

**Итог за час:** Cassandra — это не волшебная палочка, а мощный специализированный инструмент. Ее сила — в распределенном, отказоустойчивом хранении огромных объемов данных, когда производительность записи и доступность критичны. Понимание partition key, clustering key и уровней консистентности — это 80% успеха. Остальное — тонкая настройка под конкретную нагрузку.