Noclone модель и протоколы взаимодействия с семантическими объектами баз данных в многопользовательских приложениях Текст научной статьи по специальности «Компьютерные и информационные науки»

УДК 004.051

А. Н. Родионов \ О. В. Решетникова 2

1 Вычислительный центр ДВО РАН ул. Ким Ю Чена, 65, Хабаровск, 680000, Россия

2 Дальневосточный государственный университет путей сообщения ул. Серышева, 47, Хабаровск, 680021, Россия

[email protected]

ШСЬОЖ МОДЕЛЬ И ПРОТОКОЛЫ ВЗАИМОДЕЙСТВИЯ С СЕМАНТИЧЕСКИМИ ОБЪЕКТАМИ БАЗ ДАННЫХ В МНОГОПОЛЬЗОВАТЕЛЬСКИХ ПРИЛОЖЕНИЯХ

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

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

Введение

Источники идентичных записей в таблицах баз данных

Могут ли в базе данных появиться записи (кортежи), представляющие одну и ту же сущность? Да, могут. И это в целом рядовая, типичная ситуация. Такие данные принято называть дубликатами (клонами), а ограничение их числа - одна из актуальных задач моделирования данных и процессов их обработки. Дубликаты - следствие, с одной стороны, сходства разных семантических названий, которые могут использоваться для обозначения одной и той же сущности (далее для краткости - дубликаты первого типа), а с другой - побочный эффект работы многопользовательского приложения, в котором взаимодействие с базой данных организовано в соответствии со стратегией отсоединенного доступа (дубликаты второго типа) (рис. 1)

Заметим, что обозначенная проблема имеет место только, если в качестве идентификаторов записей используется атрибут, представляющий собой первичный суррогатный ключ. Такой, например, как атрибут «Id_name», представленный на рис. 1. Назначение семантических атрибутов («Name») в качестве первичных ключей по определению исключает возникновение дубликатов второго рода.

Родионов А. Н., Решетникова О. В. №зС1оие модель и протоколы взаимодействия с семантическими объектами баз данных в многопользовательских приложениях // Вестн. Новосиб. гос. ун-та. Серия: Информационные технологии. 2015. Т. 13, вып. 2. С. 64-75.

ISSN 1818-7900. Вестник НГУ. Серия: Информационные технологии. 2015. Том 13, выпуск 2 © А. Н. Родионов, О. В. Решетникова, 2015

Names (Имена)

Id name Name

1 Вероника п

2 Наталья

3 Наталия Г,

4 наталья п

5 Анастасия п

6 Анастасия >\

7 Анастасия г7

Дубликаты 1-го рода

Дубликаты ¡f-го рода

Рис. 1. Дубликаты в семантической таблице базы данных

Применение функциональных зависимостей соответствия [1] и различных метрик, указывающих на близость семантических названий [2], позволяет успешно производить поиск дубликатов первого рода и тем самым заранее предварять их возможное появление в базе данных.

В настоящей работе исследуются и решаются задачи исключения или ограничения числа дубликатов второго типа. Область применения предлагаемых протоколов распространяется только на класс таблиц, в которых хранится либо только семантическая информация, как, например, в таблице «Имена» (см. рис. 1), либо на группу таблиц, представляющих сущности предметной области в базах данных - Pattern, Sample и Instance-таблицы [3]. Проблема дубликатов документальных и иных категорий структур в работе не рассматривается.

Алгоритмы исключения дубликатов второго рода

Основная причина, приводящая к появлению идентичных записей, принадлежащих второму типу, - использование отсоединенной стратегии доступа клиентских приложений к базе данных. Идея, лежащая в основе отсоединенного доступа, предельно проста: клиент по своему запросу получает нужные ему данные от сервера и работает с ними в автономном (отсоединенном) режиме. По мере необходимости клиент взаимодействует с сервером, чтобы обновить, вставить или удалить какие-то данные, не информируя о своих действиях других клиентов. По сути, на стороне клиента находится копия части базы данных, гарантированно синхронизированная с серверной частью только в момент получения этой части или обновления последней.

При подобном способе взаимодействия клиентов с сервером в процессе работы нескольких клиентских приложений, если не предпринимать специальных действий, данные, хранящиеся на сервере, и данные клиентов с высокой степенью вероятности будут находиться в рассогласованном состоянии. Наглядным подтверждением сказанному может служить схема (рис. 2), иллюстрирующая одновременную вставку новых записей в одну из таблиц базы данных двумя клиентскими приложениями.

От клиентов на сервер пересылаются запросы, содержащие сведения о новых записях, подлежащих вставке (действия 11 и 12). Поступающие запросы формируют очередь. После выполнения текущего запроса из очереди (действия 21 и 22) в клиентские приложения возвращаются (действия 31 и 32) уникальные идентификаторы (ID) - значения так называемого суррогатного ключа, которые получили записи, размещенные в таблице базы данных.

Рис. 2. Взаимодействие серверной таблицы и ее клиентских копий в процессе вставки новых записей

Рис. 3. Структурная схема КоС1оие-протоколов взаимодействия клиентов с сервером

Вставка новой записи, равно как и получение ею ГО, предполагает обязательное монопольное блокирование серверной таблицы. В противном случае, при параллельном доступе, возвращаемый ГО может оказаться принадлежащим аналогичной записи, вставку которой произвел другой клиент.

Очевидно, что ничто не препятствует клиентам добавить в СТ одну и ту же сущность с разными ГО, но совпадающими значениями всех других атрибутов. Ведь клиенты не осве-

домлены о подобных намерениях друг друга. Появление, например, трех идентичных кортежей r5, r6 и r7, показанных на рис. 1, - следствие описанных действий.

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

Определимся с критерием эффективности протоколов и введем ряд временных параметров, которые далее понадобятся для отражения существенных характеристик процессов размещения новых записей.

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

Интервал времени, в котором клиентская копия модифицируемой таблицы находится в статичном, не актуализированном, состоянии, обозначим как \tn, tc ], где tn - момент времени окончания предпоследнего обновления, tc - момент времени начала текущего обновления.

В соответствии с обоими протоколами процедуру вставки (или модификации) данных в СТ предваряет обязательная проверка на наличие в СТ аналогичных записей, которые ранее (в промежутке \tn, tc ]) могли быть размещены в ней другими клиентами.

Далее представим реализацию протоколов средствами СУБД MS SQL: операторами Transact-SQL и операторами языка программирования, встроенного в MS SQL.

Два запроса в составе хранимой процедуры (листинг 1) - запрос на проверку в таблице «Names» (атрибут «Name») значения, идентичного значению, содержащемуся в переменной @Msg, и непосредственно запрос на вставку содержимого @Msg, который производится, если первый запрос вернул False, выполняются последовательно в одном блоке - блоке «поиска-вставки», оформленном как транзакция. Начало блока предваряет получение права (строка 4 листинга 1) на монопольное использование модифицируемой таблицы (устанавливается монопольная блокировка). Соответственно, по завершении запросов, образующих блок, монопольная блокировка снимается (строка 11). (Отказ от монопольного блокирования может привести к тому, что другие клиенты после выполнения проверочного запроса произведут размещение дублирующих записей.)

Листинг 1. Хранимая процедура, содержащая «проверочный» запрос и запрос на вставку новой записи в таблицу «Names»

1. Begin

2. Set Transaction Isolation Level Serializable;

3. Begin Transaction;

4. Select Id_name From Names Where Name = Cast ( @Msg As Char(10));

5. If (@@Rowcount > 0) Send On Conversation @Dlghandle Message Type [Prot1] (Cast(Id_name As Integer))

6. Else Begin

7. Insert Into Names(Name) Values ( Cast ( @Msg As Char(10)));

8. Select Id_name From Names Where Id_name=SCOPE_IDENTITY();

9. Send On Conversation @Dlghandle Message Type [Prot1] (Cast(Id_name As Integer));

10. End;

11. Commit Transaction;

12. End

Описанные действия составляют содержание первого протокола.

Согласно второму протоколу, запросам на проверку и вставку предшествует запрос (листинг 2) на получение всех обновлений в периоде \tn, tc ]. Это позволяет в случае обнаружения дубликатов не инициировать запросы блока «поиска-вставки».

Листинг 2. Поиск обновлений в таблице «Names»

1. Begin

2. Set Transaction Isolation Level Repeatable Read;

3. Declare @Msg_T Rowvwersion=Convert(Rowvwersion, Substring(Cast(@Msg As Char(18)),1,8))

3. Select Name From Names Where TimeStamp > @Msg_T;

4. If (@@Rowcount = 0) Send On Conversation @Dlghandle Message Type [Prot2] (Cast('0' As Integer))

5. Commit Transaction;

6. End

Обязательным условием выполнения данного запроса является включение в таблицу, где производится поиск дубликатов, служебного атрибута, область определения которого - тип данных (множество) Timestamp / rowversion. В нашем случае это будет атрибут «TimeStamp», который следует добавить в определение таблицы «Names». Атрибут, которому поставлен в соответствие этот тип данных, хранит время последнего обновления (вставки) текущей строки [4]. Значение обновляется автоматически системой управления базой данных.

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

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

Пусть Qc с Q, где Q - множество элементов, образующих очередь; Qc - подмножество, содержащее два или более одинаковых элемента (кортежа); с - индекс множества; C - количество Qc. (Кортежи одинаковы, если значения всех их атрибутов, кроме атрибута суррогатного ключа, совпадают.) Количество дубликатов Nd в очереди в этом случае определится как Nd c C (Ц -1^, где Qc| - мощность подмножества Qc.

На рис. 4 показано два варианта подмножеств записей, подлежащих вставке и содержащих одинаковое число дубликатов - по 3 в каждой очереди.

Однозначно утверждать, какой из протоколов (1 или 2) предпочтительнее по критерию t только на основании представленных соображений, нельзя. Нужны количественные оценки t, полученные или в процессе наблюдения за работой реальной информационной системы, или в результате проведения экспериментов с моделью, замещающей реальную систему.

Формулирование модели

Ранее мы определились с выходным параметром модели t . Входных параметров, от которых зависит t, несколько. Это мощность обновляемой таблицы M, измеряемая числом кортежей (записей), содержащихся в ней, длина транзакционной очереди L и характеристика смеси транзакций в очереди B = TElTA, определяемая как отношение числа транзакций, монопольно блокирующих таблицу TE к общему числу всех транзакций в очереди TA. Число транзакций, размещающих разделяемую блокировку, может быть рассчитано как разница между длиной очереди и числом транзакций, запрашиваемых монопольную блокировку. Заметим, что для первого протокола B = 1.

Имитация размещения новых noclone записей может быть сведена к выполнению двух последовательных шагов: формированию транзакционных очередей с различными значениями B и непосредственного выполнения всех транзакций, образующих очередь. Представленная схема моделирования соответствует поставленной задаче - получить сравнительные оценки t для рассматриваемых протоколов - и не требует предварительного исследования структуры потоков заявок (запросов), поступающих от пользователей (клиентов), и построения системы массового обслуживания, наиболее уместной в данном случае.

По этой же причине организация моделируемых протоколов (рис. 5) несколько отличается от той, что была показана на рис. 1. Из ее состава исключены совпадающие блоки (в частности, блоки обмена данными между клиентом и сервером), а также блок проверки условия наличия клона в первом протоколе ввиду того, что продолжительность вставки tа много

меньше продолжительности поиска t* (ta ■ t* ).

Запишем выражения, позволяющие произвести расчет t. Для первого протокола tl может

У ( +ta )

г" ^ ~ ^^ i=1 — L V г г / тт 7~»

быть найдено как tl =--• Для второго протокола, с учетом B:

tii =

У ,=1+L tU У i=U(L-L-B) + ta )

L L - L - B

где tU - продолжительность поиска обновлений в модифицируемой таблице.

Рис. 5. Организация моделирующих протоколов

я

я

я

я

я

я

Н'

\У

УУ

Я

я

я

IV

(С

УУ

к

я

я

я

XV

я

я

н

я

я

ГУ

я

Л!-чтение Начались

б

Рис. 6. Варианты структур транзакционных очередей с минимальным (а), средним (б) и максимальным (в) временем ожидания

а

в

Рис. 7. Наиболее вероятные структуры очередей для заданных значений В

Еще одним существенным фактором, который, наряду с ранее перечисленными, может оказывать влияние на I, является структура (организация) очереди, отражающая мощности чередующихся транзакций на чтение и запись. Несколько вариантов организации очередей, иллюстрирующих существенное различие во времени их выполнения, показаны на рис. 6. Предполагается (согласно постановке задачи), что все транзакции в очереди - конкурирующие (обращаются к одним и тем же таблицам базы данных).

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

Для целей настоящего исследования фактор организации очереди имеет значение только для протокола № 2. В этой связи, поскольку рассматривается стохастическая система (заявки на вставку поступают в случайные моменты времени с одинаковой вероятностью), необходимо определиться со структурой моделируемой очереди.

Очевидно, что «недубликаты», требующие монопольного блокирования, будут располагаться в очереди выше, чем транзакции, «отвечающие» за размещение дублирующих записей. Наиболее вероятные структуры очередей с различными значениями В показаны на рис. 7. Очередь разбита на сегменты, число которых равно ТЕ. Каждый сегмент начинается

с транзакции, обеспечивающей вставку новой записи. Далее при реализации модели использовалась представленная организация.

Вычислительный эксперимент

Для целей настоящего исследования важно не только сформировать очередь определенной длины, состоящей из чередующихся транзакций, но и сделать ее частью среды выполнения. В качестве последней использовалась СУБД MS SQL, в которой инструменты непосредственного синтеза очередей отсутствуют. Сказанное повлекло разработку программного модуля (рис. 8), имитирующего работу многопользовательского приложения, производящего массовую, одновременную вставку новых записей в таблицу базы данных. Названный модуль включает клиентскую часть - Client Module, реализованную средствами языка программирования С# среды разработки MS Visio Studio, и один из сервисов MS SQL - Service Broker. Представим краткое описание работы приложения.

Транзакции генерируются методом PleerInstance, входящим в состав клиентского модуля. Моделирование параллельности их поступления достигается за счет создания вторичных потоков (по одному потоку на каждую транзакцию). Транзакции передаются сервисному брокеру для постановки в очередь (компонент Queue), по завершении формирования которой вызывается хранимая процедура QueueProcessing (см. рис. 8), выполняющая все транзакции, включенные в очередь. Продолжительность реализации очереди рассчитывается как разность tstart и tfinish , фиксируемых в блоках QuestItem и AnswerItem соответственно.

Рис. 8. Структура приложения, имитирующего размещение новых записей в таблицах баз данных

12000

и 0,5 1,0 и 1,5 1,6 1,7 1,8 1,9 2,0 2,! 22 23 2,4 2,5

Мощность таблицы, млн. записей

Рис. 9. Влияние длины транзакционной очереди L и мощности модифицируемой таблицы Mна t

Среднее значение времени выполнения всех транзакций в очереди t оценивалось с вероятностью 0,954 попадания t в 10-процентный интервал: t -1/10 < t < t +?/10. На основании экспериментальных данных, полученных для исходной серии из 20 экспериментов, и выражения n = (cxZal2 )21'd2, где n - размер выборки, g - среднеквадратическое отклонение, Zal2 -

двусторонняя нормальная стандартная статистика, d - половина ширины доверительного интервала, итерационно рассчитывался требуемый n (в сторону увеличения в случае необходимости).

Эксперименты выполнялись на компьютере со следующими характеристиками: тип - x64-based PC, процессор - Intel(R) Core (TM)2 Duo CPU E8400 @ 3.00 GHz, 3.003 GHz, ядер - 2, логических процессоров - 2, объем оперативной памяти - 4 ГБ.

На рис. 9 приведены экспериментальные данные, полученные в ходе реализации первого протокола и иллюстрирующие зависимость t от числа заявок в очереди L и мощности отношения M (таблицы), в которую производится вставка.

Увеличение t с ростом M и L ожидаемо, чего нельзя сказать о непропорционально растущем t по отношению к увеличивающемуся L. Это можно наблюдать на примере семейства зависимостей t = f (M,L) (см. рис. 9), которые получены после аппроксимации представленных экспериментальных данных. Было бы логично, если бы, например, при увеличении L в 3, 5 и 7 раз во столько же раз увеличивалось и t. Однако этого не наблюдается:

L = 30/ Ф ^=3с/ • /L = 10* /dM'

L = 50/ Ф ¿L»/ • /L = 10 /dM'

L = 70/ ф ^=7й/ /L = 10 /dM.

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

На всех последующих рисунках (рис. 10-12) изображены данные, характеризующие работу второго протокола. На кривые, полученные для разных значений B, «наложена» зависимость t = f (M,L = const), описывающая первый протокол. Точки пересечения последней

с отдельными fn = f (M, L, B) помечены прописными символами русского алфавита. Эти точки - маркеры, позволяющие произвести сравнительную двух протоколов.

си ЦО и 1,6 2,0 2,1 11 2.5 2,4

МОИШОСЛ* ГЭбЛКИЫ, мл Л. '111И1Ч .1

Рис. 10. Зависимость Г = f (L = 10,M) и семейство зависимостей Г = f (L = 10,M,B) с фиксированными значениями B

Рис. 11. Зависимость Г = f (L = 30,M) и семейство зависимостей 1 = f (L = 30,M,B) с фиксированными значениями В

Рис. 12. Зависимость Г = / (L = 50,М) и семейство зависимостей 1 = / (L = 50,М,В) с фиксированными значениями В

Так, например, для очереди, включающей 10 транзакций (см. рис. 10), второй протокол предпочтительнее использовать, когда:

. В = 10/* В /10'

. В = АЫ > 2,1 -106' * В = а Ы > 1-106.

Аналогичные данные могут быть получены на основании представленных графиков для L = 30 и L = 50 (см. рис. 11 и 12 соответственно).

Существенные колебания t , наблюдаемые при росте M, объясняются особенностями внутренней логики работы MS SQL сервера, функционирующего на многоядерной архитектуре, когда невозможно точно смоделировать ситуацию задействования сервером дополнительных ядер в процессе реализации очереди. Тем не менее, несмотря на выявленный разброс t, явно просматривается тренд на возрастание t с ростом параметров Ы и L.

Заключение

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

Наше исследование, что не является исключением, поставило ряд новых вопросов в этой области, в том числе и концептуального плана.

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

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

1. Shaoxu S., Chen L. Efficient discovery of similarity constrain for matching dependencies // Data and knowledge engineering. 2013. Vol. 87. Р. 146-166.

2. Bilenko Ы., Mooney R., Cohen W. W., Ravikumar P., Fienberg S. E. Adaptive name matching in information integration // IEEE Intelligent Systems 2003. Vol. 18 (5). P. 16-23.

3. Родионов А. Н. Семантическая идентификация, конфигурирование и моделирование типов сущностей в моделях данных // Вестн. Новосиб. гос. ун-та. Серия: Информационные технологии. 2014. Т. 12, вып. 1. С. 64-78.

4. Вьейра Р. SQL Server 2000. Программирование. М.: БИНОМ. Лаборатория знаний, 2004. 735 с.

Материал поступил в редколлегию 13.05.2015

A. N. Rodionov O. V. Reshetnikova 2

1 Computer Center FEB RAS 65, Kim Yu Chen Str., Khabarovsk, 680000, Russian Federation

2 Far Eastern State Transport University 47, Serysheva Str., Khabarovsk, 680021, Russian Federation

[email protected]

NOCLONE MODEL AND THE PROTOCOLS OF INTERACTIONS WITH DATABASE SEMANTIC OBJECTS IN MULTIUSER APPLICATIONS

This paper proposes two alternative protocols, which eliminate an appearance of duplicates in applications with centralized databases. By an experiment it is obtained the dependencies of the execution mean time for the transactions that insert or modify records into semantic or entity's database tables. The dependences variables are presented by the table cardinality, the transaction queue length and the characteristic of the transaction blend. The later is defined as the ratio of the exclusive lock transactions to the total transactions in the queue. The boundaries of these protocols for utilizing in database applications are determined.

Keywords: first and second type duplicates, duplicate elimination, transaction queue, concurrent transaction blend, semantic and entity's database tables.

References

1. Shaoxu S., Chen L. Efficient discovery of similarity constrain for matching dependencies. Data and knowledge engineering, 2013, vol. 87, p. 146-166.

2. Bilenko M., Mooney R., Cohen W. W., Ravikumar P., Fienberg S. E. Adaptive name matching in information integration. IEEE Intelligent Systems, 2003, vol. 18 (5), p. 16-23.

3. Rodionov A. N. Semantic identification, configuration and entities types modeling for the data model engineering. Vestnik of Novosibirsk State University. Series: Information Technologies, 2014, vol. 7, no. 1, p. 31-36.

4. Vieira R. Professional SQL Server 2000 Programming. Moscow, BINOM. Knowledge laboratory, 2004, 735 p.