Что такое Apache Cassandra: архитектура, история и принципы работы

Apache Cassandra – это нереляционная отказоустойчивая распределенная СУБД, рассчитанная на создание высокомасштабируемых и надёжных хранилищ огромных массивов данных, представленных в виде хэша. Проект был разработан на языке Java в корпорации Facebook в 2008 году, и передан фонду Apache Software Foundation в 2009 [1]. Эта СУБД относится к гибридным NoSQL-решениям, поскольку она сочетает модель хранения данных на базе семейства столбцов (ColumnFamily) с концепцией key-value (ключ-значение) [2].

Модель данных Apache Cassandra

Модель данных Cassandra состоит из следующих элементов [3]:

столбец или колонка (column) – ячейка с данными, включающая 3 части – имя (column name) в виде массива байтов, метку времени (timestamp) и само значение (value) также в виде байтового массива. С каждым значением связана метка времени — задаваемое пользователем 64-битное число, которое используется для разрешения конфликтов во время записи: чем оно больше, тем новее считается столбец. Это учитывается при удалении старых колонок.
строка или запись (row) – именованная коллекция столбцов;
семейство столбцов (column family) – именованная коллекция строк;
пространство ключей (keyspace) – группа из нескольких семейств столбцов, собранных вместе. Оно логически группирует семейства столбцов и обеспечивает изолированные области имен.

Также стоит отметить понятия сравнителя (comparator), задаваемого для имени столбца и валидатора (validator) для значений и ключей. Comparator определяет, какие байтовые значения допустимы для имён колонок и как их упорядочить, а validator – для значений колонок и ключей. Если они не заданы, то Кассандра хранит значения и сравнивает их как байтовые строки (BytesType) так как, по сути, они сохраняются внутри. Вообще, в рассматриваемой СУБД доступны следующие типы данных [4]:

BytesType: любые байтовые строки (без валидации);
AsciiType: ASCII строка;
UTF8Type: UTF-8 строка;
IntegerType: число с произвольным размером;
Int32Type: 4-байтовое число;
LongType: 8-байтовое число;
UUIDType: UUID 1-ого или 4-ого типа;
TimeUUIDType: UUID 1-ого типа;
DateType: 8-байтовое значение метки времени;
BooleanType: два значения: true = 1 или false = 0;
FloatType: 4-байтовое число с плавающей запятой;
DoubleType: 8-байтовое число с плавающей запятой;
DecimalType: число с произвольным размером и плавающей запятой;
CounterColumnType: 8-байтовый счётчик.

Пространство ключей соответствует понятию схемы базы данных (database schema) в реляционной модели, а находящиеся в нем семейства столбцов – реляционной таблице. Столбцы объединяются в записи при помощи ключа (row key) в виде массива байтов, по значению которого столбцы упорядочены в пределах одной записи. В отличие от реляционных СУБД, в NoSQL модели возможна ситуация, когда разные строки содержат разное число колонок или столбцы с такими же именами, как и в других записях [4].

SQL-СУБД и Apache Cassandra, модель данных NoSQL Кассандра — Как понятия модели данных NoSQL-СУБД Кассандра соответствуют реляционной парадигме

Можно сказать, конкретное значение, хранимое в Apache Cassandra, идентифицируется следующими привязками [4]:

к приложению или предметной области в пространстве ключей, что позволяет на одном кластере размещать данные разных приложений;
к запросу в рамках семейства столбцов;
к узлу кластера с помощью ключа, который определяет, на какие узлы попадут сохранённые колонки;
к атрибуту в записи с помощью имени колонки, что позволяет в одной записи хранить несколько значений.

Структура данных при этом выглядит так [4]:

Keyspace
- ColumnFamily
  - Row
    - Key
    - Column
      - Name
      - Value
    - Column
    - …
  - …

data model Cassandra, модель данных Кассандра — Модель данных Apache Cassandra

Архитектура

Apache Cassandra – это децентрализованная распределенная система, состоящая из нескольких узлов, по которым она распределяет данные. В отличие от многих других Big Data решений экосистемы Apache Hadoop (HBase, HDFS), эта СУБД не поддерживает концепцию master/slave (ведущий/ведомый), когда один из серверов является управляющим для других компонентов кластера.

Для распределения элементов данных по узлам Кассандра использует последовательное хэширование, применяя хэш-алгоритм для вычисления хэш-значений ключей каждого элемента данных (имя столбца, ID строки и пр.). Диапазон всех возможных хэш-значений, т.е. пространство ключей, распределяется между узлами кластера так, что каждому элементу данных назначен свой узел, который отвечает за хранение и управление этим элементом данных [3].

Благодаря такой распределенной архитектуре, Кассандра предоставляет следующие возможности [3]:

распределение данных между узлами кластера прозрачно для пользователей – каждый сервер может принимать любой запрос (на чтение, запись или удаление данных), пересылая его на другой узел, если запрашиваемая информацию хранится не здесь;
пользователи могут сами определить необходимое количество реплик, создание и управление которыми обеспечит Cassandra;
настраиваемый пользователями уровень согласованности данных по каждой операции хранения и считывания;
высокая скорость записи (около 80-360 МБ/с на узел) – данные записываются быстрее, чем считываются за счет того, что их большая часть хранится в оперативной памяти ответственного узла, и любые обновления сперва выполняются в памяти, а только потом – в файловой системе. Чтобы избежать потери информации, все транзакции фиксируются в специальном журнале на диске. При этом, в отличие от обновления данных, записи в журналы фиксации только добавляются, что исключает задержку при вращении диска. Кроме того, если не требуется полная согласованность записей, Cassandra записывает данные в достаточное число узлов без разрешения конфликтов несоответствия, которые разрешаются только при первом считывании.
гибкая масштабируемость – можно построить кластер даже на сотню узлов, способный обрабатывать петабайты данных.

Таким образом, отсутствие центрального узла лишает Кассандру главного недостатка, свойственного системам master/slave, в которых отказывает весь кластер при сбое главного сервера (Master Node). В кластере Cassandra все узлы равноценны между собой и, если один из них отказал, его функции возьмет на себя какой-то из оставшихся. Благодаря такой децентрализации Apache Cassandra отлично подходит для географически распределенных систем с высокой доступностью, расположенных в разных датацентрах. Однако, при всех преимуществах такой гибко масштабируемой архитектуры, она обусловливает особенности операций чтения и записи, а также накладывает ряд существенных ограничений на использование этой СУБД в реальных Big Data проектах.

architecture Apache Cassandra — Кластерная архитектура Apache Cassandra

О ключевых возможностях, достоинствах и недостатках Apache Cassandra мы расскажем в отдельной статье. А примеры практического использования этой СУБД класса NoSQL в реальных Big Data проектах мы собрали здесь.

Источники

Модель данных Apache Cassandra

Архитектура

Related Entries