Модель согласования версий записи в базах данных NoSQL

Список литературы

1. Новацкий В. Теория упругости. - М.: Изд. Мир, 1975.

2. Ильюшин А.А. Пластичность. Часть 1: Теория малых упруго-пластических деформаций. - М.: ГИТТЛ, 1948.

3. Халджигитов А., Каландаров А., Юсупов Ю.С., Сагдуллаева Д. Numerical modeling of the 1D thermoplastic coupled problem for isotropic materials // Вестник ТУИТ. - 2013. - Том 1/2.

МОДЕЛЬ СОГЛАСОВАНИЯ ВЕРСИЙ ЗАПИСИ В БАЗАХ ДАННЫХ NOSQL

© Цвященко Е.В.*

Московский государственный технический университет им. Н.Э. Баумана,

г. Москва

В статье представлена модель согласования версий записи в базах данных NoSQL. Модель позволяет оценить время согласования, а также число версий записи, одновременно существующих в базе данных. Представлено два варианта модели. В первом варианте время обработки пользователем версий записи рассчитывается исходя из числа версий, считанных пользователем. Во втором варианте время обработки рассчитывается на основе числа обновлений, выполненных другими пользователями между последовательными обновлениями записи текущим клиентом. Проведен натурный эксперимент в кластере до 10 узлов для доказательства адекватности модели.

Для повышения производительности и отказоустойчивости автоматизированных информационных систем (АИС) в настоящее время все чаще используются системы баз данных (БД), построенные на парадигме распределенных хранилищ «ключей / значений», получивших название NoSQL (Not-Only-SQL) [1]. В базах данных NoSQL не поддерживается режим ведения транзакций, поэтому возникает проблема согласования данных. Поддержание требуемого уровня согласованности для каждой конкретной предметной области может регулироваться параметрами (N, W, R) [2].

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

* Аспирант.

держит информацию о пользователях, выполнявших изменения данной версии записи. При чтении пользователь получает все версии записи с данным ключом, обрабатывает их и сохраняет новую версию записи, при этом старые версии удаляются из хранилища. При увеличении числа версий записи возрастает время их согласования клиентами (обработка и объединение). Задача состоит в том, что бы оценить число версий, одновременно хранящихся в системе и время их согласования. В работе [3] разработана соответствующая модель.

Распределение числа версий записи и времени их обработки сложно представить в аналитическом виде, поэтому использовался имитационный подход к моделированию [3]. Общее время работы клиента на каждой итерации чтения версий записи складывается из двух составляющих:

1. Анализ версий и обработка согласно своей роли: объединение мнений других пользователей (текущий клиент играет роль руководителя группы), добавление своих предложений (текущий клиент является рядовым членом группы) и т.д. Это время будем называть временем обработки.

2. Время, через которое пользователь возвращается к ранее откорректированной записи (документу), чтобы продолжить работу с накопившимися изменениями. Данное время обозначим как время обдумывания.

Предлагается два варианта модели. Согласно первому варианту, время обработки версий записи рассчитывается, исходя из числа версий, считанных из системы. На рис. 1 представлена схема работы модели.

Источники работы с записью

1

Т1

Массив обработки версий

записи

01

З

02

N

анять позицию в

массиве

W

Число версий

0п

Занять позицию в источнике

записи

Рис. 1. Модель обработки версий записи На рисунке 1 приняты следующие обозначения:

2

т

п

X - параметр экспоненциального закона распределения времени обдумывания клиентом (1.. .N) результатов работы с версиями записи,

Ti - момент поступления требования на чтение версий записи от i-го ис-

W

точника (клиента): i-й клиент читает W версий записей, ф = ^^ - время

i

обработки всех версий записи клиентом, £ - случайное время обработки, связанное с одной версией записи,

W - текущее число версий записи в базе данных NoSQL. Массив обработки версий записи содержит один столбец. Значение Qi -это число версий записи, которые необходимо удалить из базы данных в момент, когда i-й источник покидает фазу обработки.

Этот вариант не учитывает в явном виде, что в реальной ситуации время обработки может зависеть от числа обновлений, выполненных другими клиентами между последовательными обновлениями записи данным клиентом. Эту особенность учитывает второй вариант модели.

Модель отличается от предложенной ранее тем, что в массив обработки добавляется столбец (Ui.-.UJ, который содержит количество обновлений записи другими источниками (клиентами), выполненных между последовательными обновлениями записи данным клиентом. Время обработки рассчитывается не как сумма по W, а как сумма по Ui. Именно этот вариант был выбран для проведения экспериментов и анализа адекватности модели.

Для доказательства адекватности модели был проведен натурный эксперимент на кластере Riak [4] размером до 10 виртуальных узлов. Для проведения испытаний были арендованы виртуальные узлы, предоставленные компанией Digital Ocean [5]. Использовалась операционная система Ubuntu Server 14.04 [6], предустановленная поставщиком. Для работы с версиями записи была разработаны соответствующая прикладная программа, алгоритм работы которой представлен в работе [7].

По умолчанию сегмент системы Riak не хранит версии записей, при конфликте обновления база данных сама разрешает эти конфликты встроенными средствами, что может приводить к потере некоторых обновлений. Следовательно, помимо настройки параметров репликации для сегмента обрабатываемых данных необходимо дополнительно указать возможность хранения нескольких версий записи. Для этого используется параметр allowmult свойств сегмента.

В версии Riak выше 2.0 рекомендуется активировать параметр сегмента dvvenabled. Данный параметр отвечает за использование «точечных векторов версий» (DVV) [4]. Точечные векторы версий являются расширением вектора часов. Если несколько клиентов параллельно обновляют ключ, то обновления каждого клиента помечаются «точкой» (минимальным вектором часов), которая отражает конкретное событие, связанное с модификацией записи. При использовании точечных векторов версий гарантируется, что

количество версий, одновременно хранящихся в БД, не будет превышать число клиентов, параллельно работающих с записью. При использовании классических векторов часов такая гарантия отсутствует. Введение точечных векторов версий означает, что в Riak доступно комбинирование строгой или слабой (в конечном счете) согласованности с причинной согласованностью (потенциальная причинная связь), описанной в [8].

Для параллельной обработки клиентами версий записи была разработана соответствующая прикладная программа. Riak предоставляет библиотеки для доступа к системе на следующих языках: Java, Erlang, Pyton, Ruby, из которых была выбрана библиотека Java. Java приложения транслируются в промежуточный байт-код, который исполняется на любой виртуальной машине, что облегчило отладку приложения в среде ОС Windows.

Процесс обработки версий выполняется каждый клиентом непосредственно на узлах. В модели [3] (вариант 2) предлагалось использовать два столбца массива обработки: в первом столбце хранится число версий записи, обрабатываемых пользователем, во втором - число обновлений, выполненных другими клиентами. В соответствии с этим использовать две записи:

1. Основная запись Z. Запись используется только для управления числом версий записи, одновременно хранящихся в БД.

2. Служебная запись ZR. Запись содержит массив, аналогичный столбцу U модели обработки версий записи [3], где хранятся счетчики обновлений записи Z. Размер массива соответствует числу клиентов.

При строгой согласованности клиент всегда получает актуальную запись, но даже этот тип согласованности не может предотвратить конфликты изменения управляющей записи RZ. Это связано с тем, что при проведении натурного эксперимента запись RZ могут одновременно обновить несколько клиентов и текущий клиент получает несколько версий этой записи. Для разрешения таких конфликтов в запись RZ были добавлены два служебных поля (их описание приведено в [7]), а так же, добавлена соответствующая процедура разрешения конфликтов в прикладную программу доступа к СУБД.

Проводились четыре серии натурных экспериментов. От эксперимента к эксперименту менялись следующие параметры: число клиентов и k - коэффициент, учитывающий время обдумывания. Средняя относительная погрешность оценки с помощью модели среднего числа версий записи составила 7,5 %, дисперсии - 5,5 %, причем максимальная погрешность и по дисперсии, и по среднему значению не превышала 14 %. Получена очень небольшая погрешность оценки среднего значения времени обработки версий записи, которая составила 0,22 %.

Анализ показал, что экспериментальные и модельные значения среднего числа версий записи имеют выраженный максимум, а значения дисперсии времени обработки версий записи имеют выраженный минимум. Полу-

ченные экспериментальные данные и результаты моделирования подтверждают адекватность имитационной модели, разработанной в [3].

Список литературы:

1. NoSQL [Электронный ресурс]. - Режим доступа: http://ru.wikipe-dia.org/wiki/NoSQL (дата обращения: 03.04.2015).

2. Редмон Э., Уилсон Д. Р. Семь баз данных за семь недель. Введение в современные базы данных и идеологию NoSQL. - М.: ДМК Пресс, 2013. -384 с.

3. Григорьев Ю.А. Цвященко Е.В. Анализ процессов обработки версий записи в базах данных NoSQL // Наука и образование. - 2015. - № 1. -С. 176-188.

4. Riak documentation [Электронный ресурс]. - Режим доступа: http://docs. basho.com/index.html (дата обращения: 03.04.2015).

5. Digital Ocean [Электронный ресурс]. - Режим доступа: https://www.di-gitalocean.com (дата обращения: 22.03.2015).

6. Ubuntu OS 14.04 [Электронный ресурс]. - Режим доступа: http://re-leases.ubuntu.com/14.04 (дата обращения: 03.04.2015).

7. Цвященко Е.В.Анализ адекватности модели согласования версий записи в базах даных NoSQL // Наука и образование. - 2015. - № 3.

8. Peter Bailis, Ali Ghodsi Joseph M. Hellerstein. Ion Stoica. Bolt-on causal consistency [Электронный ресурс]. - Режим доступа: https://www.cs.berke-ley.edu/~alig/papers/bolt-on-causal-consistency.pdf (дата обращения: 03.04.2015).

ЭНАКТИВИЗМ КАК СПОСОБ УЛУЧШЕНИЯ ИСКУССТВЕННОГО ИНТЕЛЛЕКТА

© Яхимович М.Е.*, Пяткин В.В.Ф

Институт комплексной безопасности и специального приборостроения

Московского государственного университета информационных технологий, радиотехники и электроники, г. Москва

Статья посвящена рассмотрению некоторых аспектов Энактивизма как одного из наиболее перспективных подходов к построению искусственного интеллекта

Ключевые слова Энактивизм, Искусственный Интеллект, Воплощённое познание, Динамическое познание.

Энактивизм - это направление исследований, которое утверждает, что познание возникает в результате динамического взаимодействия между дей-

* Студент кафедры Прикладной и бизнес информатики.

* Доцент кафедры Прикладной и бизнес информатики, кандидат экономических наук.