Apache Cassandra — ширококолоночная (wide-column) NoSQL СУБД с peer-to-peer архитектурой. Все узлы кластера равноправны — нет single point of failure в виде мастер-ноды. Cassandra оптимизирована для очень высоких объёмов записи и чтения при географически распределённой инфраструктуре.
Как работает
Данные распределяются между узлами по consistent hashing: каждый узел отвечает за часть ключевого пространства (token ring). Запрос клиента обрабатывается любым узлом — он выступает координатором и перенаправляет запрос к нодам, хранящим нужные данные. Репликация настраивается через replication factor (RF): RF=3 означает, что каждая запись хранится на трёх узлах.
Модель согласованности по теореме CAP: Cassandra обеспечивает доступность (A) и устойчивость к разделению (P), жертвуя строгой согласованностью (C). Configurable consistency level: при записи/чтении можно указать QUORUM, ONE, ALL. QUORUM = большинство реплик, баланс между согласованностью и производительностью.
Данные организованы как keyspace → table → row с partition key и clustering columns. Запросы выполняются через CQL (Cassandra Query Language), синтаксически похожий на SQL, но с ограничениями: JOIN не поддерживаются, WHERE только по partition key.
История
Cassandra разработана в Facebook в 2007–2008 годах Авинашем Лакшманом и Прашантом Малликом для хранения данных «Inbox Search». В 2008 году Facebook открыла код. В 2010 году Cassandra стала проектом верхнего уровня Apache. Netflix, Apple (более 75 000 узлов в 2015), Instagram, Twitter — основные пользователи.
Связь с хостингом
Cassandra требует минимум 3 узлов для надёжной работы и значительных ресурсов: 8+ GB RAM на узел, SSD-диски. На стандартном виртуальном хостинге не применяется. Для разработки доступны Docker-образы. Managed Cassandra: Amazon Keyspaces, DataStax Astra. В нише интернет-магазинов и веб-хостинга Cassandra практически не используется — её ниша: IoT, логирование, тайм-серии с миллиардами строк.
Архитектура Cassandra
Cassandra — распределённая NoSQL БД без единой точки отказа (masterless peer-to-peer). Данные распределяются по токен-рингу: каждый узел отвечает за диапазон токенов. Консистентность настраивается: ANY, ONE, QUORUM, ALL. CAP-теорема: Cassandra жертвует Consistency ради Availability и Partition tolerance.
Запись и чтение в Cassandra
Запись: Commit Log → Memtable → SSTable (flush на диск). LSM-дерево: медленнее для чтения, быстро для записи. Compaction объединяет SSTables. Чтение: Bloom Filter (определяет наличие в SSTable) → Partition Key Cache → SSTable. Оптимален для write-heavy нагрузок.
Применение в хостинге
Cassandra выбирают для time-series данных (метрики, логи), IoT, рекомендательных систем. Минимальный кластер — 3 узла. На одном VPS Cassandra не имеет смысла — преимущества только в кластере. Управляемые решения: AWS Keyspaces (Cassandra-совместимый).
Cassandra Data Modeling
Cassandra требует проектирования схемы "from queries, not entities": таблица создаётся под конкретный запрос. Денормализация обязательна. Partition key определяет физическое расположение данных. Wide partition антипаттерн: partition > 100 МБ снижает производительность. Используйте ALLOW FILTERING только в разработке.
Инструменты управления Cassandra
nodetool — основной CLI: nodetool status, nodetool repair, nodetool compactionstats. cqlsh — CQL shell. DataStax DevCenter — GUI. Medusa — backup/restore для Cassandra в S3. Cassandra Reaper — автоматическое repair расписание.
Cassandra подходит для хранения временных рядов, логов и IoT-данных. В отличие от PostgreSQL и MySQL жертвует согласованностью ради доступности. Резервное копирование через nodetool snapshot. Мониторинг через Prometheus + JMX exporter.