Избавление от путаницы в отношении баз данных NoSQL

Question

Этот вопрос касается NoSQL (например, взять cassandra).

• Верно ли, что при использовании базы данных NoSQL без репликации данных у вас нет проблем с согласованностью? Также не в случае параллелизма доступа?

• Что происходит в случае раздела, в котором одна и та же строка была записана в обоих разделах, возможно несколько раз? Когда раздел ушел, какое письменное значение используется?

• Предположим, вы используете N = 5 Вт = 3 R = 3. Это означает, что у вас есть гарантированная последовательность? Насколько хорошо использовать этот кворум? Имея 3 узла, возвращающих данные, это не большие накладные расходы?

• Можете ли вы указать для каждого запроса в cassandra, хотите ли вы, чтобы запрос имел гарантированную согласованность? Например, вы выполняете запрос вставки, и вы хотите, чтобы все реплики заполнили вставку до того, как значение будет возвращено операцией чтения?

• Если у вас есть: сотрудники {PK: employeeID, departmentId, employeeName, birthday} и отдел {PK: departmentID, departmentName}, и вы хотите получить день рождения всех сотрудников с определенным названием отдела. Две проблемы:

  1. вы не можете попросить всех сотрудников с данным днем ​​рождения (потому что вы можете только запрос по первичному ключу)
  2. Вы не можете присоединиться к сотруднику и семьи колонки отдел, потому что присоединяется невозможны.

Так что вы можете сделать, это создать семью колонки:

departmentBirthdays {PK: (departmentName, день рождения), [сотрудников-чей-день рождения-это-это]}

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

Answer 1

Я отвечу на это с точки зрения cassandra, потому что вы, кажется, смотрите (вряд ли какие-либо два магазина nosql одинаковы!).

1. Для одного узла все операции выполняются последовательно. Проблемы параллелизма могут быть ортогональными, хотя ... ваш веб-клиент, возможно, сделал запрос, а затем другой, но из-за сетевой нагрузки, cassandra получил второй первый. Это может быть или не быть проблемой. Существуют такие подходы вокруг таких проблем, как неизменные данные. Вы также можете использовать «легкие транзакции».

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

3. Quurom для чтения и записи даст вам последовательность. Существует краевой случай. Если координатор не знает, что узел кворума отсутствует, он отправляет запросы на запись, после чего запись будет завершена, когда кворум будет восстановлен. Клиент в этом случае получит тайм-аут, а не сбой.Последующий запрос может получить устаревшие данные, но любой запрос после этого получит последние данные. Это крайний край, и обычно N = 5, R = 3, W3 = даст вам полную согласованность. Чтение из трех узлов не является на самом деле большой частью накладных расходов. Для запроса с R = 3 клиент отправит этот запрос узлу, к которому он подключен (координатор). Координатор будет запрашивать реплики параллельно (не последовательно). Он будет увеличивать результаты с помощью LWW, чтобы получить результат (и, при необходимости, произвести ремонт и т. Д.). Поскольку запросы происходят параллельно, накладные расходы значительно сокращаются.

4. Да.

5. Это вопрос моделирования данных. Вы описываете один подход (хотя разбиение на день рождения, а не на деление, может быть лучше и привести к более равномерному распределению разделов). Вам нужны таблицы сотрудников и отделов ... нужны ли они для других запросов? Если нет, возможно, вам просто нужен он. Если вы денормализуете, вам нужно будет сохранить данные вручную. В Cassandra 3.0 глобальные индексы позволят вам запрашивать индекс, не будучи неэффективным (что имеет место при использовании вторичного индекса без указания ключа раздела сегодня). Да еще один вариант состоит в том, чтобы разбивать занятый день рождения на два дня и делать два запроса, а также присоединяться к памяти в клиенте. Запросы Cassandra, попадающие в раздел, очень быстры, поэтому делать два на самом деле не так дорого.