CC BY
107
Оригинальная статья / Original article УДК: 004.652
DOI: 10.21285/1814-3520-2016-10-71-80
ОСОБЕННОСТИ ПРОЕКТИРОВАНИЯ НЕРЕЛЯЦИОННЫХ БАЗ ДАННЫХ (НА ПРИМЕРЕ РЕШЕНИЯ ВИКТА)
© А.М. Андрианов1, В.М. Илюшечкин2, П.Ю. Чумаченко3, Е.Л. Федотова4
Национальный исследовательский университет «Московский институт электронной техники», 124498, Россия, г. Москва, г. Зеленоград, пл. Шокина, 1.
РЕЗЮМЕ. ЦЕЛЬ. Целью данного исследования является определение возможностей и ограничений нереляционной БД ПК ВИКТА (базы данных программного комплекса ВИКТА). МЕТОДЫ. Использовался метод сравнительного анализа архитектуры БД и результатов натурных экспериментов. РЕЗУЛЬТАТЫ. Приведены результаты второго этапа исследования отечественной среды быстрой разработки приложений ПК ВИКТА. На первом этапе исследовалась архитектура ПК ВИКТА кроме исследования оригинальной БД. В данной статье представлены выводы о возможностях и ограничениях данной БД. Приведены результаты экспериментов по тестированию быстродействия БД по сравнению с некоторыми аналогами и решениями на реляционных БД. ВЫВОДЫ. Установлена высокая скорость и компактность БД ПК ВИКТА при использовании в программах учетных систем. Ключевые слова: базы данных, нереляционная база данных, ПК ВИКТА, архитектура баз данных, проектирование баз данных.
Формат цитирования: Андрианов А.М., Илюшечкин В.М., Чумаченко П.Ю., Федотова Е.Л. Особенности проектирования нереляционных баз данных (на примере решения ВИКТА) // Вестник Иркутского государственного технического университета. 2016. Т. 20. № 10. С. 71-80. DOI: 10.21285/1814-3520-2016-10-71-80
DESIGN FEATURES OF NON-RELATIONAL DATABASES (ON EXAMPLE OF VIKTA SOLUTION) A.M. Andrianov, V.M. Ilyushechkin, P.Y. Chumachenko, E.L. Fedotova
National Research University of Electronic Technology - MIET, 1, Shokin Square, Zelenograd, Moscow, 124498, Russia.
ABSTRACT. The PURPOSE of this research is determination of capabilities and limitations of a non-relational VIKTA Program Complex database (VIKTA PC DB). METHODS. The method of the comparative analysis of DB architecture and full-scale experiment results is used. RESULTS. The results of the second investigation phase of the national rapid application development environment VIKTA PC are given. The first stage studied the VIKTA PC architecture, except for the research of the original database. This article presents the conclusions on the capabilities and limitations of the discussed database. The experiment results on testing database high-speed response as compared with some analogs and solutions on relational databases are provided. CONCLUSION. High speed and compactness of the VIKTA PC DB is determined when being used in registration system programs.
Keywords: databases; non-relational database; PC VIKTA; database architecture; designing databases
For citation: Andrianov A.M., Ilyushechkin V.M., Chumachenko P.Y., Fedotova E.L. Design features of non-relational databases (on example of VIKTA solution). Proceedings of Irkutsk State Technical University. 2016. vol. 20, no. 10. pp. 71-80. (In Russian) DOI: 10.21285/1814-3520-2016-10-71-80
Андрианов Андрей Михайлович, кандидат технических наук, доцент кафедры информатики и программного обеспечения вычислительных систем, e-mail: andymailru@mail.ru
Andrianov Andrey, Candidate of technical sciences, Associate Professor of the Department of Information Science and Computer System Software, e-mail: andymailru@mail.ru
2Илюшечкин Владимир Михайлович, кандидат технических наук, профессор кафедры информатики и программного обеспечения вычислительных систем.
Ilyushechkin Vladimir, Candidate of technical sciences, Professor of the Department of Information Science and Computer System Software.
Чумаченко Павел Юрьевич, кандидат технических наук, доцент кафедры информатики и программного обеспечения вычислительных систем.
Chumachenko Pavel, Candidate of technical sciences, Associate Professor of the Department of Information Science and Computer System Software.
4Федотова Елена Леонидовна, кандидат педагогических наук, доцент кафедры информатики и программного обеспечения вычислительных систем.
Fedotova Elena, Candidate of Pedagogics, Associate Professor of the Department of Information Science and Computer System Software.
Введение
На сегодняшний момент широко распространены реляционные базы данных (БД), которые состоят из таблиц, связанных между собою по полям уникальных идентификаторов. Такие БД хорошо зарекомендовали себя на практике. Однако в последнее время в связи с постоянно ускоряющимся ростом объема и сложности данных постепенно набирают популярность нереляционные БД, с которыми связывают
надежды по упрощению работы с «Большими Данными» [1] (Big Data [2]). Такие БД, как правило, иностранного происхождения. В статье рассматривается принципиальная архитектура отечественной нереляционной базы данных программного комплекса ВИКТА (ПК ВИКТА) [3]. Целью данного исследования является определение возможностей и ограничений нереляционной БД ПК ВИКТА.
Материал и методы исследования
Материалом для исследования являются: БД ПК ВИКТА и реляционные БД на примере MySQL, которые исследуются посредством анализа архитектуры и сравнительных нагрузочных экспериментов.
Сравнение архитектуры БД ВИКТА с архитектурой реляционных БД. Современные реляционные БД - это, как правило, отдельный продукт, имеющий встроенный интерфейс взаимодействия с внешним по отношению к нему прикладным приложением. Этот интерфейс реализуется обычно на базе общепринятого языка структурированных запросов - SQL. Эти БД могут быть платными (MS SQL, Oracle) или бесплатными (MySQL, Postrgess SQL). Платные БД зачастую позиционируются как решения для высоконагруженных проектов и имеют соответствующий инструментарий. Наличие полей уникальных идентификаторов записей позволяет построить полную базу данных приложения еще до написания кода самого приложения, которое будет ее использовать. Под полной базой здесь понимается возможность связать все данные будущего приложения так, что только по этой структуре уже можно достаточно полно представить потребности будущего приложения (рис. 1).
БД ПК ВИКТА отличается от распространенных профессиональных реляционных БД отсутствием в архитектуре понятия уникального идентификатора записи в том смысле, в котором он широко распространен в реляционных БД. Поэтому в БД ПК
ВИКТА нельзя напрямую выполнить запрос, аналогичный «SELECT * from 'table' where 'ID' = ... ». Уникальный идентификатор записи в БД ПК ВИКТА формируется из значений, так называемых реквизитов записи. (Что такое реквизиты, будет подробнее описано ниже). Если же применить аналогию с реляционной БД, то уникальность записи определяется набором ее данных в определенных полях таблицы. Например, когда для этой цели выделены поля «NAME» и «EMAIL», тогда в них не может быть двух записей с одинаковыми данными. При этом другие поля записей могут иметь одинаковые значения. В некоторых реляционных базах также можно создавать уникальные идентификаторы (ключи) из нескольких полей (например, MySQL), однако их рекомендуется применять только для оптимизации узкоспециальных запросов, в то время как в БД ПК ВИКТА это одна из основ всей технологии БД.
На первый взгляд такое решение должно замедлить работу при обращении к конкретной записи, так как быстрее всего ее выбрать по уникальному номеру, а не поиском по значению полей, не говоря уже о неудобстве указания двух и более полей вместо одного уникального идентификатора. Но более детальное рассмотрение вопроса показало, что получение данных конкретной записи в интерфейсе прикладного приложения, вообще говоря, происходит,
Рис. 1. Типовая схема связей реляционной БД Fig. 1. Standard diagram of relational DB ties
как правило, в результате выбора из списка, возвращенного некой предыдущей операцией. В БД ПК ВИКТА записи этого списка неявно содержат позицию записи в файле БД (рис. 2). Эта позиция не идентификатор записи, это ее положение (по сути -номер строки) от начала файла БД. Поскольку позиция записи в файле известна,
то выбор значения записи для подробного просмотра или редактирования (если это нужно) происходит мгновенно. Очевидно, что данное решение в архитектуре БД было продиктовано наблюдением за реальной практикой использования прикладных приложений.
Рис. 2. Физическое содержание записи в БД ВИКТА Fig. 2. Physical content of a record in the VIKTA DB
Естественным является желание считать номер строки записи в файле БД ПК ВИКТА уникальным идентификатором. Однако этого нельзя делать. В БД ПК ВИК-ТА может быть несколько экземпляров одной и той же по сути записи, но с «исторически разными данными». Это вторая особенность БД ПК ВИКТА. Записи изменяются не по месту их расположения, а измененные записи всегда дописываются в конец БД. Никаких операций с записью, послужившей источником для изменений, не производится. Поэтому операция «UPDATE» в БД ПК ВИКТА производится быстрее, а в таблицы интерфейса прикладного приложения выбираются уже только последние записи. Этот подход также позволяет совершить в любой момент откат (и просмотр) всей БД на определенную дату и даже час, и секунду. Поскольку
такой способ выполнения обновлений записей приводит к росту БД за счет устаревших данных, разработчиками ПК ВИКТА предусмотрена операция компрессирования базы, которая позволяет удалить все устаревшие данные до определенной даты.
Вместо понятия полей таблицы (записи) в БД ПК ВИКТА применяется понятие реквизитов (рис. 3). Реквизиты в чем-то схожи с полями таблицы реляционной БД. Особенности реквизитов таковы:
1. Реквизиты могут содержать только простые типы данных: int, char и т.д.
2. Комбинация значений обязательных реквизитов составляет уникальный ключ записи.
3. Реквизиты описываются в конфигурационном файле БД.
4. По реквизитам могут быть построены ключи для быстрого поиска.
XML файл с описанием БД XML file with a DB description
Общий список реквизитов ПК ВИКТА
kodjnol_RU_СПКомпьютер_Основное! 30206
nom_sklad_RU_СПКомпьютер_0сновное130206
nomnom_RU_СПКомпьютер_0сновное130206
Общие справочники ПК ВИКТА
ЦемыКЛАМАРа_RU_СПКомпьютер_Основное! 30206
K.-WM
U1PJM4HHIJ
Ml fr**** p«tt>i>ireft
. typ_**um_RU СПКомпыог»е_Осиоа»««и02К
lyp_dofcuni_RU_CnKoMftwof»p_Осмоамо*1Ш0(
dJM_r»g_RU_СЙ<эиПкют»р_
Файл справочника Reference file
lyp_dokum_ nomnom_... date_reg_...
данные данные
данные данные
данные данные
данные данные
данные данные
Файл БД прикладного приложения Application DB file
Kod_mol_... nomnom_.. typ_dokum_...
данные данные
данные данные
данные данные
данные
данные данные
Выборка данных в приложении Data retrieval in an application
kod_mol_.. typ_dokum_.........
данные данные
данные данные
данные данные
данные данные
данные данные
Рис. 3. Схема использования понятия реквизитов в БД ВИКТА для построения БД Fig. 3. Diagram of using the attribute concept in the VIKTA DB for building a DB
Физически файл справочника ничем не отличается от БД приложения, но справочники могут использоваться разными приложениями. Таким образом, получается возможность повторного использования данных. Например, справочников типов бухгалтерских документов, единиц измерений и т.д.
Связь полей таблицы в пользовательском интерфейсе с файлами (таблицами) справочников осуществляется статическим и динамическим связыванием. Статическое связывание осуществляется в специальном хт1-файле, и привязанные таким образом справочники становятся доступны для использования во всех таблицах, представляющих запись. Динамиче-
ское связывание позволяет добавить к виду таблицы колонку с выбором из справочника в коде фрейма. Внешне вызовы обоих типов не различаются и открывают справочник одинаково (рис. 4).
В записи БД не содержится ссылки на файл справочника, а содержится выбранное значение. Например, Назва-ние=«Шпроты с овощами». Это позволяет быстро формировать таблицу результатов. Ссылка на файл справочника, которая приводит к его открытию для выбора значения, описывается либо в коде обработчика таблицы (фрейма) при динамическом связывании, либо в хт1-файле статических связей при статическом связывании.
2 '«г jnw iöl 1кикт.г llrfH w ' 1 Шшсстйфмииор млтгриальшж ресурсов
Пщи Мпфммш Пимам Сфаамим» Цимймиим WMlM в*М 0«И* Осмсы»
Л и»»1я*шиои1в««1«|/.1ян»жиЛ|««вмв€1 I Я ГШ—1Г»WTWW—Miwafm
Ни
Рис. 4. Демонстрация динамического связывания данных в табличном интерфейсе пользователя со справочником Fig. 4. Demonstration of dynamic data binding in the user plate interface with a reference table
Рассмотрение архитектуры БД ПК ВИКТА показывает «заточенность» базы на обеспечение максимальной скорости работы для задач, характерных для определенного класса учетных систем. Важным, практически значимым следствием из архитектуры БД ПК ВИКТА является возможность многократного снижения потребностей в ресурсах при бэкапировании данных, что может быть значимо, например, для компаний, предоставляющих услуги хостинга сайтов. По договору такие компании обычно должны выполнять ежедневное бэкапи-рование данных с обязательством хранить архивы 10-14 дней.
Сравним эффективность хранения для традиционного подхода и в БД ПК ВИКТА. Обозначим за 1 размер БД. Для упрощения примем, что в БД не добавляются новые записи, а только изменяется 10% записей. При традиционном подходе через 14 дней будем иметь 15 полных копий БД (рис. 5). Для БД ПК ВИКТА достаточно к копии на файл-сервере бэкапов до-
писывать в конец изменения текущего дня, а на сервере БД выполнять компрессирование. В результате получим 1+1+0,1*14=3,4. Таким образом, БД ПК ВИКТА требуется в 15/3,4=4,4 раза меньший объем жестких дисков. Преимущество БД ПК ВИКТА будет тем больше, чем меньшее количество данных обновляется.
Нельзя сказать, что механизм пор-тирования обновлений совсем не используется в реляционных БД. Такой механизм есть и называется репликация. Однако этот механизм требует достаточно тонкой настройки средствами самой БД и применяется для проектов с высокой степенью ответственности, где даже потеря данных за несколько минут уже может быть критична. В этом случае правильно иметь почти идентичные копии БД, тогда в случае краха одной базы практически мгновенно подключается вторая. Для большинства же сайтов используется механизм полной копии, так как он весьма прост.
Рис. 5. Сравнение традиционного бэкапирования БД и возможности бэкапирования в ПК ВИКТА Fig. 5. Comparison of DB traditional backing up and the backing up possibility in the VIKTA PC
Необходимо сказать несколько слов об устройстве БД ПК ВИКТА в том случае, когда приложение является сетевым и с одной БД работают несколько операторов. Важно отметить, что в этом случае каждый оператор имеет ПОЛНУЮ копию БД, т.е. нет одной БД, к которой обращаются все операторы, а есть столько копий БД, сколько операторских мест. При этом ПК ВИКТА автоматически обеспечивает механизм синхронизации данных и разрешение случая взаимных блокировок. Важно отметить, что как таковых блокировок в «классическом смысле» в БД ПК ВИКТА вообще нет [4]. Операторы могут одновременно прочитать запись, потому что у каждого своя копия БД. Но вот записать одновременно они уже не могут, так как записываются сохраняемые данные оператора, пославшего их на сохранение первым. Оператору предлагается уже либо отменить сохранение записи измененной другим пользователем, либо взять обновленные данные этой записи.
Тестирование быстродействия БД ПК ВИКТА. Всего проводилось два специальных эксперимента: в 2010 и 2016 гг.
Первый эксперимент. В 2010 г. ООО «Аймэн» (http://www.aimen.ru), являющееся Microsoft Gold Certified Partner, проводило сравнительное тестирование приложений типа «Заработная плата», разработанных на платформе Microsoft и на платформе ПК ВИКТА. Тестирование показало почти 30-кратное превосходство в скорости решения на базе ПК ВИКТА: 30-40 секунд у ПК ВИКТА против 15-16 минут у Microsoft для задачи расчета заработной платы. По итогам тестирования был составлен протокол о намерениях, который, к сожалению, тогда не перерос в договор о сотрудничестве по независящим от СП-Компьютер причинам.
Также в протоколе были отмечены следующие особенности ПК ВИКТА (в 2010 г. имевшего название «СП^50») важные в части БД:
1. Программная оболочка «СП^50» - готовый программный продукт, предназначенный для создания автоматизирован-
ных информационных систем. По своему составу и функциональным возможностям «СП-250» не уступает имеющимся на рынке отечественным и зарубежным аналогам. Кроме того, в программной оболочке заключен ряд оригинальных решений.
2. В системе реализована уникальная технология распределенной базы данных, что позволяет решать задачу масштабирования путем простого добавления рабочих станций к системе с ростом нагрузки и числа одновременно работающих пользователей. Одновременно с этим наличие распределенной базы данных позволяет также решить и задачу отказоустойчивости системы в целом за счет отсутствия централизованного места хранения данных и наличия встроенных механизмов синхронизации.
Второй эксперимент. Проводился в январе 2016 г. для сравнения быстродействия БД ВИКТА и реляционной БД MySQL. Для эксперимента было составлено два справочника. Первый содержал 100 тыс. записей списка сотрудников, второй -300 тыс. записей мест работы сотрудников. Каждый сотрудник мог иметь до 3-х мест работы. В эксперименте выбирались 1000 сотрудников с местом работы, совпадавшим в контексте с некоторым шаблоном. Задача состояла в том, что место работы неоднозначно. Нужно выбрать всех, кто работал, например, в МГУ ВМиК. Может быть, все 3 места сотрудника отвечают заданному требованию, может быть, - одно. Например, МГУ ВМиК нужно искать в контексте Поле «аааа бббб МГУ ВМиК оооо» и в «МГУ ВМиК ннн»; оба отвечают поставленному требованию.
Тестирование проводилось на компьютерах сравнимой мощности. MySQL был развернут на базе пакета 1С-Битрикс Web-окружение, который включал также развертывание web-сервера. Запросы к MySQL выполнялись как из php-файла, так потом и напрямую командами из консоли, чтобы исключить влияние потерь времени на передачу запросов через Apache-PHP. Результаты выполнения ПК ВИКТА составили 2 секунды (+78 миллисекунд) (рис. 6.)
Рис. 6. Время исполнения тестового запроса в ПК ВИКТА Fig. 6. Execution time of a test query in the VIKTA PC
Результаты выполнения запросов на БД MySQL составили от 31 до 41 секунды (рис. 7, 8). Выполнение этих же запросов прямыми командами консоли к MySQL показало рост скорости в среднем не более чем на 1-3 секунды. Итого в среднем вы-
полнение запроса в MySQL можно оценить в 35 секунд. Таким образом, преимущество БД ПК ВИКТА по скорости составило 35/2 = 17,5 раза. Как видно, эксперименты показали кратно высокую производительность БД ПК ВИКТА на данном тесте.
Запрос:
SELECT U TAB NUMBER U FIO , U . PHONE . U . EMAIL . PW . ЧАНЕ
FOOM pfacas.woric' AS PW , uwy AS U , uwrs_to_pi»c»_wort AS UPW
V.vtERE J TAB NUHMO • ' UfWV USER
AH© JPW VVO«k г PW.tD
ANO PW . U*ï
AND U TAB_NU»«EP i ÎOOO
Рис. 7. Выполнение запроса без вывода данных с частичным совпадением с одной строкой Fig. 7. Query execution without data output and with partial one line matching
Рис. 8. Выполнение запроса без вывода данных с частичным совпадением с двумя строками Fig. 8. Query execution without data output with partial two lines matching
Результаты и выводы
Исследование выявило ряд преимуществ БД ПК ВИКТА для хранения данных в случае, когда чтение данных является более приоритетной (востребованной) операцией по сравнению с изменением и записью данных. Также при такой нагрузке БД ПК ВИКТА демонстрирует заметную (в 3-4 раза) компактность по сравнению с некоторыми традиционными решениями и удобство при восстановлении данных по заданной метке времени. Из всего вышеизложенного можно сделать следующие выводы:
1. Возможности БД ПК ВИКТА: - высокая скорость исполнения запросов чтения;
- малое потребление дискового пространства;
- отказоустойчивость за счет полных копий БД на каждой рабочей станции;
- масштабируемость за счет простого увеличения числа рабочих станций.
2. Ограничения:
- отсутствует документация;
- не выделена в отдельный продукт, так как жестко связана с 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. URL: http://www.nature.com/news/2008/080903/full/455016a. html (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. Bol'shie dannye - teorija i praktika [Big Data - 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. On-line journal Nature. 2008, no. 455/7209 Available at: http://www.nature.com/news/2008/080903/full/455016a. html (accessed 17 June 2016).
Критерии авторства
Андрианов А.М., Илюшечкин В.М., Чумаченко П.Ю., Федотова Е.Л. провели исследования по определению возможностей и ограничений нереляционной базы данных программного комплекса ВИКТА, провели обобщение и написали рукопись. Андрианов А.М. несет ответственность за плагиат.
Конфликт интересов
Авторы заявляют об отсутствии конфликта интересов.
Статья поступила 01.08.2016 г.
3. Potapova T. Platforma "Vikta" [Vikta platform]. Available at: http://spcomputer.ru/developer/vikta (accessed 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
Andrianov A.M., Ilyushechkin V.M., Chumachenko P.Y., Fedotova E.L. conducted studies to determine the possibilities and limitations of the non-relational database of the program complex VIKTA, summarized the material and wrote the manuscript. Andrianov A.M. bears the responsibility for 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
