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

3.4.
 
Анализ адекватности модели (3) процесса ведения версий записи 
3.4.1.
 
Подготовка эксперимента 3 
Описание подготовки натурного эксперимента 3 и его результаты 
опубликованы в [92, 99]. В модели процесса ведения версий записи (вариант 2, 
см. пункт 2.3.4) предлагалось использовать два столбца массива обработки: в 
первом столбце хранится число версий записи, обрабатываемых клиентом, во 
втором – число обновлений, выполненных другими клиентами между
последовательными обновлениями записи данным клиентом. В соответствии с 
этим при проведении натурного эксперимента предлагается использовать две 
записи:
1.
Основная запись Z, она используется только для хранения числа версий 
записи, одновременно хранящихся в БД. 
2.
Служебная (вспомогательная) запись RZ. Она содержит массив, 
аналогичный столбцу U модели обработки версий записи, где хранятся 
счетчики обновлений записи Z. Размер массива соответствует числу 
клиентов. Для доступа к массиву будем использовать обозначение 
RZ.array[i], где i – индекс клиента (начинается с нуля). 
Согласно модели время обработки обновлений записи базы данных и время 
обдумывания значительно превышают время ввода/вывода этой записи, что 
позволяет пренебречь этими небольшими задержками. Одна условная единица 
работы модели GPSS принималась равной 10 мс в натурном эксперименте. 
При использовании строгой согласованности, клиент всегда получает 
актуальную запись, но даже этот тип согласованности не может предотвратить 
конфликты, связанные с изменениями вспомогательной записи RZ. Это связано с 
тем, что при проведении натурного эксперимента запись RZ могут одновременно 
обновлять несколько клиентов и текущий клиент получает несколько версий этой 
записи. Для разрешения таких конфликтов необходимо добавить в запись RZ два 

---

107 
служебных поля: RZ.operation – тип операции, выполняемой клиентом перед 
сохранением этой записи: 0 – клиент обнулил в RZ свой счетчик обновлений 
записи Z, 1 – клиент увеличил в RZ счетчики обновлений записи Z на единицу для 
других клиентов; RZ.clientIndex – индекс клиента, который выполнил изменение 
записи RZ. 
Алгоритм разрешения конфликтов при работе с записью RZ. 
Вход: список версий записи RZ_S, считанных из БД, CLIENT_C – число 
клиентов. Выход: RZ_R – результирующая запись RZ (первоначально все поля 
нулевые).