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].

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

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

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

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

Архитектура

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 проектах.

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

Источники

1. https://ru.wikipedia.org/wiki/Apache_Cassandra
2. https://eax.me/cassandra/
3. https://www.ibm.com/developerworks/ru/library/os-apache-cassandra/
4. https://ru.bmstu.wiki/Apache_Cassandra

Related Entries

• NoSQL
• CAP
• HBase
• Kudu
• ClickHouse