Cassandra
Cassandra — это распределённая система управления базами данных (СУБД) класса NoSQL, предназначенная для обработки больших объёмов данных в режиме реального времени с высокой доступностью, отказоустойчивостью и горизонтальной масштабируемостью. Относится к семейству ширококолоночных (wide-column store) баз данных, сочетающих модель хранения на основе семейств столбцов (column families) с архитектурой peer-to-peer без единой точки отказа.
История
Система была разработана в компании Facebook (организация Meta признана экстремистской и запрещена в РФ) для обеспечения функций поиска по входящим сообщениям (Inbox Search). В 2008 году код был открыт под лицензией Apache License 2.0 и передан в инкубатор Apache Software Foundation. В 2010 году проект получил статус Top-Level Project. Изначально Cassandra сочетала идеи из BigTable (Google) по модели хранения данных и Dynamo (Amazon) по архитектуре распределённости.
С 2010 года проект активно развивается сообществом и компаниями, включая DataStax, которая предоставляет коммерческую версию и поддержку. Ключевые версии: 1.0 (2011), 2.0 (2013), 3.0 (2015), 4.0 (2021). В версии 4.0 были внедрены виртуальные таблицы, улучшена работа с памятью и исправлены критические ошибки.
Архитектура и принципы
Peer-to-peer (децентрализация)
Cassandra не использует master-slave архитектуру. Все узлы (nodes) в кластере равноправны. Каждый узел может обрабатывать запросы на чтение и запись. Это устраняет единую точку отказа и упрощает масштабирование.
Распределённость и репликация
Данные автоматически распределяются по узлам кластера с использованием консистентного хеширования (consistent hashing). Каждая запись реплицируется на несколько узлов (фактор репликации задаётся администратором). Репликация обеспечивает отказоустойчивость: при выходе узла из строя данные остаются доступными на других узлах.
Gossip-протокол
Узлы обмениваются информацией о состоянии кластера с помощью протокола сплетен (gossip). Каждый узел периодически сообщает о себе и узнаёт о других узлах. Это позволяет кластеру динамически адаптироваться к изменениям топологии (добавление/удаление узлов) без централизованного управления.
Модель согласованности
Cassandra предлагает настраиваемую согласованность (tunable consistency). Пользователь может задать уровень согласованности для каждой операции чтения/записи (например, ONE, QUORUM, ALL). Это позволяет балансировать между задержкой и актуальностью данных в зависимости от требований приложения.
Модель данных
Ключевое пространство (Keyspace)
Аналог базы данных в реляционных СУБД. Определяет стратегию репликации (SimpleStrategy или NetworkTopologyStrategy) и фактор репликации.
Таблица (Table) / Семейство столбцов (Column Family)
Содержит строки (rows) и столбцы (columns). Каждая строка идентифицируется уникальным первичным ключом (primary key), который состоит из ключа раздела (partition key) и необязательных кластеризующих столбцов (clustering columns).
Ключ раздела (Partition Key)
Определяет, на каком узле будет храниться строка. Все строки с одинаковым ключом раздела хранятся на одном узле (или наборах узлов, если включена репликация).
Кластеризующие столбцы (Clustering Columns)
Определяют порядок сортировки строк внутри раздела. Например, можно хранить сообщения пользователя, отсортированные по времени.
Столбцы (Columns)
Cassandra поддерживает статические (определённые в схеме) и динамические столбцы. Значения могут быть любого поддерживаемого типа (текст, число, UUID, коллекции, пользовательские типы).
Ключевые особенности
Высокая доступность и отказоустойчивость
Благодаря децентрализованной архитектуре и репликации, Cassandra продолжает работать при выходе из строя отдельных узлов. Кластер может быть развёрнут на нескольких дата-центрах, обеспечивая географическую устойчивость.
Горизонтальная масштабируемость
Для увеличения пропускной способности достаточно добавить новые узлы в кластер. Данные автоматически перераспределяются (rebalancing). Максимальный размер кластера практически не ограничен (известны развёртывания на тысячи узлов).
Производительность записи
Cassandra оптимизирована для высоких нагрузок на запись. Записи сначала попадают в commit log (журнал предзаписи) и в memtable (структура в памяти), затем асинхронно сбрасываются на диск в SSTable (отсортированные таблицы на диске). Это позволяет достигать скорости записи до миллионов операций в секунду на кластер.
Гибкая модель данных
Поддержка динамических столбцов и коллекций (списки, множества, карты) позволяет хранить слабоструктурированные данные без необходимости жёсткой схемы.
Недостатки и ограничения
Ограниченные возможности запросов
Cassandra не поддерживает JOIN, подзапросы, агрегатные функции (в классическом понимании) и транзакции ACID (только легковесные транзакции на уровне одной строки). Запросы должны быть спроектированы под модель данных (query-first design).
Сложность администрирования
Настройка кластера, выбор стратегии репликации, настройка compaction и repair требуют высокой квалификации. Ошибки в схеме данных могут привести к снижению производительности.
Потребление ресурсов
Cassandra активно использует оперативную память и дисковое пространство. Для больших кластеров требуется тщательное планирование аппаратного обеспечения.
Отсутствие встроенных средств для аналитики
Cassandra не предназначена для сложных аналитических запросов. Для этой цели часто используется интеграция с Apache Spark или другими системами.
Применение
Cassandra используется в системах, где критичны высокая доступность, отказоустойчивость и способность обрабатывать большие объёмы данных в реальном времени. Типичные сценарии:
- Хранение временных рядов (метрики мониторинга, логи, данные IoT).
- Системы управления контентом (социальные сети, рекомендательные сервисы).
- Платформы электронной коммерции (корзины покупок, каталоги товаров).
- Телекоммуникационные системы (биллинг, управление подписками).
- Игровые платформы (хранение профилей пользователей, игровых данных).
Примеры использования
- Apple — использует Cassandra для хранения данных в iCloud.
- Netflix — применяет Cassandra для хранения истории просмотров и рекомендаций.
- Spotify — использует Cassandra для хранения плейлистов и метаданных.
- **Instagram (продукт Meta, признанной экстремистской и запрещённой в РФ)** (организация Meta признана экстремистской и запрещена в РФ) — использует Cassandra для хранения сообщений и ленты новостей.
- Uber — применяет Cassandra для хранения данных о поездках и местоположении.
Инструменты и экосистема
- CQL (Cassandra Query Language) — SQL-подобный язык запросов, упрощающий взаимодействие с базой данных.
- DataStax Enterprise — коммерческая версия с дополнительными функциями (аналитика, безопасность, управление).
- Apache Spark — интеграция для аналитической обработки данных.
- OpsCenter — инструмент мониторинга и управления кластером.
- cqlsh — командная строка для выполнения CQL-запросов.
Источники
- Apache Cassandra Documentation (официальная документация проекта).
- DataStax Academy (учебные материалы и руководства).
- «Cassandra: The Definitive Guide» by Eben Hewitt and Jeff Carpenter (O'Reilly Media).
- Официальные блоги и статьи разработчиков (Facebook, Netflix, Apple).
BFOmetr — база данных и аналитика по компаниям России.
На главную BFOmetr →