Модели процессов согласования реплик в базах данных Nosql

1.4.
 
 Анализ существующих моделей и методов оценки показателей 
качества функционирования баз данных NoSQL 
1.4.1.
 
Анализ методов повышения качества согласования данных 
Иногда на практике набор параметров N, W, R бывает недостаточным для 
управления согласованностью данных. Это происходит при возникновении 
необходимости повысить качество согласованности при заданном уровне 
доступности и наоборот. 

---

33 
В [40] рассматривается проблема разделения свойств безопасности и 
долговечности в распределенных хранилищах данных с использованием «
bolt-on
» 
слоя. Данный слой предполагает причинную согласованность. Причинная 
согласованность – это согласованность, основанная на причинно-следственной 
связи <случилось – до>. Таким образом, все операции записи описывают 
причинную историю. Данный подход гарантирует строгую согласованность. 
Причинные связи чаще всего описываются в двух видах: потенциальная и явная 
причинная связь. В потенциальной связи все записи, которые могут повлиять на 
другую запись, должны быть видны до того, как станет видна эта последняя 
запись. Явная причинная связь описывается в приложении. В статье [40] 
представлена архитектура 
«bolt-on»
слоя следующим образом. На каждую 
клиентскую машину предлагается установить прослойку (
shim
), содержащую 
метаданные и локальное хранилище. Клиент обращается к данной прослойке, 
которая в свою очередь обращается к хранилищу данных, согласованному в 
конечном счете. Данный слой ограничивает нарушения согласованности, которые 
может увидеть клиент. Хранилище данных ответственно за распределение 
процессов записи: для того, чтобы прочитать новые версии других процессов, 
каждый 
shim
отправляет соответствующий запрос в хранилище данных. 
Локальное хранилище содержит согласованный набор записей, с которыми могут 
проводиться операции чтения и добавления в любое время без нарушения 
ограничений безопасности. Данный набор записей обозначается как «причинная 
вырезка данных» x1→y1→z1 (causal sat). Пусть другой клиент сохранил запись 
y2→NULL. При поиске последней версии записи y2 прослойка shim должна 
убедиться, что в хранилище была запись y1. Иначе причинная связь x1→y2 будет 
утеряна. В статье описаны алгоритмы работы с shim, а также процедуры проверки 
целостности причинных связей. Предлагаемая архитектура схематически 
изображена на рисунке 1.13. 

---

34 
Рисунок 1.13 – Схема 
bolt-on
хранилища. 
Преимуществом рассмотренного подхода является повышение уровня 
согласованности 
до 
строгой 
согласованности 
благодаря 
введению 
дополнительной прослойки на клиентской машине. Недостатком является перенос 
части функций базы данных на клиентскую машину, а, следовательно, рост 
объема хранимых данных, наличие дополнительной задержки на синхронизацию 
локального и общего хранилища данных.
Такой подход можно использовать для узкого круга приложений, например, 
для уточнения целей при поиске данных. Согласованность в конечном счете (КС-
согласованность) не рассматривалась. 
В статье [41] предлагается метод 
LibRe
согласованности данных в базах 
данных NoSQL. Метод основывается на согласованности в конечном счете. 
Задача состоит в том, чтобы сочетать высокую доступность данных с высоким 
уровнем согласованности данных. Например, если N=3, W=1, R=1, то имеет место 
КС-согласованность, т.к. W+R≤ N. Подход, предлагаемый в статье, позволяет 
усилить согласованность. 
LibRe
расшифровывается как 
Library For Replication
. 
Подход заключается в следующем. Управляющий модуль 
LibRe
располагается 
рядом с балансировщиком загрузки. Балансировщик загрузки перед каждой 
операцией записи/обновления передает 
LibRe
набор узлов, на которых возможно 
выполнить операцию. После выполнения операции 
LibRe
хранит некоторое время 
информацию о том, какой узел ее выполнил. Для каждой операции чтения 
LibRe

---

35 
возвращает набор узлов, которые хранят актуальные для текущего запроса 
наборы данных. На рисунке 1.14 представлено расположение 
LibRe
в системе. 
Преимуществом 
этого 
подхода 
является 
повышение 
уровня 
согласованности 
до 
строгой 
согласованности 
благодаря 
введению 
дополнительного реестра, который некоторое время хранит информацию о том, 
на какой реплике происходило обновление той или иной записи. Недостатком 
является наличие некоторой задержки, необходимой для определения нужной 
реплики. Реестр может стать «узким местом». 
FrontEnd
Libre
Балансировщик 
загрузки
Кластер
Libre
Реестр
Менеджер извещения
Менеджер доступности
Рисунок 1.14 – Расположение 
libre
в системе. 
В работе [42] описывается механизм 
PAXOS
обеспечения согласованности в 
распределенных базах данных. Подход основывается на согласованной 
(
consensus
) репликации. Алгоритм согласования реплик в классическом варианте 
(
paxos basic)
заключается в следующем:
1.
Конкретная реплика (сервер) назначается в качестве координатора. 
2.
Координатор выбирает запись и рассылает ее всем репликам для 
подтверждения, принимающий сервер может принять запись или 
отказать. 

---

36 
3.
Как только большинство реплик приняли новую запись, согласование 
достигнуто и всем репликам высылается команда о подтверждении 
операции (
commit
). 
При необходимости пункты 1-3 могут быть повторены (из-за отказа сети). 
Координатор может также отказать. Но 
paxos 
не требует, чтобы координатор был 
единственным, в любой момент координатором может стать другая реплика.
В статье [43] предлагается метод обеспечения причинной согласованности 
со сходящейся обработкой конфликтов (CAUSAL+CONSISTENCY). Данный вид 
согласованности 
является 
расширением 
классической 
причинной 
согласованности. Классический метод причинной связи не рассматривает 
конкурирующие операции обновления, т.е. операции работы над одним ключом, 
например, put(x, a) и put(x, b). Потенциальной причинной связи между этими 
операциями нет. Следовательно, в КС-согласованной системе возможны 
конфликты и рассогласования при определенных условиях. Конфликты 
нежелательны по двум причинам: во-первых, реплики могут логически 
«разойтись», во-вторых, полученные расхождения могут логически исключать 
друг друга, что требует специальной обработки. Предложенное в [43] расширение 
классического метода заключается во введении 
сходящейся обработки 
конфликтов. 
Обработкой конфликтов занимается специальная функция h, 
запускаемая для каждой реплики. Функция должна быть коммутативной и 
ассоциативной. Сходимость заключается в равенстве результатов выполнения 
функций h(a, h(b,c)) на одной реплике и h(c, h(b, a)) - на другой, где a→b→c – 
некоторая последовательность операций обновлений и чтений (put и get).
Преимущества метода: усиление согласованности данных за счет введения 
коммутативной и ассоциативной функции обработки конфликтов. 
Недостатки: обнаружение конфликтов является сложной задачей, решение 
которой вносит существенные задержки в работу системы. Например, одним из 
трех компонентов системы обнаружения конфликтов является введение явной 
причинной связи между операциями put текущей и предыдущей версии записи, 

---

37 
что требует выполнения дополнительной операции 
dep_check 
(проверка 
зависимости).