A B C D E F G H I K L M N O P R S T W Y Z Б В Е И К М О П Т Ц

Cassandra

Big Data, Большие данные, архитектура, обработка данных, NoSQL, SQL, 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 проектах мы собрали здесь.

Источники

  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

Поиск по сайту