Как обеспечить согласованность данных в Кассандре на разных таблицах?
Я новичок в Кассандре, и я читал, что Кассандра поощряет денормализацию и дублирование данных. Это оставляет меня немного смущенным. Давайте представим следующий сценарий:
У меня есть пространство клавиш с четырьмя таблицами: 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, как я могу обеспечить согласованность данных в других таблицах с такими же данными?
2 ответа
Кассандра обеспечивает BATCH для этого. Из документации:
Оператор BATCH объединяет несколько операторов языка изменения данных (DML) (INSERT, UPDATE, DELETE) в одну логическую операцию и устанавливает предоставленную клиентом временную метку для всех столбцов, записанных операторами в пакете. Пакетная обработка нескольких операторов может сохранить сетевой обмен между клиентом / сервером и координатором / репликами сервера. Однако из-за распределенной природы Cassandra распределите запросы между соседними узлами в максимально возможной степени, чтобы оптимизировать производительность. Использование пакетов для оптимизации производительности обычно не удается, как описано в разделе "Использование и неправильное использование пакетов". Информацию о самом быстром способе загрузки данных см. В разделе "Cassandra: пакетная загрузка без ключевого слова Batch".
Пакеты по умолчанию являются атомными. В контексте пакетной операции Cassandra атомарная означает, что если какой-либо из пакетов успешно, все будет. Для достижения атомарности Cassandra сначала записывает сериализованный пакет в системную таблицу пакетного журнала, которая использует сериализованный пакет в виде данных большого двоичного объекта. Когда строки в пакете были успешно записаны и сохранены (или намекают), данные пакетного журнала удаляются. Производительность снижается за атомарность. Если вы не хотите налагать это наказание, запретите Cassandra писать в систему пакетного журнала, используя опцию UNLOGGED: BEGIN UNLOGGED BATCH
UNLOGGED BATCH почти всегда нежелателен, и я считаю, что он будет удален в будущих версиях. Обычные партии обеспечивают желаемую функциональность.
Вы также можете изучить новую функцию Cassandra 3.0, которая называется материализованные представления:
Основные правила моделирования данных в Cassandra предполагают ручную денормализацию данных в отдельные таблицы на основе запросов, которые будут выполняться к этой таблице. В настоящее время единственный способ сделать запрос к столбцу без указания ключа раздела - это использовать вторичные индексы, но они не заменяют денормализацию данных в новые таблицы, поскольку они не подходят для данных с большим количеством элементов. Запросы вторичного индекса высокой мощности часто требуют ответов от всех узлов в кольце, что добавляет задержку к каждому запросу. Вместо этого используются денормализация на стороне клиента и несколько независимых таблиц, что означает, что один и тот же код переписывается для многих разных пользователей.
В 3.0 Cassandra представит новую функцию под названием Materialized Views. Материализованные представления обрабатывают автоматическую денормализацию на стороне сервера, устраняя необходимость обработки этой денормализацией на стороне клиента и обеспечивая возможную согласованность между базой и данными представления. Эта денормализация позволяет очень быстро искать данные в каждом представлении, используя обычный путь чтения Cassandra.
Идея точно такая же, как предложенная Джеффом Джирса, но она не потребует от вас обработки всей логики согласованности нескольких таблиц внутри вашего приложения, Cassandra сделает это автоматически.