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

2.3.
 
Разработка модели процесса ведения версий записи 
Рассмотрен процесс ведения версий записи с использованием вектора часов 
как один из способов разрешения конфликтов, вызванных отсутствием 
блокировок в базах данных NoSQL. Показано, что возникает задача оценки 
нагрузки на пользователя в зависимости от числа пользователей, одновременно 
работающих с записью. 
2.3.1.
 
Ведение вектора часов в базах данных NoSQL
При отсутствии механизма блокировок записей БД пользователи NoSQL 
могут читать, а потом одновременно обновлять запись с одним и тем же ключом. 
В этом случае система будет хранить несколько версий данной записи. Возникает 
проблема согласования версий (конфликт обновления). Базы данных NoSQL 
поддерживают механизм ведения вектора часов (Vector Clock - VC) для каждой 

---

65 
хранящейся в БД версии записи, который содержит информацию о пользователях, 
выполнявших изменения данной версии записи. При чтении пользователь 
получает все версии записи с данным ключом, обрабатывает их и сохраняет 
новую версию записи, при этом старые версии удаляются из базы данных. При 
увеличении числа версий записи возрастает время их согласования клиентами 
(просмотр и объединение).
Векторные часы – это последовательность пар <пользователь, номер версии 
записи для этого пользователя>, которая описывает порядок обновления этой 
записи. Рассмотрим механизм ведения вектора часов на примере базы данных 
Riak [19]. Ниже приведены алгоритмы формирования векторных часов и 
обновления записей, описанные в [14, 18]. 
Пусть {A
i
} – множество идентификаторов пользователей (клиентов), 
обновляющих записи базы данных. Рассмотрим два варианта. 
Случай 1
. Пользователь A
m

{A
i
} добавляет новую запись. Для этой записи 
база данных установит следующий вектор часов: VC= A
m
[1], где 1 – номер версии 
записи для пользователя A
m
. 
Случай 2
. Пользователь A
m
читает запись по ключу, а затем обновляет ее. 
Ниже приведены алгоритмы формирования вектора часов и обновления записи в 
базе данных для этого случая (алгоритмы 1 и 2). 
1.
Алгоритм 1 формирования вектора часов VC новой версии записи. 
Вход: A
m
– идентификатор пользователя, который читает запись, VC
n
= 
{Ai[j]}
n
- вектор часов прочитанной пользователем A
m
n-ой версии записи (при 
чтении пользователь A
m
получает все версии записи с тем же ключом), {VC
n
} – 
множество векторов часов всех n версий записи, хранящихся в базе данных.