|
1.3.3.
Ведение версий реплики и их согласование
Отсутствие блокировок позволяет одновременно читать и изменять одну и
туже запись базы данных на разных узлах. Это приводит к конфликтам, которые
разрешаются или штатными средствами NoSQL, или вручную.
Первым, самым простым способом разрешения конфликтов является
использование временной метки, которой снабжается каждая запись. При
возникновении конфликтов предпочтение отдается самой новой записи. Но, как
отмечается в [18], такой подход сложно реализовать в кластере узлов.
Вторым способом разрешения конфликтов является ведение версий записи,
реализуемое с помощью
вектора часов
(Vector Clock – VC) [14, 26]. Вектор часов
28
– это последовательность пар <пользователь, номер версии записи для этого
пользователя>, которая описывает порядок обновления этой записи.
D(A
1
[1])
Запись D добавлена
пользователем A
1
D (A
1
[2])
Запись D обновлена
пользователем A
1
D
1
(A
1
[2],A
2
[1])
Запись D обновлена
пользователем A
2
одновременно с A
3
Запись D cогласована и
обновлена
пользователем A
1
Запись D обновлена
пользователем A
3
одновременно с A
2
D
2
(A
1
[2],A
3
[1])
D(A
1
[3],A
2
[1],A
3
[1])
Рисунок 1.12 – Пример ведения вектора часов.
На рисунке 1.12 показан пример ведения вектора часов (в скобках показан
вектор часов записи). Запись D (например, какой-то документ) обновляется
пользователями A
1
, A
2
, A
3
. Первые два обновления выполняются пользователем
A
1
последовательно. Далее пользователи A
2
, A
3
одновременно читают и
обновляют эту запись (случайное совпадение). В базе данных сохраняются две
версии записи: D
1
и D
2
. При чтении документа D пользователю A
1
возвращаются
две версии записи с одним и тем же ключом (D1 и D2). Он вносит изменения,
например, объединяет обновления, выполненные пользователями A
2
, A
3
. В базе
сохраняется одна согласованная версия записи с вектором часов, включающим
идентификаторы трех пользователей.
Преимущества вектора часов: отсутствие единой точки отказа системы, т.к.
при использовании временных меток в записях необходимо выполнять точную
синхронизацию времени с одним эталоном.
Недостатки
вектора часов: отсутствие возможности автоматически
разрешать конфликты, а также увеличение длины вектора часов при
29
многократном обновлении записи. Однако в NoSQL существуют механизмы
усечения вектора часов. Например, в системе Riak можно задавать частоту
обрезания вектора на уровне сегмента, а также максимальный размер (длину)
вектора часов [19].
Следующий подход устранения конфликтов заключается в создании
невременной метки (это может быть хеширование содержимого, GUID, счетчик и
т.д.), которая возвращается пользователю вместе с требуемыми данными из СУБД
[4]. После выполнения изменений пользователем система сравнивает значение
метки, полученное от пользователя, с тем, которое хранится в базе данных. Если
значения не совпадают, операция отклоняется. Пользователь должен вновь
прочитать и обновить запись. Данный подход используется в системе CouchDB
[30].
Приведем примеры рассогласования данных, приводящие к появлению
нескольких версий записи, и способы их устранения:
Несколько сотрудников одновременно корректируют экземпляр одного
и того же документа (записи) – например, предложение по развитию
предприятия; разрешение рассогласованности – объединение (выбор)
корректировок руководителем группы.
Несколько экспертов одновременно оценивают экземпляр одного и того
же документа – например, blind-оценка статьи, поданной на
конференцию; разрешение рассогласованности – выбор оценки
председателем комиссии.
Несколько сотрудников одновременно работают с одним экземпляром
документа, причем один сотрудник может видеть результаты работы
другого сотрудника – например, несколько авторов работают над одной
статьей; может появиться несколько версий записей, рассогласованность
устраняет руководитель группы авторов.
Пользователи обсуждают какое-либо одно событие в блоге.
При многофазной обработке запроса по технологии MapReduce
выходные данные одной фазы являются входными данными другой
30
фазы – например, при выполнении операции Join при доступе к
структурированным данным или при выполнении сложных запросов в
поисковых системах (реплики входных данных следующей фазы могут
быть рассогласованы); эту рассогласованность устраняет NoSQL
(согласованность, основанная на потенциальной причинно-следственной
связи).
Приложение генерирует последовательность связанных записей, они
сохраняются в репликах не одновременно и в другой временной
последовательности – например, результаты индексации документов в
поисковых системах; рассогласованность реплик устраняет NoSQL
(согласованность, основанная на явной причинно-следственной связи).
Из приведенных выше примеров видно, что обеспечение согласованности
очень важно для стабильной и правильной работы системы. Одновременная
работа приводит к конфликтам, которые могут быть разрешены, например,
руководителем группы на основе вектора часов. Знание оценки окна
рассогласованности способствовало бы в этой ситуации предотвращению
конфликтов.
В случае многофазной обработки рассогласованности быть не должно, т.к.
выходные данные одной фазы используются как входные данные другой. Знание
задержки реакции системы при обеспечении строгой согласованности позволяет
выполнить точную оценку времени выполнения всего многофазного задания.
При одновременной работе большого числа пользователей с одной записью
базы данных число версий этой записи может быть велико. Поэтому возникает
задача оценки нагрузки на пользователя в зависимости от числа пользователей,
одновременно работающих с записью: оценка числа версий записи, времени их
обработки пользователем и др. По результатам этих оценок можно дать
рекомендации о максимально возможном числе пользователей, одновременно
принимающих участие в обсуждении.
31
Do'stlaringiz bilan baham: |
