CC BY
78
Наука к Образование
МГТУ им. Н.Э. Баумана
Сетевое научное издание
ISSN 1994-0408 УДК 004.657
Анализ адекватности модели согласования версий записи в базах данных NoSQL
Цвященко Е. В.^' euaene.t5Yiashchenko@gmaüxom
1МГТУ им. Н.Э. Баумана, Москва, Россия
В статье анализируется модель согласования версий записи в базах данных NoSQL. Использовался вариант модели, согласно которому, время обработки клиентом версий записи зависит в явном виде от количества обновлений, выполненными другими клиентами между последовательными обновлениями текущим клиентом. Описывается процесс подготовки и проведения натурного эксперимента в облаке для доказательства адекватности модели. Приводятся спецификации программы, с помощью которой был реализован доступ к NoSQL-системе, и программы обработки журналов. Исследовались четыре характеристики: среднее значение и дисперсия числа версий записи, среднее и дисперсия времени обработки клиентами версий записи.
Ключевые слова: база данных NoSQL, версии записи, согласованность, адекватность, адаптация, вектор часов
Введение
Для повышения производительности и отказоустойчивости автоматизированных информационных систем (АИС) в настоящее время все чаще используются системы баз данных (БД), построенные на парадигме распределенных хранилищ «ключей/значений», получивших название NoSQL (Not-Only-SQL) [1]. В базах данных NoSQL не поддерживается режим ведения транзакций, поэтому возникает проблема согласования данных. Поддержание требуемого уровня согласованности для каждой конкретной предметной области может регулироваться параметрами (N, W, R) [2].
Вне зависимости от типа согласованности, пользователи могут одновременно обновлять записи с одним и тем же ключом. Следовательно, система может хранить несколько версий данной записи. В этом случае возникает проблема обработки сразу нескольких версий (конфликт обновления). Базы данных NoSQL поддерживают механизм ведения вектора часов (Vector Clock - VC) [2] для каждой версии хранящейся в БД записи, который содержит информацию о пользователях, выполнявших изменения данной версии записи. При чтении пользователь получает все версии записи с данным ключом,
Наука и Образование. МГТУ им. Н.Э. Баумана. Электрон. журн. 2015. № 03. С. 193-206.
DOI: 10.7463/0315.0761977
Представлена в редакцию: 26.03.2015
© МГТУ им. Н.Э. Баумана
обрабатывает их и сохраняет новую версию записи, при этом старые версии удаляются из хранилища.
При увеличении числа версий записи возрастает время их согласования клиентами (обработка и объединение). В работе [3] разработана модель согласования версий записи. В статье анализируется адекватность этой модели. Для доказательства адекватности был выполнен натурный эксперимент на кластере Шак [4] размером в 10 узлов. Приводятся спецификации прикладных программ, использованных при проведении эксперимента и анализа журналов узлов для расчёта статистики.
1. Модель согласования версий записи
Распределение числа версий записи и времени их обработки сложно представить в аналитическом виде, поэтому использовался имитационный подход к моделированию [3]. Общее время работы клиента на каждой итерации чтения версий записи складывается из двух составляющих:
1. Анализ версий и обработка согласно своей роли: объединение мнений других пользователей (текущий клиент играет роль руководителя группы), добавление своих предложений (текущий клиент является рядовым членом группы) и т.д. Это время будем называть временем обработки.
2. Время, через которое пользователь возвращается к ранее откорректированной записи (документу), чтобы продолжить работу с накопившимися изменениями. Данное время обозначим как время обдумывания.
Авторами [3] предложены два варианта модели. Согласно первому варианту, время обработки версий записи рассчитывается, исходя из числа версий, считанных из системы. Этот вариант не учитывает в явном виде, что в реальной ситуации время обработки может зависеть от числа обновлений, выполненных другими клиентами между последовательными обновлениями записи данным клиентом. Эту особенность учитывает второй вариант модели, именно он использовался для оценки адекватности. Предложенные алгоритмы работы модели были реализованы в среде ОРББ [5]. Данное инструментальное средство моделирования параллельных процессов имеет встроенные механизмы сбора статистики, построения гистограмм, а также большой набор стандартных числовых атрибутов (СЧА), использование которых облегчает анализ. Например, для блока таблицы существуют СЧА математического ожидания и среднего квадратичного отклонения случайной величины. В качестве функции распределения вероятностей времени обработки клиентом одного обновления записи использовалась функция, обратная функции ОРББ [3]. Плотность соответствующей функции распределения является двугорбой со средним значением, равным 5.5.
2. Описание экспериментальной установки
На рынке существует множество компаний, предоставляющих облачные вычислительные ресурсы. Ресурсы бывают виртуальными и выделенными. Выделенными облачными ресурсами (узлами) являются узлы, которым соответствуют физически отдельные серверы. В отличие от выделенных узлов, виртуальные узлы - это виртуальной машины. Выделенные серверы стоят существенно дороже, поэтому в нашем эксперименте использовались виртуальные узлы, предоставленные компанией DigitalOcean (DO) [6]. Т.к. время ожидания требованием на чтение оценивается при работе пользователя с одной парой <ключ/значение>, то база данных NoSQL существенно не нагружает оперативную память (ОП), что позволяет арендовать недорогие серверы с малым объемом ОП.
Все узлы, предоставляемые поставщиком облачных ресурсов, основаны на многопроцессорных машинах с SSD дисками. Это позволяет сделать предположение, что другие клиенты DO, которым предоставлены виртуальные узлы на том же физическом сервере, не будут нагружать именно тот процессор, на котором запущена наша виртуальная машина. При инициализации узла доступно несколько опций, среди которых можно выделить опцию private networking. При включении данной опции все узлы, арендованные пользователем, гарантированно находятся в одном центре обработки данных (ЦОД), что означает небольшую задержку при передаче данных внутри кластера Riak.
При первоначальной настройке узла (Droplet) необходимо выбрать операционную систему (ОС) или снимок, ранее созданный пользователем. Использовалась операционная система Ubuntu Server 14.04 [7], предустановленная поставщиком. Для установки и настройки Riak необходимо выполнить ряд действий на каждом из (N+1) узлов. Установка Riak «с нуля» требует много времени, поэтому для ускорения подготовки кластера общая часть действий по инсталляции системы, описанных в [4], была выполнена один раз на одном узле. Далее был сделан снимок узла, который впоследствии устанавливался на остальных узлах. Индивидуальная часть действий по настройке Riak, описанная в [4], была сохранена в качестве bash-скрипта. Данные скрипты являются Linux аналогом bat-скриптов для ОС Windows. После установки и настройки системы все узлы необходимо соединить в кластер, для чего предусмотрены следующие команды Riak:
1. riak-admin cluster join riak@<ip_first_node>;
2. riak-admin cluster plan;
3. riak-admin cluster commit.
Команда 1 выполняется на каждом узле, кроме одного, к которому присоединяются остальные узлы (ip_first_node). После выполнения команды 1 необходимо проверить конфигурацию кластера на любом из узлов командой 2, после чего сохранить изменения с помощью команды 3. После выполнения всех команд кластер будет готов к работе, однако, необходимо некоторое время для переноса уже хранящихся данных из первого узла во все остальные. В течение этого времени система может отвечать not found на запросы клиентов. Т.к. исследуются версии записей, а точнее - их количество и время
обработки, будем использовать сильную согласованность при работе с записью <ключ/значение> (R+W>N). Настройки согласованности для каждого эксперимента задавались следующим образом: (N,W,R)=(3, 3, 1).
По умолчанию сегмент системы Riak не хранит версии записей, при конфликте обновления база данных сама разрешает эти конфликты встроенными средствами, что может приводить к потере некоторых обновлений. Следовательно, помимо настройки параметров репликации для сегмента обрабатываемых данных необходимо дополнительно указать возможность хранения нескольких версий записи. Для этого используется параметр allow_mult свойств сегмента. В версии Riak выше 2.0 также рекомендуется активировать параметр сегмента dvvenabled. Данный параметр отвечает за использование «точечных векторов версий» (DVV) [4]. Точечные векторы версий являются расширением вектора часов. Если несколько клиентов параллельно обновляют ключ, то обновления каждого клиента помечаются «точкой» (минимальным вектором часов), которая отражает конкретное событие, связанное с модификацией записи. При использовании точечных векторов версий гарантируется, что количество версий, одновременно хранящихся в БД, не будет превышать число клиентов, параллельно работающих с записью. При использовании классических векторов часов такая гарантия отсутствует.
Введение точечных векторов версий означает, что в Riak доступно комбинирование строгой или слабой (в конечном счете) согласованности с причинной согласованностью (потенциальная причинная связь), описанной в [8].
3. Подготовка эксперимента
Для параллельной обработки клиентами версий записи была разработана соответствующая прикладная программа. Riak предоставляет библиотеки для доступа к системе на следующих языках: Java, Erlang, Pyton, Ruby, из которых была выбрана библиотека Java. Java приложения транслируются в промежуточный байт-код, который исполняется на любой виртуальной машине, что облегчило отладку приложения в среде ОС Windows.
Процесс обработки версий выполняется каждый клиентом непосредственно на узлах. В модели [3] (вариант 2) предлагалось использовать два столбца массива обработки: в первом столбце хранится число версий записи, обрабатываемых пользователем, во втором - число обновлений, выполненных другими клиентами. В соответствии с этим предлагается использовать две записи:
1. Основная запись Z. Запись используется только для управления числом версий записи, одновременно хранящихся в БД.
2. Служебная запись ZR. Запись содержит массив, аналогичный столбцу U модели обработки версий записи [3], где хранятся счетчики обновлений записи Z. Размер массива соответствует числу клиентов. Для доступа к массиву будем использовать обозначение ZR.array[i], где i - индекс клиента (начинается с нуля).
Согласно модели время обработки одной версии записи и время обдумывания значительно превышают время обновления записи и считывания ее из системы, что позволяет пренебрегать этими небольшими задержками. Одна условная единица работы модели GPSS принималась равной 10 мс в натурном эксперименте.
Т.к. используется строгая согласованность, то клиент всегда получает актуальную запись, но даже этот тип согласованности не может предотвратить конфликты изменения управляющей записи Это связано с тем, что при проведении натурного эксперимента запись RZ могут одновременно обновить несколько клиентов и текущий клиент получает несколько версий этой записи. Для разрешения таких конфликтов необходимо добавить в запись два служебных поля: RZ.operation - тип операции, выполняемой клиентом перед сохранением этой записи: 0 - клиент обнулил свой счетчик обновлений записи Z, 1 - клиент увеличил счетчики обновлений записи Z на единицу для других клиентов; RZ.clientIndex - индекс клиента, который выполнил изменение записи RZ.
Алгоритм разрешения конфликтов при работе с записью RZ.
Вход: список версий записи RZ_S, считанных из БД, CLIENT_C - число клиентов-1. Выход: RZ_R - результирующая запись RZ. Алгоритм:
ЦИКЛ по количеству элементов массива i = 0..CLIENT_C ЕСЛИ НЕ 3 K : RZ_S[K].dientIndex==i, то // ьй клиент не изменял запись RZ
КОНЕЦ ЕСЛИ
TMP_COUNT = RZ_S[K].array[i] ДЛЯ каждой версии RZ[j] из RZ_S
ЕСЛИ ] != K л RZ[j].operation == 1
// другой клиент изменил счетчик обновлений ьго клиента
TMP_COUNT++ КОНЕЦ ЕСЛИ КОНЕЦ ДЛЯ
RZ_R.array[i] = TMP_COUNT КОНЕЦ ЦИКЛА ВЕРНУТЬ RZ_R
При проведении натурного эксперимента каждый клиент (узел) в цикле читает версии записи Z, обрабатывает их и сохраняет уже одну версию этой записи (результат обработки) в базе данных. Но в базе данных могут сохраняться и другие версии записи Z, обновлённые другими клиентами.
Алгоритм процесса обработки версий записи Z.
Вход: LOOP_TIME - время работы клиента; INDEX - индекс клиента, используется для сохранения в рабочей записи ZR; k - коэффициент, используемый для расчета среднего времени обдумывания клиентом результатов работы с версиями записей в каждом цикле, CLIENT_C - количество клиентов (-1). Алгоритм:
T_A = 5.5k10 // среднее время обдумывания в миллисекундах. L = 1/T_A // параметр экспоненциального закона распределения вероятностей времени обдумывания. ЦИКЛ пока не истечет интервал времени LOOP_TIME T = EXPONENTIAL(L)
ЗАДЕРЖАТЬ процесс на время T // обдумывание СЧИТАТЬ из БД запись Z // клиент получает все версии записей СЧИТАТЬ из БД запись RZ COUNT = RZ.array[index] + 1 // количество обновлений записи Z, выполненных другими клиентами за время обдумывания и обработки версий записи Z текущим клиентом за предыдущий цикл, плюс одно обновление текущим клиентом TIME = 0
ЦИКЛ по количеству обновлений COUNT
TIME += случайное время обработки одного обновления (см. ниже)
КОНЕЦ ЦИКЛА
RZ.array[index] = 0 // клиент обработал все обновления записи Z RZ.operation = 0, RZ.clientlndex = INDEX СОХРАНИТЬ в БД запись RZ ЗАПИСАТЬ в журнал время TIME
ЗАДЕРЖАТЬ процесс на время TIME // обработка версий записи СОХРАНИТЬ в БД запись Z СЧИТАТЬ из БД запись Z
ЗАПИСАТЬ в журнал число версий записей Z (W) СЧИТАТЬ из БД запись RZ
ЦИКЛ по количеству элементов массива i = 0..CLIENT_C ЕСЛИ i ф INDEX
RZ.array[i]++ // увеличить счетчики обновлений для других клиентов КОНЕЦ ЕСЛИ КОНЕЦ ЦИКЛА
RZ.operation = 1, RZ.clientIndex = INDEX
СОХРАНИТЬ в БД запись RZ КОНЕЦ ЦИКЛА
Алгоритм определения случайного времени обработки одного обновления
(используется для расчета времени обработки версий записи TIME).
Вход: функция
{Xi,Yi}={0,0/0.125,10/0.375,20/0.5,30/0.625,80/0.875,90/1.0,100}, обратная функции распределения; Выход: значение случайной величины Алгоритм:
P = получить случайное число, равномерно распределённое на отрезке [0,1] ЕСЛИ Xi<P<Xi+i, ТО ^=Yi+i(Xi+i) //значение в правом конце интервала, при P=0 положить ^=0.
После завершения всех процессов обработки версий записи, необходимо скопировать журналы узлов Riak на локальную машину для расчёта статистик - оценки математического ожидания и дисперсии числа версий записи и времени их обработки.
Алгоритм оценки математического ожидания и дисперсии числа версий записи и времени их обработки.
Вход: LOGS - файлы журналов процессов обработки версий записи. Алгоритм:
VA = 0 // математическое ожидание числа версий VD = 0 // дисперсия числа версий
TA = 0 // математическое ожидание времени обработки версий TD = 0 // дисперсия времени обработки версий COUNT = V = V2 = T = T2 = 0 // счетчики ДЛЯ каждого журнала LOG_I из LOGS
ДЛЯ каждой записи <W> и <TIME> из LOG_I TIME/= 10 // перевести мс в условные единицы V += W, V2 += W2 T += TIME, T2 += TIME2 COUNT++ КОНЕЦ ДЛЯ КОНЕЦ ДЛЯ VA = V / COUNT TA = T / COUNT VD = V2 / COUNT - VA2 TD = T2 / COUNT - TA2
4. Проведение эксперимента и анализ адекватности модели
Перед проведением каждого эксперимента необходимо включить в БД запись Z (одну версию обрабатываемой записи). Также необходимо включить в БД запись RZ с обнуленными счетчиками обновления.
Проводились четыре серии натурных экспериментов. В табл. 1 приведены значения изменяемых параметров (число узлов-клиентов и k -коэффициент, учитывающий время обдумывания [3]), результаты натурных и модельных экспериментов, а также относительная погрешность моделирования средних значений и дисперсии числа версий записи.
Таблица 1. Результаты экспериментов для версий записи
Эксперимент Модель Относительная погрешность моделирования
Клиенты к Среднее Дисперсия Среднее Дисперсия Среднее Дисперсия
5 0.5 3,386 1,225 3,027 1,326 0,106 0,083
0.8 3,340 1,244 3,134 1,311 0,061 0,053
1 3,292 1,231 3,140 1,302 0,046 0,057
3 2,862 1,183 2,766 1,202 0,033 0,016
5 2,527 1,085 2,445 1,077 0,033 0,008
10 0.5 5,996 3,446 5,160 3,765 0,139 0,092
0.8 6,232 3,402 5,630 3,725 0,097 0,095
1 6,266 3,416 5,777 3,674 0,078 0,076
3 6,243 3,367 5,551 3,417 0,111 0,015
5 5,092 3,200 4,941 3,233 0,030 0,010
15 0.5 8,112 6,445 7,094 6,757 0,125 0,048
0.8 8,707 6,293 7,893 6,780 0,094 0,077
1 8,865 6,206 8,223 6,648 0,072 0,071
3 8,720 5,853 8,494 6,115 0,026 0,045
5 7,862 5,715 7,711 5,838 0,019 0,021
20 0.5 10,655 9,485 8,686 10,117 0,185 0,067
0.8 11,225 9,841 9,936 10,236 0,115 0,040
1 11,498 9,160 10,541 10,084 0,083 0,101
3 11,754 8,635 11,428 9,207 0,028 0,066
5 10,879 8,460 10,638 8,875 0,022 0,049
Средняя относительная погрешность оценки с помощью модели среднего числа версий записи составляет 7,5%, дисперсии - 5,5%, причем максимальная погрешность и по дисперсии, и по среднему значению не превышает 14%.
В табл. 2 приведены значения изменяемых параметров (число узлов-клиентов и к), результаты натурных и модельных экспериментов, а также относительная погрешность моделирования средних значений и дисперсии времени обработки версий записи клиентом.
Таблица 2. Результаты экспериментов для времени обработки версий записи.
Эксперимент Модель Относительная погрешность моделирования
Клиенты к Среднее Дисперсия Среднее Дисперсия Среднее Дисперсия
5 0.5 27,447 237,833 27,492 365,047 0,002 0,535
0.8 27,490 218,830 27,497 283,004 0,000 0,293
1 27,471 219,891 27,501 261,279 0,001 0,188
3 27,431 233,971 27,498 261,608 0,002 0,118
5 27,550 283,378 27,493 308,962 0,002 0,090
10 0.5 55,784 962,539 54,999 1357,020 0,014 0,410
0.8 55,651 738,978 54,973 966,663 0,012 0,308
1 54,998 665,468 54,976 863,092 0,000 0,297
3 55,046 672,620 54,974 697,959 0,001 0,038
5 54,852 749,271 54,990 813,408 0,003 0,086
15 0.5 82,555 2130,697 82,458 2927,299 0,001 0,374
0.8 82,527 1645,066 82,458 2058,403 0,001 0,251
1 82,477 1461,800 82,495 1750,024 0,000 0,197
3 82,605 1186,659 82,497 1234,146 0,001 0,040
5 82,501 1351,175 82,491 1403,810 0,000 0,039
20 0.5 109,986 3645,831 109,985 5366,950 0,000 0,472
0.8 109,882 2742,223 109,988 3589,280 0,001 0,309
1 109,894 2885,739 109,985 2975,542 0,001 0,031
3 109,969 1855,456 110,000 1910,426 0,000 0,030
5 109,918 2011,905 109,986 2059,277 0,001 0,024
Средняя относительная погрешность оценки на модели среднего значения времени обработки версий записи составляет 0,22%, дисперсии - 20,6%.
Ниже показаны зависимости средних значений УЛ (рис. 1а) и дисперсий УО (рис. 1б) от к для различного числа клиентов.
Из рис. 1 видно, что как экспериментальные, так и модельные значения среднего числа версий записи имеют выраженный максимум и мало отличаются. Дисперсии также почти совпали.
—5_экс -ИО_экс —15_экс -^20_экс -^5_мод ^Н10_мод —Н15_мод — 20_мод
—5_экс -НОэкс —— —^ 5_мод -^10_мод ^Н15_мод — 20_мод
a) б)
Рис. 1. Зависимость числа версий записи от k для различного числа клиентов: а) среднее значение; б) дисперсия.
Ниже показаны зависимости средних значений TA (рис. 2а) и дисперсий TD (рис. 2б) от k для различного числа клиентов.
^ б) Рис. 2. Зависимость времени обработки версий от k для различного числа клиентов: а) среднее значение; б) дисперсия.
Из рис. 2 видно, что средние значения времени обработки практически совпали (для эксперимента и модели). А экспериментальные и модельные значения дисперсии времени обработки версий записи имеют выраженный минимум.
Всё это свидетельствует об адекватности модели, т.к. кривые на рис. 1 и 2 мало отличаются по форме.
Заключение
1. Проведены четыре серии экспериментов для оценки адекватности модели согласования версий записи (вариант 2 модели [3]) в базах данных NoSQL. Натурные эксперименты проводились в облачном кластере в 10 узлов, предоставленном компанией Digital Ocean.
2. Приведены алгоритмы работы прикладных программ для проведения экспериментов и расчета средних значений и дисперсий числа версий записи, а также времени их обработки.
4. Проанализирована адекватность модели (см. табл. 1 и 2). Средняя относительная погрешность оценки среднего числа версий записи составила 7,5%, дисперсии - 5,5%. Получена очень небольшая погрешность оценки среднего значения времени обработки версий записи, которая составила 0,22%.
5. Из графиков, приведённых на рис. 1 и 2, видно, что и экспериментальные, и модельные значения среднего числа версий записи имеют выраженный максимум, а значения дисперсии времени обработки версий записи имеют выраженный минимум.
6. Полученные экспериментальные данные и результаты моделирования подтверждают адекватность имитационной модели, разработанной в [3].
Список литературы
1. NoSQL. Википедия: Свободная энциклопедия. Режим доступа: http://ru.wikipedia.org/wiki/NoSQL (дата обращения 09.03.2015).
2. Редмон Э., Уилсон Д.Р. Семь баз данных за семь недель. Введение в современные базы данных и идеологию NoSQL: пер. с англ. М.: ДМК Пресс, 2013. 384 с.
3. Григорьев Ю.А., Цвященко Е.В. Анализ процессов обработки версий записи в базах данных NoSQL // Наука и образование. МГТУ им. Н.Э. Баумана. Электрон. журн. 2015. № 1. С. 176-188. DOI: 10.7463/0115.0753706
4. Riak documentation: website. Режим доступа: http://docs.basho.com/index.html (дата обращения 09.03.2015).
5. GPSS World Reference Manual // Minuteman Software: website. Режим доступа: http://www.minutemansoftware.com/reference/reference_manual.htm (дата обращения 09.03.2015).
6. Digital Ocean: website. Режим доступа: https://www.digitalocean.com (дата обращения 09.03.2015).
7. Ubuntu OS 14.04 // Ubuntu Releases: website. Режим доступа: http://releases.ubuntu.com/14.04 (дата обращения 09.03.2015).
8. Bailis P., Ghodsi A., Hellerstein J.M., Stoica I. Bolt-on causal consistency // Berkeley EECS (Electrical Engineering and Computer Science): website. Режим доступа: https://www.cs.berkeley.edu/~alis/papers/bolt-on-causal-consistency.pdf (дата обращения 09.03.2015).
Science and Education of the Bauman MSTU, 2015, no. 03, pp. 193-206.
DOI: 10.7463/0315.0761977
Received:
26.03.2015
Science^Education
of the Bauman MSTU
I SS N 1994-0408 © Bauman Moscow State Technical Unversity
Model Adequacy Analysis of Matching Record Versions in Nosql Databases
E.V. Tsviashchenko1' ''eu3ene.t5~riashchenkoiggmail.com
1Bauman Moscow State Technical University, Moscow, Russia
Keywords: NoSQL database, record versions, consistency, adequacy, adaptation, vector clock
The article investigates a model of matching record versions. The goal of this work is to analyse the model adequacy. This model allows estimating a user's processing time distribution of the record versions and a distribution of the record versions count. The second option of the model was used, according to which, for a client the time to process record versions depends explicitly on the number of updates, performed by the other users between the sequential updates performed by a current client. In order to prove the model adequacy the real experiment was conducted in the cloud cluster. The cluster contains 10 virtual nodes, provided by DigitalOcean Company. The Ubuntu Server 14.04 was used as an operating system (OS). The NoSQL system Riak was chosen for experiments. In the Riak 2.0 version and later provide "dotted vector versions" (DVV) option, which is an extension of the classic vector clock. Their use guarantees, that the versions count, simultaneously stored in DB, will not exceed the count of clients, operating in parallel with a record. This is very important while conducting experiments. For developing the application the java library, provided by Riak, was used. The processes run directly on the nodes. In experiment two records were used. They are: Z - the record, versions of which are handled by clients; RZ - service record, which contains record update counters. The application algorithm can be briefly described as follows: every client reads versions of the record Z, processes its updates using the RZ record counters, and saves treated record in database while old versions are deleted form DB. Then, a client rereads the RZ record and increments counters of updates for the other clients. After that, a client rereads the Z record, saves necessary statistics, and deliberates the results of processing. In the case of emerging conflict because of simultaneous updates of the RZ record, the client obtains all versions of that record and merges their information using a special algorithm. There were conducted 4 series of experiments with 5 ones in each. From experiment to experiment the following parameters were changed: clients count and k - an attitude of the average deliberation time to the average processing time of one update. An average relative error of the average record versions count was 7.5%; dispersion was 5.5%. An average processing time error of the record versions was estimated very small, i.e. 0. 22%.
References
1. NoSQL. Wikipedia, the free encyclopedia. Available at: http://ru.wikipedia.org/wiki/NoSQL , accessed 09.03.2015.
2. Redmond E., Wilson J.R. Seven Databases in Seven Weeks:A Guide to Modern Databases and the NoSQL Movement. Pragmatic Bookshelf, 2012. (Russ. ed.: Redmond E., Wilson J.R. Sem' baz dannykh za sem' nedel'. Vvedenie v sovremennye bazy dannykh i ideologiyu NoSQL. Moscow, DMK Press, 2013. 384 p.).
3. Grigor'ev Yu.A., Tsvyashchenko E.V. Analysis of Handling Processes of Record Versions in NoSQL Databases. Nauka i obrazovanie MGTU im. N.E. Baumana = Science and Education of the Bauman MSTU, 2015, no. 1, pp. 176-188. DOI: 10.7463/0115.0753706
4. Riak documentation: website. Available at: http://docs.basho.com/index.html , accessed 09.03.2015.
5. GPSS World Reference Manual. Minuteman Software: website. Available at: http://www.minutemansoftware.com/reference/reference_manual.htm , accessed 09.03.2015.
6. Digital Ocean: website. Available at: https://www.digitalocean.com , accessed 09.03.2015.
7. Ubuntu OS 14.04. Ubuntu Releases: website. Available at: http://releases.ubuntu.com/14.04 , accessed 09.03.2015.
8. Bailis P., Ghodsi A., Hellerstein J.M., Stoica I. Bolt-on causal consistency. Berkeley EECS (Electrical Engineering and Computer Science): website. Available at: https://www.cs.berkeley.edu/~alig/papers/bolt-on-causal-consistency.pdf , accessed 09.03.2015.
