Раз-два-много: уровни согласованности Apache Cassandra при распределенной обработке Big Data

Big Data, Большие данные, архитектура, обработка данных, NoSQL, SQL, Cassandra

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

Что такое согласованность и зачем она нужна

Вообще, разговор о согласованности данных в распределенных системах стоит начать с CAP-теоремы (согласованность, доступность, устойчивость) [1], однако это тема отдельной статьи. Apache Cassandra полностью реализует принципы доступности (Availability) и устойчивости к разделению (Partition tolerance), обеспечивая корректный отклик на любой запрос и простоту масштабирования. Однако, согласованность (Consistency), т.е. непротиворечивость данных считается слабым местом этой распределенной СУБД в связи с ее децентрализацией, когда на множестве узлов хранятся разные реплики одной и той же информации. Для устранения этой проблемы используется механизм настройки уровней согласованности.

Напомним, в отличие от другой популярной NoSQL-базы данных для Big Data, Apache HBase, все узлы кластера Cassandra равноценны – клиенты могут соединятся с любым из них для записи и чтения. При этом выполнение запроса начинается с его координации, чтобы с помощью ключа и меток определить, на каких узлах кластера находятся нужные данные и отправить запрос именно туда. Узел, выполняющий координацию, называется координатором (coordinator), а узлы, которые выбраны для сохранения записи с данным ключом — узлами-реплик (replica nodes). Физически координатором может быть один из узлов-реплик [2].

Можно сказать, что доступность данных напрямую зависит от уровня согласованности операций чтения и записи, так как он определяет, сколько узлов-реплик может отказать при подтверждении успешного выполнения этих операций. Например, если уровень репликаций меньше, чем сумма узлов, с которых пришло подтверждения об успешной записи данных, и с которых происходит чтение, то есть гарантия строгой согласованности (strong consistency). Строгая согласованность гарантирует, что после записи новое значение всегда будет прочитано. Иначе возможна ситуация, когда в результате чтения СУБД возвратит устаревшие данные.

Для борьбы с этим в Apache Cassandra есть механизм итоговой согласованности (eventual consistency), который распространит данные по узлам-репликам после того, как закончится координационное ожидание. Если при этом будут доступны не все узлы-реплики, то придется задействовать другие средства восстановления данных, в частности, чтение с исправлением и запускаемое вручную анти-энтропийное восстановление узла (anti-entropy node repair) [2].

Big Data Writing in Cluster Apache Cassandra, согласованность в распределенной NoSQL-СУБД
Распределенная запись данных в кластере Apache Cassandra

Согласованная запись в NoSQL-СУБД Кассандра

При записи данных уровень согласованности определяет количество узлов-реплик, с которых будет ожидаться подтверждение удачного окончания операции – сигнала того, что данные успешно записаны. Для записи существуют такие уровни согласованности [2]:

  • ANY (0) — даёт возможность записать данные, даже если все узлы-реплики не отвечают. Координатор дожидается первого ответа от любого одного узла-реплик или данные сохранятся с помощью механизма направленной отправки (hinted handoff) на координаторе.
  • ONE (1) — координатор шлёт запросы всем узлам-реплик, но возвращает управление пользователю, дождавшись подтверждения от любого первого узла;
  • TWO (2)— координатор дожидается подтверждения от двух первых узлов, прежде чем вернуть управление;
  • THREE (3) — координатор ждет подтверждения от трех первых узлов, прежде чем вернуть управление;
  • QUORUM (4) — координатор дожидается подтверждения записи от более чем половины узлов-реплик, а именно round(N/2)+1, где N — уровень репликации;
  • ALL (5) — координатор дожидается подтверждения от всех узлов-реплик;
  • LOCAL_QUORUM (6) — координатор дожидается подтверждения от более чем половины узлов-реплик в том же центре обработки данных, где расположен координатор. Это позволяет избавиться от задержек, связанных с пересылкой данных в другие датацентры.
  • EACH_QUORUM (7) — координатор дожидается подтверждения от более чем половины узлов-реплик в каждом центре обработки данных.
Запись Big Data в Согласованная запись в Apache Cassandra
Согласованная запись в Apache Cassandra

Согласованное чтение Big Data в Apache Cassandra

В случае чтения уровень согласованности определяет количество узлов-реплик, с которых будет считана информация [2]:

  • ONE (1) — координатор шлёт запросы к ближайшему узлу-реплике, читая остальные с целью исправления (read repair) с заранее заданной в конфигурации вероятностью;
  • TWO (2) — координатор шлёт запросы к двум ближайшим узлам, выбирая значение с большей меткой времени;
  • THREE (3) — координатор шлёт запросы к трем ближайшим узлам, выбирая значение с большей меткой времени;
  • QUORUM (4) — собирается кворум, то есть координатор шлёт запросы к более чем половине узлов-реплик, а именно round(N/2)+1, где N — уровень репликации;
  • ALL (5) — координатор возвращает данные после прочтения со всех узлов-реплик;
  • LOCAL_QUORUM (6) — собирается кворум узлов в том датацентре, где происходит координация, и возвращаются данные с последней меткой времени;
  • EACH_QUORUM (7) — координатор возвращает данные после собрания кворума в каждом из датацентров.
Чтение Big Data в Apache Cassandra
Согласованность Кассандра при чтении данных

Как уровни согласованности влияют на быстроту работы NoSQL СУБД

Подводя итог возможным уровням согласованности в Apache Cassandra, можно сделать следующие выводы [2]:

  • QUORUM на чтение и на запись обеспечит строгую согласованность и баланс между временной задержкой на выполнение этих операций;
  • strong consistency также будет достигнута при записи ALL, и чтении ONE. Однако, в этом случае данные будут считываться быстрее и с большей доступностью, поскольку количество отказавших узлов, при котором чтение все еще будет выполнено, может быть больше, чем при QUORUM. Для записи потребуются все рабочие узлы-реплик.
  • Обратный случай (запись ONE, чтение ALL) тоже обеспечит строгую согласованность, но запись будет выполняться быстрее и с большей доступностью, т.к. потребуется подтверждение об успешном окончании операции лишь с одного узла. Чтение же, в этом случае, требует отклика от всех узлов-реплик и происходит медленнее.
  • При отсутствии требований о строгой согласованности, можно ускорить операции чтения и записи, а также улучшить доступность за счет выставления меньших уровней согласованности.

По умолчанию для всех операций в Apache Cassandra используется уровень согласованности ONE. Отметим, что в ранних версиях этой NoSQL-СУБД задать уровень согласованности можно было прямо в самом CQL-запросе, например, так [3]:

SELECT * FROM users WHERE state=’TX’ USING CONSISTENCY QUORUM;

Однако, начиная с версии 1.2 (2012 год) разработчики убрали эту возможность, аргументируя тем, что согласованность операции должна устанавливаться не в рамках запроса, а на уровне протокола ее выполнения [3]. Таким образом, сегодня установить consistency level в Кассандре можно двумя следующими способами:

  • изменить значение этого параметра в программном коде с использованием класса SimpleStatement, например, так [4]:

from cassandra import ConsistencyLevel

from cassandra.query import SimpleStatement

query = SimpleStatement(

«INSERT INTO users (name, age) VALUES (%s, %s)»,

consistency_level=ConsistencyLevel.QUORUM)

session.execute(query, (‘John’, 42))

  • также можно указать необходимый уровень согласованности в следующей инструкции cqlsh, оболочки командной строки для взаимодействия с Cassandra через CQL [5]:

CONSISTENCY <consistency level>

Напомним, cqlsh поддерживает ряд специальных команд, которые не являются частью CQL, используя драйвер собственного протокола Python при подключении к узлу, указанному в командной строке [5].

обработка данных, NoSQL, SQL, Кассандра, установка уровня согласованности
Пример установки уровня согласованности Кассандры в оболочке командной строки cqlsh

В следующей статье мы подробнее расскажем, как именно выполняются процессы записи и считывания больших данных (Big Data) в Apache Cassandra с учетом рассмотренных уровней согласованности.

Источники

  1. https://ru.wikipedia.org/wiki/Теорема_CAP
  2. https://ru.bmstu.wiki/Apache_Cassandra
  3. https://issues.apache.org/jira/browse/CASSANDRA-4734
  4. https://wp.huangshiyang.com/cassandra-setting-a-consistency-level
  5. https://cassandra.apache.org/doc/latest/tools/cqlsh.html

 

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