Как неизменные данные делают конечную согласованность тривиальной?

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

Следующий абзац взят из статьи:

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

Представьте себе следующий пример: у меня есть распределенная база данных только для вставки с двумя узлами A и B, и оба содержат запись [timestamp=1; id=1; value=10]. Затем, в то же время, выполняется вставка для узла A, которая приводит к [timestamp=2; id=1; value=20], и чтение для узла B для записи с id=1.

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




Ответы (1)


Я не на 100% понял, но все равно постараюсь объяснить.

Рассмотрим пример - у вас есть 2 базы данных, принимающие записи / чтения, связанные с сетевым соединением. Связь обрывается, что приводит к разделению сети. Мы хотим, чтобы наша система была доступна CAP, поэтому мы принимаем операции записи / чтения в обеих базах данных.

При работе с изменяемыми структурами данных: предположим, что клиент, подключенный к 1-й базе данных, хочет обновить значение для записи X до A, а другой клиент, подключенный ко 2-й базе данных, хочет обновить это значение до B. Поскольку наша система доступна, мы принимаем обе записи в обеих базах данных, но нам придется разрешить конфликт, как только исчезнет разделение сети. Это приведет к потере одного из обновлений.

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

person matino    schedule 06.10.2017