Как обрабатывается денормализация в cassandra

Каков наилучший подход к обновлению таблицы с повторяющимися данными?

у меня есть стол

table users (
id text PRIMARY KEY,
email text,
description,
salary
)

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

когда я обновляю свою базовую таблицу, я делаю

insert into users (id, salary) values (1, 500);

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

Другие обходные пути и недостатки

  1. Я мог бы создать материализованное представление, но поскольку базовая таблица имеет только один первичный ключ, я могу добавить только еще один столбец. мое требование поиска требует более одного столбца.
  2. Создайте вторичные индексы для столбцов, по которым будет производиться поиск. Но производительность для этого будет плохой, поскольку столбцы, в которых я буду искать, будут иметь высокую кардинальность. т. е. описание, электронная почта и т. д.

nosql cassandra data-modeling denormalization
person Eduardo Dennis    schedule 18.11.2016    source источник

Ответы (1)


arrow_upward
2
arrow_downward

Итак, "правильный" способ сделать это - создать 3 таблицы. зарплата_по_идентификатору, зарплата_по_электронной почте и зарплата_по_описанию.

table salary_by_id (
  id text PRIMARY KEY,
  salary int
)

table salary_by_email (
  email text PRIMARY KEY,
  salary int
)

table salary_by_description (
  description text,
  id int,
  salary int,
  primary key (description, id)
)

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

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

Теперь при вставке или удалении значений вам нужно сделать это во всех трех таблицах. Если вы используете драйвер, как в java, который поддерживает асинхронные вызовы, то это не требует больших затрат.

person Andreas Wederbrand    schedule 18.11.2016
comment
но для сценария, в котором я вставляю в файл pay_by_id (1, 500), как я могу вставить его во вторую таблицу, если у меня нет адреса электронной почты, соответствующего этому? - person Eduardo Dennis; 18.11.2016
comment
Вам нужно было бы получить его раньше. Если у вас его еще нет где-то. - person Andreas Wederbrand; 18.11.2016
comment
@AndreasWederbrand Как убедиться, что все 3 обновления зарплаты будут успешными? Что произойдет, если только 2 из 3 запросов будут успешными? Будет ли это несогласованное состояние в одной таблице? - person Alin Ciocan; 17.11.2017
comment
Почему запись не удалась? По сути, вам придется убить узел Cassandra между двумя операциями записи или написать ошибочные запросы. Помните, Кассандра никогда не отказывается от записи. Не существует уникальных индексов или блокировок, которые могут истечь по тайм-ауту. - person Andreas Wederbrand; 17.11.2017
comment
@AndreasWederbrand Кассандра никогда не отклоняет записи — это неправда. Из документации: Apache Cassandra будет отбрасывать мутации, превышающие заданный размер. C* отбрасывает записи, которые составляют › 50 % от размера commit_log_segment_size_in_mb (в приведенном выше примере использования маловероятно, что ограничение по умолчанию будет превышено — если только поле описания не может иметь размер МБ. Но стоит уточнить, что запись может отклоняться.) - person Cities; 14.02.2019
comment
Верно. Поэтому, если одно из этих трех изменений будет чрезвычайно большим, оно НИКОГДА не будет успешным, независимо от стратегии. - person Andreas Wederbrand; 15.02.2019