Как обеспечить согласованность данных в Cassandra на разных таблицах?

Я новичок в Кассандре, и я читал, что Кассандра поощряет денормализацию и дублирование данных. Это оставляет меня немного смущенным. Давайте представим следующий сценарий:

У меня есть пространство клавиш с четырьмя таблицами: A, B, C и D.

CREATE TABLE A (
  tableID int,
  column1 int,
  column2 varchar,
  column3 varchar,
  column4 varchar,
  column5 varchar,
  PRIMARY KEY (column1, tableID)
);

Давайте представим, что другие таблицы (B, C, D) имеют такую же структуру и те же данные, что и таблица A, только с другим первичным ключом, чтобы отвечать на другие запросы.

Если я обновлю строку в таблице A, как я могу обеспечить согласованность данных в других таблицах с такими же данными?

Ответ 1

Кассандра обеспечивает BATCH для этой цели. Из документации:

Оператор BATCH объединяет несколько операторов языка изменения данных (DML) (INSERT, UPDATE, DELETE) в одну логическую операцию и устанавливает временную метку, предоставленную клиентом, для всех столбцов, написанных операторами в пакете. Объединение нескольких операторов может сэкономить обмен данными между клиентом/сервером и координатором/репликами сервера. Однако из-за распределенного характера Cassandra максимально распространять запросы по ближайшим узлам для оптимизации производительности. Использование партий для оптимизации производительности обычно не выполняется, как описано в разделе "Использование и неправильное использование пакетов". Информацию о самом быстром способе загрузки данных см. В разделе "Cassandra: пакетная загрузка без ключевого слова Batch".

Партии по умолчанию являются атомарными. В контексте пакетной операции Cassandra атомный означает, что если какая-либо из пакетов будет успешной, все это будет. Чтобы добиться атомарности, Cassandra сначала записывает сериализованную партию в таблицу системных журналов, которая потребляет сериализованную партию в виде данных blob. Когда строки в партии были успешно записаны и сохранены (или намечены), данные в пакете удаляются. Для атомарности есть штраф за производительность. Если вы не хотите брать на себя этот штраф, не позволяйте Кассандре писать в систему пакетного журнала, используя опцию UNLOGGED: BEGIN UNLOGGED BATCH

UNLOGGED BATCH почти всегда нежелателен, и я считаю, что он удаляется в будущих версиях. Обычные партии обеспечивают необходимую функциональность.

Ответ 2

Вы также можете изучить новую функцию из Cassandra 3.0 под названием материализованные представления:

Основные правила моделирования данных в Cassandra включают ручную денормализацию данных в отдельные таблицы на основе запросов, которые будут выполняться против этой таблицы. В настоящее время единственным способом запроса столбца без указания ключа раздела является использование вторичных индексов, но они не заменяют денормализацию данных в новые таблицы, поскольку они не подходят для данных с высокой мощностью. Запросы вторичных индексов высокой мощности часто требуют ответов от всех узлов в кольце, что добавляет латентность для каждого запроса. Вместо этого используется денормализация на стороне клиента и несколько независимых таблиц, что означает, что один и тот же код переписывается для разных пользователей.

В 3.0, Cassandra представит новую функцию, называемую Materialized Views. Материализованные представления обрабатывают автоматическую денормализацию на стороне сервера, устраняя необходимость обработки этой денормализации на стороне клиента и обеспечивая возможную согласованность между базовыми и отображаемыми данными. Эта денормализация позволяет очень быстро находить данные в каждом представлении, используя обычный путь чтения Кассандры.

Идея точно такая же, как предложено Джеффом Джирсой, но для вас не потребуется обрабатывать всю логику согласования нескольких таблиц внутри вашего приложения, Cassandra сделает это за вас автоматически.