CC BY
35
Оригинальная статья / Original article УДК: 004.652
DOI: 10.21285/1814-3520-2016-12-91-100
ОБЗОР АРХИТЕКТУРЫ И ПРИНЦИПОВ ОРГАНИЗАЦИИ НЕРЕЛЯЦИОННОЙ СУБД ПК ВИКТА
© А.М. Андрианов1, В.М. Илюшечкин2, П.Ю. Чумаченко3, Е.Л. Федотова4
Национальный исследовательский университет « Московский институт электронной техники», 124498, Российская Федерация, г. Москва, г. Зеленоград, пл. Шокина, 1.
РЕЗЮМЕ. ЦЕЛЬ. Целью данного исследования является определение возможностей и ограничений нереляционной СУБД ПК ВИКТА (программный комплекс ВИКТА). МЕТОДЫ. Использовался метод сравнительного анализа архитектуры СУБД и сравнение результатов натурных экспериментов. РЕЗУЛЬТАТЫ. Приведены результаты второго этапа исследования отечественной среды быстрой разработки приложений ПК ВИКТА. На первом этапе исследовалась архитектура ПК ВИКТА, кроме исследования оригинальной СУБД. В данной статье представлены выводы о возможностях и ограничениях данной СУБД. Приведены результаты экспериментов по тестированию быстродействия базы данных по сравнению с некоторыми аналогами и решениями на реляционных СУБД. ЗАКЛЮЧЕНИЕ. Установлена высокая скорость и компактность СУБД ПК ВИКТА при использовании в программах. Ключевые слова: базы данных, нереляционная база данных, ПК ВИКТА, архитектура баз данных, проектирование баз данных.
Формат цитирования: Андрианов А.М., Илюшечкин В.М., Чумаченко П.Ю., Федотова Е.Л. Обзор архитектуры и принципов организации нереляционной СУБД ПК ВИКТА // Вестник Иркутского государственного технического университета. 2016. Т. 20. № 12. С. 91-100. DOI: 10.21285/1814-3520-2016-12-91-100
REVIEW OF NON-RELATIONAL DBMS VIKTA PC ARCHITECTURE AND ORGANIZATION PRINCIPLES A.M. Andrianov, V.M. Ilyushechkin, P.Yu. Chumachenko, E.L. Fedotova
National Research University of Electronic Technology,
1, Shokin Square, Zelenograd, Moscow, 124498, Russian Federation.
ABSTRACT. The PURPOSE of this study is determination of capabilities and limitations of non-relational database management system (DBMS) VIKTA PC ("VIKTA Program Complex"). METHODS. The method of the comparative analysis of DBMS architecture and the comparison of results of full-scale experiments is used. RESULTS. The results of the second stage of researching the domestic rapid application development environment PC VIKTA are given. The first stage was devoted to the study of VIKTA PC architecture excluding the research of the original DBMS. This article provides the conclusions on the capabilities and limitations of the discussed DBMS, as well as presents the results of experiments on testing of DBMS operation speed in comparison with some analogs and solutions in relational DBMS. CONCLUSION. The VIKTA PC DBMS is characterized with high speed and compactness when used in programs. Keywords: databases, non-relational database, VIKTA PC, database architecture, database design
For citation: Andrianov A.M., Ilyushechkin V.M., Chumachenko P.Yu., Fedotova E.L. Review of non-relational DBMS VIKTA PC architecture and organization principles. Proceedings of Irkutsk State Technical University. 2016. vol. 20. no. 12, pp. 91-100. (In Russian) DOI: 10.21285/1814-3520-2016-12-91-100
1
Андрианов Андрей Михайлович, кандидат технических наук, преподаватель кафедры информатики и программного обеспечения вычислительны систем, e-mail: andymailru@mail.ru
Andrei M. Andrianov, Candidate of technical sciences, Lecturer of the Department of Information Science and Computer System Software, e-mail: andymailru@mail.ru
2Илюшечкин Владимир Михайлович, кандидат технических наук, профессор кафедры информатики и программного обеспечения вычислительны систем.
Vladimir M. Ilyushechkin, Candidate of technical sciences, Professor of the Department of Information Science and Computer System Software.
3Чумаченко Павел Юрьевич, кандидат технических наук, доцент кафедры информатики и программного обеспечения вычислительны систем.
Pavel Yu. Chumachenko, Candidate of technical sciences, Associate Professor of the Department of Information Science and Computer System Software.
4Федотова Елена Леонидовна, кандидат технических наук, доцент кафедры информатики и программного обеспечения вычислительных систем.
Elena L. Fedotova, Candidate of technical sciences, Associate Professor of the Department of Information Science and Computer System Software.
information Science, Computer Engineering and Management
Введение
На сегодняшний момент широко распространены реляционные базы данных (БД), которые состоят из таблиц, связанных между собою по полям уникальных идентификаторов. Такие БД хорошо себя зарекомендовали на практике. Однако в последнее время в связи с постоянно ускоряющимся ростом объема и сложности данных постепенно набирают популярность нереляционные БД, с которыми связывают надежды по упрощению работы с большими данными [1, 2]. Такие БД, как правило, иностранного происхождения. В статье
Сравнение архитектуры СУБД ВИКТА
Современные реляционные СУБД -это, как правило, отдельный продукт, имеющий встроенный интерфейс взаимодействия с внешними по отношению к нему прикладными приложениями. Этот интерфейс реализуется, как правило, на базе общепринятого языка структурированных запросов - SQL. Эти СУБД могут быть платными (MS SQL, Oracle) или бесплатными (MySQL, Postrgess SQL). Платные, как правило, позиционируются как решения для высоко нагруженных проектов и имеют соответствующий инструментарий. Наличие полей уникальных идентификаторов записей позволяет построить полную базу данных приложения еще до написания кода самого приложения, которое будет ее использовать. Под полной базой здесь понимается возможность связать все данные будущего приложения так, что только по этой структуре уже можно достаточно полно представить потребности будущего приложения (рис. 1).
СУБД ПК ВИКТА отличается от распространенных профессиональных реляционных СУБД отсутствием в архитектуре понятия уникального идентификатора записи в том смысле, в котором он широко распространен в реляционных СУБД. Поэтому в СУБД ВИКТА нельзя напрямую выполнить запрос, аналогичный «SELECT * from 'table' where 'ID' = ... ».
рассматривается принципиальная архитектура отечественной нереляционной базы данных программного комплекса ВИКТА (ПК ВИКТА) [3].
Авторы ставили перед собой цель определить возможности и ограничения нереляционной СУБД ПК ВИКТА.
Материалом для исследования являются СУБД ПК ВИКТА и реляционные БД на примере MySQL, которые исследуются посредством анализа архитектуры и сравнительных нагрузочных экспериментов.
с архитектурой реляционных БД
Уникальный идентификатор записи в СУБД ВИКТА формируется из значений так называемых реквизитов записи (что такое реквизиты, будет подробнее описано ниже). Если же применить аналогию с реляционной СУБД, то уникальность записи определяется набором ее данных в определенных полях таблицы. Например, пусть для этой цели выделены поля «NAME» и «EMAIL». Тогда не может быть двух записей с одинаковыми данными в полях «NAME» и «EMAIL». При этом другие поля записей могут иметь одинаковые значения. В некоторых реляционных базах также можно создавать уникальные идентификаторы (ключи) из нескольких полей (например MySQL), однако это рекомендуется применять только для оптимизации узкоспециальных запросов, в то время как в СУБД ВИКТА - это одна из основ всей технологии БД.
На первый взгляд такое решение должно замедлить работу при обращении к конкретной записи, так как быстрее всего ее можно выбрать по уникальному номеру, а не поиском по значению полей, не говоря уже о неудобстве указания двух и более полей, вместо одного уникального идентификатора. Но более детальное рассмотрение вопроса показало, что получение данных конкретной записи в интерфейсе прикладного приложения происходит, как правило, в результате выбора из списка, воз-
Пример организации связи данных в реляционной БД I
An example of data relationships organization in a relational database (DB)
users u s ers_to_p lace_wo r k
ID ID_WORK
FIO 1 D_N AM E_WO RK —
places_work
ID_WORK ID
... NAME
Связи могут быть полностью описаны внутри структуры БД I Relationships can be given a complete description within the DB structure
Рис. 1. Типовая схема связей реляционной БД Fig. 1. Standard diagram of relational DB relationships
вращенного некой предыдущей операцией. В СУБД ВИКТА записи этого списка неявно содержат позицию записи в файле БД (рис. 2). Эта позиция не является идентификатором записи, это ее положение (по сути - номер строки) от начала файла БД. Поскольку позиция записи в файле извест-
на, то выбор значения записи для подробного просмотра или редактирования (если это нужно) происходит мгновенно. Очевидно, что данное решение в архитектуре БД было продиктовано наблюдением за реальной практикой использования прикладных приложений.
Рис. 2. Физическое содержание записи в БД ВИКТА Fig. 2. Physical content of a record in VIKTA DB
Information Science, Computer Engineering and Management
Естественным является желание считать номер строки записи в файле БД ВИКТА уникальным идентификатором. Однако этого нельзя делать. В СУБД ВИК-ТА может быть несколько экземпляров одной и той же по сути записи, но с «исторически разными данными». Это вторая особенность СУБД ВИКТА. Записи изменяются не по месту их расположения, а измененные записи всегда дописываются в конец БД. Никаких операций с записью, послужившей источником для изменений, не производится. Поэтому операция «UPDATE» в СУБД ВИКТА производится быстрее, а в таблицы интерфейса прикладного приложения выбираются уже только последние записи. Этот подход также позволяет совершить в любой момент откат (и просмотр) всей БД на определенную дату и даже час и секунду. Поскольку
такой способ выполнения обновлений записей приводит к росту БД за счет устаревших данных, разработчиками ПК ВИКТА предусмотрена операция компрессирования базы, которая позволяет удалить все устаревшие данные до определенной даты.
Вместо понятия «поля» таблицы (записи), в СУБД ВИКТА применяется понятие «реквизиты» (рис. 3). Реквизиты в чем-то схожи с полями таблицы реляционной СУБД. Особенности реквизитов таковы:
1. Реквизиты могут содержать только простые типы данных: int, char и т.д.
2. Комбинация значений обязательных реквизитов составляет уникальный ключ записи.
3. Реквизиты описываются в конфигурационном файле БД.
4. По реквизитам могут быть построены ключи для быстрого поиска.
XML файл с описанием БД / XML file with a DB description
Общий список реквизитов ПК ВИКТА
К£К1_то1__RU_СПКомпьютер__Осно вное130206
nom_sklad_R и_спком пьюгер_основное 13П206
nomnoin_R U_СПКомпьютер_Основное 130206
Общие справочники ПК ВИКТА
ЦеныКЛАМАРа_RU_СПКомпьютер_Основное! 30206
и, aiHçrJ решиэнг-ге
1 Cip.LJL.kuni_ALI_С ИКочпькнрер._Осмаем»13[)2К
(Bfl¥Bm_RU_СПКампьцчр_Сечоим i 2С309 -
rS'j._i3nUМП._RU_С Ih'.uJ.Kï.l'i_с;úhийнuf 1 ÎP?nG
_.. Q_с V « гiK' *!>__рммм* ЭОКв
Файл справочника / Help file
typ_<Jokum_.. nomnom_.. date_reg_ ...
данные данные
данные данные
данные данные
данные данные
данные данные
Файл БД прикладного приложения/ Application DB file
Kocf_mol_ nomnom_.. typ_dokum_...
данные данные
данные данные
данные данные
данные
данные данные
Выборка данных в приложении / Data access in an application
kod_mol_... lyp_(tokiim_.....
данные данные
данные данные
данные данные
данные данные
данные данные
Рис. 3. Схема использования понятия «реквизиты» в БД ВИКТА для построения БД Fig. 3. Diagram of using the concept of "attributes" in VIKTA DB for DB creation
Физически файл справочника ничем не отличается от БД приложения, но справочники могут использоваться разными приложениями. Таким образом, получается возможность повторного использования данных, например справочников типов бухгалтерских документов, единиц измерений и т.д.
Связь полей таблицы в пользовательском интерфейсе с файлами (таблицами) справочников осуществляется статическим и динамическим связыванием. Статическое связывание осуществляется в специальном хт1-файле, и привязанные таким образом справочники становятся доступны для использования во всех таблицах, представляющих запись. Динамиче-
ское связывание позволяет добавить к виду таблицы колонку с выбором из справочника в коде фрейма. Внешне вызовы обоих типов не различаются и открывают справочник одинаково (рис. 4).
В записи БД нет ссылки на файл справочника, а содержится выбранное значение. Например, Название=«Шпроты с овощами». Это позволяет быстро формировать таблицу результатов. Ссылка на файл справочника, которая приводит к его открытию для выбора значения, описывается либо в коде обработчика таблицы (фрейма) при динамическом связывании, либо в хт1-файле статических связей при статическом связывании.
Рис. 4. Демонстрация динамического связывания данных в табличном интерфейсе пользователя
со справочником
Fig. 4. Demonstration of dynamic data linking in the user's table interface with a reference
Information Science, Computer Engineering and Management
Рассмотрение архитектуры СУБД ВИКТА показывает «заточенность» базы на обеспечение максимальной скорости работы для задач, характерных для определенного класса учетных систем.
Важным практически значимым следствием из архитектуры СУБД ВИКТА является возможность многократного снижения потребностей в ресурсах при бэка-пировании данных, что может быть актуальным, например, для компаний, предоставляющих услуги хостинга сайтов. По договору такие компании обычно обязываются выполнять ежедневное бэкапирование данных с обязательством хранить архивы 10-14 дней. Сравним эффективность хранения для традиционного подхода и на СУБД ВИКТА.
Обозначим за 1 размер БД. Для упрощения примем, что в БД не добавляются новые записи, а только изменяется 10% записей.
При традиционном подходе через 14 дней будем иметь 15 полных копий БД (рис. 5). Для БД ВИКТА достаточно к копии
на файл-сервере бэкапов дописывать в конец изменения текущего дня, а на сервере БД выполнять компрессирование. В результате получим 1 + 1 + 0,1*14 = 3,4. Таким образом, БД ВИКТА требуется в 15/3,4 = 4,4 раза меньший объем жестких дисков. Преимущество БД ВИКТА будет тем больше, чем меньшее количество данных обновляется.
Нельзя сказать, что механизм пор-тирования обновлений совсем не используется в реляционных СУБД. Такой механизм - репликация - есть. Однако он требует достаточно тонкой настройки средствами самой СУБД и применяется для проектов с высокой степенью ответственности, где даже потеря данных за несколько минут уже может быть критична. В этом случае правильно иметь почти идентичные копии БД, тогда в случае краха одной, практически мгновенно подключается вторая. Для большинства же сайтов используется механизм полной копии, так как он весьма прост.
Рис. 5. Сравнение традиционного бэкапирования БД и возможности бэкапирования в ПК ВИКТА Fig. 5. Comparison of the traditional DB backup and the backup possibility in VIKTA PC
Необходимо сказать несколько слов об устройстве СУБД ВИКТА в случае, когда приложение является сетевым и с одной БД работают несколько операторов. Важно отметить, что в этом случае каждый оператор имеет полную копию БД, т.е. нет одной БД, к которой обращаются все операторы, а есть столько копий БД, сколько операторских мест. При этом СУБД ПК ВИКТА автоматически обеспечивает механизм синхронизации данных и разрешение случая взаимных блокировок. Важно отметить, что как
таковых блокировок в классическом смысле в СУБД ВИКТА вообще нет [4]. Операторы могут одновременно прочитать запись, так как у каждого своя копия БД. Но вот записать одновременно они уже не могут, поскольку записываются сохраняемые данные оператора, пославшего их на сохранение первым. Оператору предлагается уже либо отменить сохранение записи, измененной другим пользователем, либо взять обновленные данные этой записи.
Тестирование быстродействия БД ВИКТА
Всего проводилось два специальных эксперимента.
Первый эксперимент. В 2010 г. ООО «Аймэн», (http://www.aimen.ru/), являющееся Microsoft Gold Certified Partner, проводило сравнительное тестирование приложений типа «Заработная плата», разработанных на платформе Microsoft и на платформе ПК ВИКТА. Тестирование показало почти 30-кратное превосходство в скорости решения на базе ПК ВИКТА: 30-40 секунд у ПК ВИКТА против 15-16 минут у Microsoft для решения задачи расчета заработной платы. По итогам тестирования был составлен протокол о намерениях, который, к сожалению, тогда не перерос в договор сотрудничества по не зависящим от СП-Компьютер причинам.
Также в протоколе были отмечены следующие особенности ПК ВИКТА (в 2010 он имел название СП^50), важные в части БД:
1. Программная оболочка СП^50 -готовый программный продукт, предназначенный для создания автоматизированных информационных систем. По своему составу и функциональным возможностям СП^50 не уступает имеющимся на рынке отечественным и зарубежным аналогам. Кроме того, в программной оболочке реализован ряд оригинальных решений.
2. В системе реализована уникальная технология распределенной базы данных, что позволяет решать задачу масштабирования путем простого добавления ра-
бочих станций к системе по мере роста нагрузки и числа одновременно работающих пользователей. Одновременно с этим наличие распределенной базы данных позволяет также решить и задачу отказоустойчивости системы в целом за счет отсутствия централизованного места хранения данных и наличия встроенных механизмов синхронизации.
Второй эксперимент. Второй эксперимент проводился в январе 2016 года для сравнения быстродействия СУБД ВИК-ТА и реляционной БД MySQL. Для эксперимента был составлено 2 справочника. Первый содержал 100 тыс., второй 300 тыс. записей мест работы сотрудников. Каждый сотрудник мог иметь до 3-х мест работы. В эксперименте выбирались 1000 сотрудников с местом работы, совпадавшим в контексте с некоторым шаблоном.
Трудность задачи состояла в том, что место работы не однозначно. Нужно выбрать всех, кто работал, например, в МГУ ВМиК. Может быть, все 3 места сотрудника отвечают заданному требованию, может, - одно. Например, МГУ ВМиК нужно искать в контексте Поле «аааа бббб МГУ ВМиК оооо» и в «МГУ ВМиК ннн» оба отвечают поставленному требованию.
Тестирование проводилось на компьютерах сравнимой мощности. MySQL был развернут на базе пакета 1С-Битрикс Web-окружение, который включал также развертывание web-сервера. Запросы к MySQL выполнялись как из php-файла, так
Information Science, Computer Engineering and Management
потом и напрямую командами из консоли, чтобы исключить влияние потерь времени на передачу запросов через Apache-PHP.
Результаты выполнения ПК ВИКТА составили 2 секунды (+78 миллисекунд) (рис. 6.)
Результаты выполнения запросов на БД MySQL составили от 31 до 41 секунды (рис. 7-8.). Выполнение этих же запросов
прямыми командами консоли к MySQL показало рост скорости в среднем не более чем на 1-3 секунды. В среднем выполнение запроса в MySQL можно оценить в 35 секунд. Таким образом, преимущество СУБД ПК ВИКТА по скорости составило 35/2 = 17,5 раза. Как видно, эксперименты показали кратно высокую производительность СУБД ПК ВИКТА на данном тесте.
Г/IF - |.Гг ВМпН .1
Рис. 6. Время исполнения тестового запроса в ПК ВИКТА Fig. 6. Execution time of a test request in VIKTA PC
Рис. 7. Выполнение запроса без вывода данных с частичным совпадением с одной строкой Fig. 7. Request execution without data output with partial one line matching
Рис. 8. Выполнение запроса без вывода данных с частичным совпадением с двумя строками Fig. 8. Request execution without data output with partial two lines matching
Заключение
Исследование выявило ряд преимуществ СУБД ПК ВИКТА для хранения данных для случая, когда чтение данных является более приоритетной (востребованной) операцией по сравнению с изменением и записью данных. Также при такой нагрузке СУБД ПК ВИКТА демонстрирует заметную (3-4 раза) компактность по сравнению с некоторыми традиционными решениями и удобство при восстановлении данных по заданной метке времени.
Итак, возможности СУБД ПК ВИКТА:
• высокая скорость исполнения запросов чтения;
• малое потребление дискового про-
странства;
• отказоустойчивость за счет полных копий БД на каждой рабочей станции;
• масштабируемость за счет простого увеличения числа рабочих станций.
Ограничения:
• отсутствует документация;
• не выделена в отдельный продукт, так как жестко связана с IDE ПК ВИКТА;
• не имеет универсального языка запросов, подобного SQL и системы администрирования;
• тестирование для *-nix систем проводилось только на эмуляторах.
Библиографический список
1. Черняк Л. Большие данные - теория и практика [Электронный ресурс] // Журнал «Открытые системы». 2011. № 10. URL: http://www.osp.ru/os/2011 /10/13010990/( 16.06.2016 ).
2. Doctorow C. Big data: Welcome to the petacentre. On-line journal Nature. 2008, № 455/7209. Availabe at: http://www.nature.com/news/2008/080903/full/455016a.
html (accessed 17. June 2016 ).
3. Потапова Т. Платформа «Викта» [Электронный ресурс]. URL: http://spcomputer.ru/developer/vikta (23.06.2016).
4. Потапова Т. Платформа «Викта» [Электронный ресурс]. URL: http://spcomputer.ru/content/sposob-organizacii-dostupa-k-baze-dannyh (23.06.16)
References
1. Chernjak L. Bo'shie dannye - teorija i praktika [Big Data - A theory and practice]. On-line journal "Open Systems". 2011, no. 10, Available at:
http://www.osp.ru/os/2011/10/13010990/ (accessed 17 June 2016).
2. Doctorow C. Big data: Welcome to the petacentre.
Information Science, Computer Engineering and Management
On-line journal Nature. 2008, № 455/7209. Available at: http://www.nature.com/news/2008/080903/full/455016a. html (accessed 17. June 2016). 3. Potapova T. Platforma «Vikta» [Vikta platform]. Available at: http://spcomputer.ru/developer/vikta (ac-
Критерии авторства
Авторы заявляют о равном участии в получении и оформлении научных результатов и в равной мере несут ответственность за плагиат.
Конфликт интересов
Авторы заявляют об отсутствии конфликта интересов.
Статья поступила 01.08.2016 г.
cessed 23 July 2016).
4. Potapova T. Platforma «Vikta» [Vikta platform]. Available at: http://spcomputer.ru/content/sposob-organizacii-dostupa-k-baze-dannyh (accessed 23 July 2016).
Authorship criteria
The authors declare equal participation in obtaining and formalization of scientific results and are equally responsible for avoiding plagiarism.
Conflict of interests
The authors declare that there is no conflict of interests regarding the publication of this article.
The article was received 01 August 2016
