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

В традиционной строчной базе данных данные хранятся и извлекаются по строкам, что означает, что все столбцы строки должны храниться вместе. Однако в колоночной базе данных, ориентированной на столбцы, каждый столбец таблицы хранится отдельно, что позволяет более эффективно хранить и извлекать данные.

Одни из самых популярных колоночных баз данных – Apache Cassandra и Apache HBase.

Зачем вообще кому-то могут понадобиться колоночные базы данных?

Они быстрее:

• Более быстрый поиск и извлечение столбцов: В колоночной базе данных каждый столбец хранится в виде отдельного файла, который можно сжать и оптимизировать с целью более эффективного хранения и извлечения данных. Такой подход позволяет повысить производительность запросов, поскольку мы оперируем только теми столбцами, которые необходимы в рамках конкретного запроса.

• Уплотненные ввод-вывод: Колоночные базы данных могут значительно сократить ввод-вывод, считывая только те столбцы, которые необходимы в рамках конкретного запроса. Как следствие время ответа на запрос сокращается и ресурсы используются более эффективно.

• Высокая производительность аналитических рабочих нагрузок: Колоночные базы данных специально оптимизированы для выполнения аналитических рабочих нагрузок, которые подразумевают обработку больших объемов данных для получения ценных сведений. Благодаря группировке данных по столбцам, колоночные базы данных быстрее сканируют и агрегируют данные для получения необходимых результатов.

Они эффективнее:

• Более эффективны с точки зрения потребления памяти: Колоночные базы данных могут быть более эффективными с точки зрения использования памяти, поскольку данные в столбцах, как правило, имеют схожие типы данных и значения, из-за чего их можно сжать более эффективно, чем данные в строках.

• Более эффективное сжатие данных: Колоночные базы данных могут достигать более высоких коэффициентов сжатия, чем традиционные базы данных. Как следствие, мы можем добиться значительной экономии памяти.

• Гибкая схема: Колоночным базам данных намного легче обрабатывать гибкие и динамические изменения схемы, чем их традиционным собратьям, группирующим данные по строкам. Это делает их более подходящим кандидатами для широкого спектра вариантов использования, включая работу с данными временных рядов, систем обмена сообщениями и многого другого.

Что из себя представляет Cassandra?

Cassandra — это популярная колоночная база данных, оптимизированная для обработки больших объемов данных на множестве commodity-серверов.

1. Высокая масштабируемость: Cassandra обладает высокой масштабируемостью и может легко обрабатывать большие объемы данных на нескольких узлах. Вы можете добавлять дополнительные узлы в свой кластер по мере роста ваших информационных потребностей.

2. Высокая доступность: Cassandra разработана с оглядкой на обеспечение высокой доступности и способна обрабатывать сбои узлов и нарушения связности сети без простоев. Это делает ее идеальным выбором для критически важных систем.

3. Высокая производительность: Cassandra разработана для обеспечения высокой производительности с низкой задержкой и высокой пропускной способностью. Она оптимизирована для рабочих нагрузок с большим количеством операций записи – она может обрабатывать миллионы операций записи в секунду.

4. Распределенная архитектура: Cassandra — это распределенная база данных, что означает, что ее можно развернуть сразу в нескольких центрах обработки данных в разных регионах. Это позволяет реплицировать данные для аварийного восстановления и сократить время ожидания для пользователей в разных географических точках.

Простой пример работы с Cassandra

from cassandra.cluster import Cluster
# Подключаемся к кластеру Cassandra
# Мы подключаемся к кластеру Cassandra посредством создания объекта Cluster с адресами узлов в кластере.
cluster = Cluster(['<cassandra-node-1>', '<cassandra-node-2>', '<cassandra-node-3>'])
# Затем мы создаем объект Session с именем пространства ключей, которое мы хотим использовать.
session = cluster.connect('<keyspace>')
# Create a table
session.execute("""
    CREATE TABLE IF NOT EXISTS users (
        id int PRIMARY KEY,
        name text,
        email text
    )
""")
# Заполняем таблицу данными
session.execute("""
    INSERT INTO users (id, name, email)
    VALUES (%s, %s, %s)
""", (1, 'Alice', 'alice@example.com'))
# Запрашиваем данные из таблицы
rows = session.execute("SELECT * FROM users")
for row in rows:
    print(row.id, row.name, row.email)
# Обновляем данные в таблице
session.execute("""
    UPDATE users
    SET email = %s
    WHERE id = %s
""", ('new-email@example.com', 1))
# Удаляем данные из таблицы
session.execute("""
    DELETE FROM users
    WHERE id = %s
""", (1,))
# Закрываем соединение с кластером Cassandra
cluster.shutdown()

В каких сценариях следует использовать Cassandra? Юзкейсы, альтернативы и недостатки

Как определить, какая именно колоночная база данных вам нужна?

Факторы, которые следует учитывать при выборе колоночной базы данных:

1. Тип рабочей нагрузки и шаблоны запросов: Для рабочих нагрузок, предполагающих сложных запросов, агрегирования и хранения данных, такие колоночные базы данных, как Vertica или ClickHouse, скорее всего, будут лучшим выбором, нежели Cassandra.

2. Требования к согласованности: Cassandra больше ориентирована на доступность и устойчивость к разделению сети, нежели на согласованность, что делает ее более подходящей для приложений, для которых подходит “согласованность в конечном счете” (eventual consistency). При более жестких требованиях к согласованности Hbase или Bigtable подойдут лучше.

3. Объемы данных: Если ваш набор данных относительно невелик и может уместиться на одной машине, более простая и легковесная база данных [например, Mysql] может быть лучшим выбором, нежели Cassandra.

4. Масштабируемость: Очень важно учитывать, насколько легко будет масштабировать базу данных, и сможет ли она обрабатывать большие объемы данных без ущерба для производительности. Cassandra, например, масштабируется линейно в зависимости от объема данных.

5. Производительность, доступность и отказоустойчивость: Также важно понимать, насколько быстро база данных может выполнять операции чтения и может ли она обрабатывать данные в реальном времени. Учитывайте, как база данных справляется с аппаратными сбоями или перебоями в работе сети, а также предоставляет ли она функционал для репликации и обеспечения избыточности данных. Cassandra, например, разработана с упором на обеспечение высокой доступности.

6. Стоимость: Разные колоночные базы данных имеют разные модели лицензирования и структуры ценообразования. Вам нужно учитывать стоимость базы данных, не забыв о лицензионных сборах и расходах на инфраструктуру и обслуживание.

7. Поддержка сообщества: Очень важными факторами являются размер и активность сообщества разработчиков и пользователей, а также доступность ресурсов и поддержки. Например, Cassandra, HBase, Bigtable — самые популярные колоночные базы данных.

Альтернативы Cassandra

Апач HBase: Apache HBase — это распределенная клоночная база данных с открытым исходным кодом, построенная поверх Hadoop. Существует несколько сценариев, в которых HBase может оказаться лучшей альтернативой Cassandra.

1. Ad-hoc запросы: HBase предоставляет более гибкую модель данных, чем Cassandra, что делает его хорошим выбором для приложений, предполагающих ad-hoc запросы и исследование данных.

2. Сложные типы данных: HBase поддерживает сложные типы данных, такие как массивы, map’ы и вложенные структуры, что делает его хорошим выбором для приложений, требующих более сложного моделирования данных.

3. Интеграция с Hadoop: HBase интегрирован с экосистемой Hadoop, что делает его хорошим выбором для приложений, требующих обработки данных с помощью таких инструментов, как Apache Spark и Apache Hive.

4. Строгая согласованность: HBase обеспечивает строгую согласованность (strong consistency), что означает, что данные всегда непротиворечивы и актуальны на всех узлах в кластере.

Bigtable: Google Cloud Bigtable — это полностью управляемый сервис NoSQL базы данных, предназначенный для обработки огромных объемов данных в режиме реального времени.

1. Интеграция с Google Cloud Platform: Он особенно хорошо подходит для сценариев, требующих интеграции с другими сервисами Google Cloud.

2. Строгая согласованность: Bigtable также обеспечивает строгую согласованность. Это делает его хорошим выбором для приложений, требующих согласованности транзакций.

3. Управляемый сервис: Bigtable — это полностью управляемый сервис на GCP, что означает, что Google берет на себя заботу о инфраструктуре, обслуживании и масштабировании базы данных. Если вы считаете, что управляемый сервис поможет вам сэкономить на операционных издержках, Bigtable скорее всего будет лучшим выбором.
   

ScyllaDB: ScyllaDB — это распределенная NoSQL база данных с открытым исходным кодом, которая позиционируется как “убийца Cassandra”.

1. Производительность: Может обрабатывать больше транзакций в секунду (TPS) с меньшей задержкой по сравнению с Cassandra.

2. Лучше в использовании оборудования: В сравнении с Cassandra ScyllaDB оптимальнее использует такие аппаратные ресурсы, как процессор и память, что может помочь вам сэкономить на затратах на оборудование.

3. Имеет встроенную поддержку аналитики в реальном времени благодаря своей фиче Materialized Views, которую можно использовать для создания вторичных индексов для более быстрого доступа к данным.

Так в чем же Cassandra выделяется на фоне остальных колоночных баз данных?

1. Распределенная архитектура, обеспечивающая высокую доступность и отказоустойчивость: Как и другие колоночные базы данных, Cassandra рассчитана на горизонтальное масштабирование за счет добавления дополнительных узлов в кластер. Однако, в отличие от других колоночных баз данных, распределенная архитектура Cassandra обеспечивает высокую доступность и отказоустойчивость, что упрощает масштабирование до громадных кластеров, состоящих из тысяч узлов.

2. Настраиваемая согласованность: Настраиваемая модель согласованности Cassandra позволяет пользователям изменять уровень согласованности для повышения доступности, что значительно упрощает масштабирование приложений в больших кластерах. Другие колоночные базы данных обычно обеспечивают более строгие гарантии согласованности, что может стать помехой для масштабирования до больших кластеров.

3. Легко масштабируется: Cassandra реализует децентрализованную (peer-to-peer) архитектуру, которая позволяет каждому узлу в кластере взаимодействовать со всеми остальными узлами. Это делает возможным добавление или удаление узлов из кластера без нарушения работы системы. Cassandra использует модель распределения данных, известную как последовательное хеширование (consistent hashing), которая обеспечивает равномерное распределение данных по узлам в кластере. Это упрощает масштабирование операций чтения и записи в больших кластерах.

4. Более низкая стоимость: Cassandra — это база данных с открытым исходным кодом, которую можно использовать бесплатно без каких-либо затрат на лицензирование.

Недостатки Cassandra

1. Сложность: Cassandra — это сложная система баз данных, требующая сложного обучения. Для правильной установки и настройки требуются специальные знания, а оптимизация производительности может быть сложной задачей.

2. Согласованность в конечном счете: Cassandra использует модель данных с согласованностью в конечном счете, а это означает, что между обновлениями, выполняемыми на разных узлах, может возникать некоторая задержка. При отсутствии должного контроля это может привести к несогласованности данных.

3. Накладные расходы на хранение: Cassandra реализует модель wide column store (буквально “широкие столбцы”), а это означает, что при хранении данных с разными значениями столбцов возникают некоторые накладные расходы. Это может стать причиной повышенных требований к хранилищу по сравнению с другими системами баз данных.

4. Требования к аппаратному обеспечению: Cassandra оптимизирована для работы на высокопроизводительном оборудовании, которое может быть весьма дорогостоящим. Также для оптимальной производительности ей требуется значительный объем оперативной памяти.

5. Ограниченные возможности формирования запросов: Язык запросов Cassandra (CQL) имеет ограниченную поддержку расширенных операций запросов, таких как подзапросы (subqueries) и полнотекстовый поиск (full-text search). Cassandra оптимизирована под простые запросы и может работать не лучшим образом со сложными запросами, требующими объединения или агрегирования.

6. Ограничения модели данных: Модель данных Cassandra оптимизирована для колоночных данных и может быть менее пригодной для транзакционных данных со сложными отношениями. Она также не поддерживает join’ы и ограничения ссылочной целостности.

Каждый инженер слышал о масштабировании. А вот вопрос, известный уже не каждому — сколько измерений масштабирования принято рассматривать? В 2007 году авторы книги "The Art of Scalability" ввели термин "The Scale Cube" и три измерения масштабирования.

Приглашаем на открытое занятие, на котором рассмотрим Scale Cube на примерах и поговорим о двух видах шардирования — горизонтальном и вертикальном. Также познакомимся с примерами СУБД, которые поддерживают те или иные виды шардирования.

Занятие пройдет в преддверии старта онлайн-курса "Highload Architect". Зарегистрироваться на открытый урок можно по ссылке.