Apache Cassandra

Apache Cassandra — это распределённая нереляционная система управления базами данных (NoSQL), спроектированная для обработки больших объёмов структурированных данных на множестве стандартных серверов с обеспечением высокой отказоустойчивости и отсутствия единой точки отказа. Cassandra сочетает модель данных на основе семейств столбцов (column-family) с архитектурой, вдохновлённой Amazon Dynamo и Google Bigtable, и предоставляет линейную масштабируемость при записи и чтении.

История

Происхождение (Facebook, 2007–2008)

Система была разработана в недрах социальной сети Facebook (продукт Meta, признанной экстремистской и запрещённой в РФ) для решения задачи полнотекстового поиска в папке «Входящие» (Inbox Search). Инженеры Авинаш Лакшман (Avinash Lakshman) и Прашант Малик (Prashant Malik) создали прототип, который сочетал модель распределённого хранения Amazon Dynamo (децентрализованное кольцо, без единой точки отказа) с моделью данных Google Bigtable (семейства столбцов и разреженные строки). В июле 2008 года система была опубликована как open-source проект на платформе Google Code.

Переход в Apache Software Foundation (2009)

В марте 2009 года Facebook передала проект в инкубатор Apache Software Foundation. К этому моменту Cassandra уже использовалась внутри Facebook для нескольких сервисов, включая поиск по сообщениям и аналитику. В феврале 2010 года проект получил статус Apache Top-Level Project (TLP).

Развитие сообществом и корпоративное участие

После выхода из инкубатора разработку подхватили компании Rackspace, Twitter, Digg, Netflix и другие. В 2011 году была основана компания DataStax (изначально Riptano), предоставляющая коммерческую поддержку и расширения для Cassandra. В 2014 году вышла версия 2.1 с поддержкой транзакций (lightweight transactions). В 2015 году — версия 3.0, которая ввела новую модель хранения на основе SSTable (SSTable Attached Secondary Index, SASI) и улучшенную поддержку JSON. В 2019 году вышла версия 4.0 (после длительной бета-фазы), которая значительно повысила производительность, надёжность и безопасность.

Архитектура и принципы работы

Распределённое кольцо (Dynamo-style)

Cassandra организует узлы (nodes) в виртуальное кольцо. Данные распределяются по узлам с помощью консистентного хеширования: каждая строка получает первичный ключ (partition key), который хешируется, и полученное значение определяет, на каком узле (или наборе узлов) хранится строка. Каждый узел отвечает за определённый диапазон хеш-значений (token range).

Отсутствие единой точки отказа

В архитектуре Cassandra нет мастер-узла (masterless). Все узлы равноправны (peer-to-peer). Если один узел выходит из строя, запросы перенаправляются на другие узлы, хранящие реплики. Это обеспечивает высокую доступность.

Репликация

Уровень репликации (replication factor) задаётся для каждого keyspace (аналог базы данных в реляционных СУБД). Например, при replication factor = 3 данные каждой строки копируются на три разных узла. Стратегия размещения реплик (replication strategy) определяет, на какие узлы попадают копии: простая стратегия (SimpleStrategy — для одного дата-центра) или сетевая (NetworkTopologyStrategy — для нескольких дата-центров).

Модель данных (Bigtable-style)

Cassandra использует модель «семейство столбцов» (column family), которая в терминах Cassandra называется таблицей (table). Ключевые элементы:

• Keyspace — контейнер для таблиц, определяющий стратегию репликации и фактор репликации.
• Таблица — набор строк, каждая из которых идентифицируется первичным ключом (primary key). Первичный ключ состоит из ключа раздела (partition key) и необязательных кластеризующих столбцов (clustering columns).
• Строка — набор столбцов (пар «имя — значение»). Столбцы могут динамически добавляться (разреженная модель).
• Кластеризующие столбцы — определяют порядок сортировки данных внутри одного раздела (partition). Например, в таблице sensor_data ключ раздела — sensor_id, кластеризующий столбец — timestamp (данные сортируются по времени).

Консистентность и компромисс CAP

Cassandra по умолчанию является AP-системой в рамках теоремы CAP (доступность и устойчивость к разделению сети в приоритете, консистентность — настраиваемая). Для каждого запроса можно задать уровень консистентности (consistency level):

• ONE — ответ от одного узла (максимальная доступность, возможна устаревшая информация).
• QUORUM — ответ от большинства реплик (кворум).
• ALL — ответ от всех реплик (максимальная консистентность, но падает доступность при отказе узла).
• LOCAL_QUORUM, EACH_QUORUM — для много-дата-центровых развёртываний.

Gossip-протокол

Узлы Cassandra обмениваются информацией о состоянии кластера через gossip-протокол (с интервалом 1 секунда). Каждый узел периодически «болтает» (gossips) с несколькими случайными узлами, передавая метаданные: список живых/мёртвых узлов, версии схемы, нагрузки. Это позволяет кластеру самостоятельно обнаруживать сбои и восстанавливать топологию.

Ключевые характеристики

Линейная масштабируемость

Cassandra демонстрирует почти линейный рост пропускной способности при добавлении новых узлов. Например, при удвоении количества узлов скорость записи и чтения увеличивается примерно вдвое (при условии равномерного распределения данных). Это достигается за счёт отсутствия единой точки узкого места (мастер-узла).

Высокая производительность записи

Cassandra оптимизирована для операций записи. Все записи сначала попадают в commit log (журнал восстановления) и в memtable (структура в памяти). Периодически memtable сбрасывается на диск в виде SSTable (Sorted String Table). Запись не требует поиска по диску (sequential write), что даёт высокую скорость.

Гибкая схема данных

В отличие от реляционных СУБД, Cassandra не требует жёсткой схемы для всех столбцов. Можно добавлять новые столбцы в любую строку без изменения схемы всей таблицы. Однако ключи раздела и кластеризующие столбцы должны быть определены заранее.

Поддержка транзакций (ограниченная)

Cassandra поддерживает так называемые лёгкие транзакции (lightweight transactions) на основе протокола Paxos. Они позволяют выполнять атомарные операции «проверить и записать» (compare-and-set), например, вставку строки только при отсутствии дубликата. Однако полноценная поддержка ACID-транзакций с произвольными операциями отсутствует.

Применение

Cassandra используется в сценариях, где требуется высокая доступность и масштабируемость при записи больших объёмов данных. Типичные области применения:

• Интернет вещей (IoT) — сбор и хранение показаний с миллионов датчиков в реальном времени.
• Аналитика в реальном времени — хранение логов, метрик, данных мониторинга (например, в связке с Apache Spark).
• Социальные сети и мессенджеры — хранение сообщений, ленты активности, пользовательских профилей.
• Рекомендательные системы — хранение матриц предпочтений и результатов обработки.
• Финансовые системы — обработка транзакций с высокой скоростью записи (например, платёжные шлюзы).

Известные пользователи

• Apple — использует Cassandra для хранения данных iCloud (миллиарды записей).
• Netflix — хранит метаданные о фильмах и пользовательские предпочтения.
• Spotify — использует для хранения плейлистов и рекомендаций.
• **Instagram (продукт Meta, признанной экстремистской и запрещённой в РФ)** (принадлежит Meta — организация признана экстремистской и запрещена в РФ) — применял Cassandra для хранения ленты активности.
• Ebay — использует для каталога товаров и истории заказов.
• ВКонтакте (Россия) — использует Cassandra для хранения сообщений, ленты новостей и других сервисов с высокой нагрузкой.

Критика и ограничения

Ограничения модели данных

Cassandra не поддерживает JOIN-ы, внешние ключи и сложные агрегации. Для выполнения запросов, требующих объединения данных из разных таблиц, необходимо либо денормализовать данные, либо использовать внешние инструменты (Apache Spark, Presto).

Сложность администрирования

Настройка кластера, подбор ключей раздела, стратегий репликации и уровней консистентности требует глубокого понимания архитектуры. Неправильный выбор ключа раздела может привести к перекосу нагрузки (hot spots) — один узел получает непропорционально много запросов.

Консистентность в условиях разделения

В случае сетевого разделения (network partition) Cassandra может отдавать устаревшие данные, если уровень консистентности установлен ниже ALL. Это неприемлемо для систем, требующих строгой консистентности (например, банковские проводки).

Потребление ресурсов

Cassandra требовательна к оперативной памяти (для memtables) и дисковому пространству (для SSTable и compaction). В больших кластерах требуется тщательное планирование аппаратного обеспечения.

Альтернативы и конкуренты

• Apache HBase — построена на Hadoop и HDFS, сильна в аналитике, но сложнее в администрировании.
• ScyllaDB — совместимый с Cassandra движок на C++, обещающий более высокую производительность за счёт использования ядра Seastar.
• Amazon DynamoDB — управляемый сервис от AWS, схожий по модели данных, но с закрытым исходным кодом.
• MongoDB — документо-ориентированная СУБД, лучше подходит для сложных запросов, но уступает Cassandra в масштабировании записи.

Интересные факты

• Название «Cassandra» происходит от имени троянской пророчицы Кассандры из древнегреческой мифологии, что символизирует предсказуемость и надёжность системы.
• Внутри Facebook первоначальная версия Cassandra обрабатывала более 50 терабайт данных и обслуживала миллионы пользователей.
• Cassandra поддерживает работу с несколькими дата-центрами (multi-datacenter replication), что позволяет географически распределять данные и обеспечивать отказоустойчивость на уровне целых ЦОДов.
• В версии 4.0 (2019) была добавлена поддержка аудита (audit logging), улучшена безопасность (нативная поддержка TLS 1.3) и введён новый механизм compaction (Unified Compaction Strategy).

Источники

• Lakshman, A., & Malik, P. (2010). Cassandra: a decentralized structured storage system. ACM SIGOPS Operating Systems Review, 44(2), 35–40.
• Hewitt, E. (2010). Cassandra: The Definitive Guide. O'Reilly Media.
• DataStax Documentation. Apache Cassandra 4.0 Documentation.
• Apache Software Foundation. Cassandra Wiki and User Manual.
• Карпов, Д. (2019). Apache Cassandra: архитектура и практика применения. Хабрахабр.