Синхронизация таблиц Cassandra

Я только что прочитал сообщение DataStax"Основные правила моделирования данных Cassandra" и, подводя итог, мы должны моделировать нашу схему базы данных по нашим запросам, а не по нашим отношениям/объектам. Таким образом, многие таблицы могут иметь одинаковые дублированные данные, например users_by_email и users_by_username которые имеют одинаковые данные.

как я могу обрабатывать обновление объекта ?
Например, пользователь редактирует свою электронную почту, do I UPDATE обе таблицы вручную или только INSERT объект со всеми столбцами и не заботьтесь о предыдущих данных (которые все еще находятся в моей базе данных, но с неправильным значением столбца => email).

в случае UPDATE, Как я могу обрабатывать синхронизацию данных ?
В настоящее время я делаю это вручную, но есть ли инструмент, чтобы помочь мне ? Потому что, возможно, у меня может быть 5 или 6 таблиц с разными ключами раздела/кластеризации.
Я слышал, что Hadoop может это сделать, или Apache Spark.

6
cassandra datastax nosql

3 ответов

в Cassadnra, учитывая существующую запись, обновление или вставка с использованием того же первичного ключа приведет к старой записи, помеченной для удаления (с надгробием), и новая запись станет "живой". Есть несколько тонкостей в разнице между Insert и Update, таких как счетчики и значения null, но они, вероятно, не имеют отношения к вопросу.

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

Кассандра 3.0 введена "Материализованные Представления", который позволяет вам поддерживать "главную" таблицу данных и несколько представлений на ней, все управляемые Кассандрой. Это требует тщательного моделирования данных, чтобы первичный ключ таблицы "master" содержал необходимые объекты для создания различных представлений и связанных запросов.

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

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

2

чтобы обеспечить согласованность данных во многих таблицах, содержащих одни и те же данные, но расположенных по-разному, рекомендуется использовать зарегистрированный пакет в CQL для обновления. Таким образом, ваши операторы CQL (обновление данных) в вашем пакете являются ACID, и вам не нужно беспокоиться о некоторых сбоях и повторных попытках.

используя схему связанной статьи, она будет выглядеть так:

BEGIN BATCH
  INSERT INTO users_by_email (email, username, age) VALUES ('fromanator@email.com', 'fromanator', 24);
  INSERT INTO users_by_username (email, username, age) VALUES ('fromanator@email.com', 'fromanator', 24);
APPLY BATCH;

весь этот оператор является атомарным, если одна вставка терпит неудачу, все они терпят неудачу и никаких изменений не было сделанный.

3

то, что я сделал в своей системе, имеет уникальный идентификатор для каждого пользователя.

Я использую одну таблицу email / identifier (и некоторые другие данные). Когда пользователь входит в систему или использует систему, я использую его электронную почту, чтобы найти идентификатор, а все остальное использует этот идентификатор.

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

Что касается старого адреса электронной почты, I еще не все, но я планирую иметь текущую ссылку на электронную почту на старую ("ссылку", если хотите), и через некоторое время, возможно, через 12 месяцев, старое письмо будет удалено. В течение этих 12 месяцев учетная запись блокируется (никто другой не может повторно использовать эту учетную запись.) Это хорошая идея по различным соображениям безопасности.

P. S. Для уникального идентификатора, люди используют различные решения, такие как боец, мне лично понравилось использовать Кассандра с пекарней Лампорта алгоритм.

1