Обзор хранилища Cassandra

Установка

Двигатель хранения Cassandra включён, но не установлен/активирован по умолчанию.

При использовании репозиториев YUM на Fedora, Red Hat или CentOS, сначала установите пакет двигателя хранения Cassandra с помощью:

yum install MariaDB-cassandra-engine

При использовании репозиториев Debian или Ubuntu плагин Cassandra находится в основном пакете сервера MariaDB.

Для установки/активации движка хранения в MariaDB выполните следующую команду:

install soname 'ha_cassandra.so'; 

Двигатель хранения также можно активировать, используя команду --plugin-load при запуске сервера.

Введение

Двигатель хранения Cassandra позволяет получить доступ к данным в кластере Cassandra из MariaDB. Общая архитектура показана на рисунке ниже и аналогична архитектуре движка хранения кластера NDB.

Вы можете получить доступ к одному и тому же кластеру Cassandra из нескольких экземпляров MariaDB, при условии, что каждый из них использует двигатель хранения Cassandra:

Основной целью Cassandra SE (двигателя хранения) является интеграция данных между SQL и NoSQL мирами. Вам когда-нибудь нужно было:

• получить некоторые данные Cassandra из вашего веб-фронта или SQL запроса?
• вставить несколько записей в Cassandra из какой-то части вашего приложения?

Теперь это легко возможно. Cassandra SE предоставляет семейства столбцов Cassandra как таблицы в MariaDB, в которые можно вставлять, обновлять и выбирать данные. Вы можете писать соединения против этой таблицы, возможно соединять данные, хранящиеся в MariaDB, с данными, хранящимися в Cassandra.

Версии в MariaDB

Что насчёт CQL?

Язык запросов Cassandra (CQL) — лучший способ работы с Cassandra. На первый взгляд он напоминает SQL, однако сходство очень поверхностное. Запросы CQL тесно связаны с тем, как Cassandra внутренне обращается к своим данным. Например, у вас не может быть даже самого простого соединения. Фактически, добавление даже самого маленького ... AND non_indexed_column=1 в WHERE предложение уже является невалидным CQL.

Наша цель — позволить работать в SQL вместо того, чтобы постоянно переключаться между CQL и SQL.

Превращает ли это Cassandra в SQL базу данных?

Нет. Cassandra SE не подходит для выполнения аналитических запросов, которые просматривают огромные объёмы данных в кластере Cassandra. Для этой задачи лучше подойдут инструменты на базе Hadoop, такие как Apache Pig или Apache Hive. Cassandra SE скорее является «окном» из SQL среды в NoSQL.

Отображение данных

Давайте уточним. Чтобы получить доступ к данным Cassandra из MariaDB, необходимо создать таблицу с engine=cassandra. Таблица будет представлять вид семейства столбцов в Cassandra, и её определение будет выглядеть так:

set cassandra_default_thrift_host='192.168.0.10' -- Cassandra's address. It can also
                                                 -- be specified as startup parameter
                                                 -- or on per-table basis

create table cassandra_tbl      -- table name can be chosen at will
(
  rowkey  type PRIMARY KEY,     -- represents Column Family's rowkey. Primary key
                                -- must be defined over this column.

  column1 type,                 -- Cassandra's static columns can be mapped to 
  column2 type,                 -- regular SQL columns.

  dynamic_cols blob DYNAMIC_COLUMN_STORAGE=yes -- If you need to access Cassandra's
                                               -- dynamic columns, you can define
                                               -- a blob which will receive all of 
                                               -- them, packed as MariaDB's dynamic
                                               -- columns.
) engine=cassandra
  keyspace= 'cassandra_key_space'        -- Cassandra's keyspace.columnFamily we  
  column_family='column_family_name';    -- are accessing.

Имя таблицы может быть произвольным. Однако первичный ключ, имена столбцов и типы должны «соответствовать» тем, что в Cassandra.

Ключ строки Cassandra

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

• Если у Cassandra rowkey есть псевдоним (или имя), то столбец MariaDB должен иметь то же имя.
  • В противном случае он должен называться «rowkey».
• Тип столбца MariaDB должен соответствовать validation_class ключа строки Cassandra (соответствие типов данных рассматривается более подробно ниже).

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

Статические столбцы Cassandra

Cassandra позволяет определять «статическое семейство столбцов», где метаданные столбцов определяются в заголовке семейства столбцов и выполняются всеми записями.

Эти «статические» столбцы могут быть отображены в обычные столбцы в MariaDB. Статический столбец с именем 'foo' в Cassandra должен иметь соответствующий столбец с именем 'foo' в MariaDB. Типы также должны совпадать, они рассматриваются ниже.

Динамические столбцы Cassandra

Cassandra также позволяет отдельным строкам иметь свои наборы столбцов. Другими словами, каждая строка может иметь свои уникальные столбцы.

К этим столбцам можно получить доступ через функцию «Динамические столбцы» MariaDB. Для этого необходимо определить столбец:

• с произвольным именем
• типа blob
• с атрибутом DYNAMIC_COLUMN_STORAGE=yes

Вот пример:

dynamic_cols blob DYNAMIC_COLUMN_STORAGE=yes

После определения, к отдельным столбцам можно получить доступ с помощью новой версии функций «Динамических столбцов», которые теперь поддерживают строковые имена (раньше поддерживались только целые числа).

Суперстолбцы

Суперстолбцы Cassandra не поддерживаются, и в настоящее время нет планов по их поддержке.

Типы данных

Нет прямого взаимно однозначного соответствия между типами данных Cassandra и MySQL/MariaDB. Кроме того, ограничения размера Cassandra часто более гибкие, чем в MySQL/MariaDB. Например, ограничение длины ключа строки Cassandra составляет около 2 ГБ, в то время как MySQL ограничивает длину уникального ключа примерно до 1,5 КБ.

Типы должны отображаться следующим образом:

Для типов, таких как «VARBINARY(n)», n нужно выбрать достаточно большой размер, чтобы вместить все данные, которые встречаются в таблице.

Сопоставление команд

Вставка

Cassandra не предоставляет практического способа сделать INSERT отличным от UPDATE. Поэтому INSERT работает как INSERT-или-UPDATE, он перепишет данные, если необходимо.

INSERT ... SELECT и многострочные INSERT будут пытаться записывать данные порциями. Размер порции контролируется переменной cassandra_insert_batch_size, которая задаёт максимальный размер порции в столбцах.

Переменные статуса Cassandra_row_inserts и Cassandra_row_insert_batches позволяют увидеть, действительно ли вставки выполняются порциями.

Обновление

UPDATE работает так, как вы ожидаете, что должна работать команда UPDATE SQL (т.е. изменение значения первичного ключа приведёт к удалению старой записи и вставке новой записи)

Удаление

• DELETE FROM cassandra_table сопоставляется с вызовом truncate(column_family).

• Удаление с предложением WHERE будет выполнять удаление по каждой строке.

Выбор

В целом, все операторы SELECT работают так, как вы ожидаете от SQL. Условия в формате primary_key=... позволяют серверу создавать планы запросов, которые обращаются к строкам Cassandra с помощью поиска по ключу.

Полный просмотр таблицы

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

Поддержка доступа по ключу в виде порций

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

• optimizer_switch='join_cache_hashed=on'
• join_cache_level=7|8

Cassandra SE в настоящее время не может использовать пространство в буфере объединения (размер которого контролируется #join_buffer_size). Вместо этого он будет ограничивать чтение порциями, читая не более cassandra_multiget_batch_size за раз, и память будет выделена в куче.

Обратите внимание, что буфер #join_buffer_size всё ещё необходим SQL слою, поэтому его значение всё равно следует увеличивать, если вы хотите читать большими порциями.

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

Системные и переменные состояния

Доступны следующие системные переменные:

Доступны следующие переменные состояния:

Примечание о Cassandra 1.2

В Cassandra 1.2 немного изменилась модель данных, как описано в http://www.datastax.com/dev/blog/thrift-to-cql3. Это привело к тому, что некоторые клиенты на основе Thrift больше не работают (например, у Pig возникла проблема: CASSANDRA-5234).

В настоящее время Cassandra SE может получать доступ только к семействам столбцов Cassandra 1.2, которые были определены WITH COMPACT STORAGE атрибутом.

См. также

• Слайды с выступления на Percona Live 2013: MariaDB Cassandra Interoperability
• MDEV-431 - задача JIRA для работы Cassandra SE
• Инструкции по созданию бинарного файла tarball в MariaDB 5.5
• Cassandra Storage Engine — Планы на будущее
• Cassandra Storage Engine — Пример использования
• Cassandra Storage Engine — Проблемы
• HBase Storage Engine