Научный журнал

Фундаментальные исследования

ISSN 1812-7339

"Перечень" ВАК

ИФ РИНЦ = 1,674

2. Актуальность построения ORM-решения на базе системы Polar

Традиционно ORM-решения разрабатываются для реляционных баз данных и используются для устранения семантического разрыва между объектно-ориентированным способом хранения данных и необходимостью сохранять такие данные на жестком носителе.

Иными словами, ORM-технологии используются в объектно-ориентированном программировании для удобства – объекты преобразуются в некий набор данных, который может быть сохранен в файлах или базе данных. В дальнейшем этот набор может быть легко извлечен, с сохранением свойств объектов и отношений между ними.

Существует несколько подходов к решению этой задачи [8]:

• Model First – Подход, при котором сначала реализуется модель БД (например, в виде UML-диаграммы).
• Database First – Реализация основывается на использовании уже существующей БД для формирования объектной модели.
• Code First – Подход, использованный при реализации для Polar. При нем сначала пишется код, задающий схему, необходимую для конструирования БД.

Система Polar обладает рядом объективных достоинств – она не требовательна к системным ресурсам, не требует специализированной установки, неприхотлива к объемам памяти и дискового пространства, а также к скорости работы процессора. В связи с этим авторы сочли интересным расширить круг задач, для решения которых система хранения Polar потенциально могла бы быть использована в качестве СУБД.

Независимо от типа используемой СУБД, при решении таких задач разработчикам неизбежно приходится решать ряд конструктивных проблем. Например, разработка приложений с использованием практически любой системы хранения данных, будь то MS SQL, MySQL или Polar в качестве СУБД, требует длительного времени для изучения ее спецификации [4, 9, 10]. Далее, программные модули, использующие API, имеют достаточно громоздкий и однообразный код, в котором легко допустить ошибку.

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

Заметим, что все ORM-решения, разработанные для универсальных СУБД, имеют ряд коммуникационных сложностей. Как правило, приложения, обеспечивающие реализацию ORM-технологии, и универсальные базы данных, которые используются как системы хранения данных при реализации ORM-технологии, представляют собой независимые решения, созданные различными группами программистов. Сообщение между приложениями в этих случаях осуществляется за счет универсальных протоколов и технологий предоставления данных, таких как ODBC [5] и ADO.NET [11]. Соответственно, обобщенная система затрачивает дополнительное время и дополнительную память на обеспечение взаимодействия.

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

Безусловно, технология ORM обладает рядом недостатков, существенных для ее реализации на практике. Например, дополнительный слой абстракции может сказаться на производительности, решение простых задач может оказаться слишком сложным, либо само ORM решение может быть недостаточно гибким. Кроме того, дизайн системы может оказаться зависимым от конкретной ORM-библиотеки. Ставя перед собой задачу разработки ORM для нереляционной базы (в нашем случае – ORM Polar), авторам приходится принимать их во внимание.

3. Принципы реализации ORM Polar

При создании программного модуля, реализующего ORM-технологию для системы хранения данных Polar, было предложено использовать подход Code First как основной. Ему отдано предпочтение за гибкость, простоту и удобство управления автоматически создаваемыми структурами данных путем редактирования соответствующих классов. В PolarDB предложено было создавать ячейку со структурой типа «запись», то есть ячейка представляет собой коллекцию однотипных массивов данных. В качестве методики разработки приложения ORM Polar авторы выбрали набор специальных классов, описывающих механизм размещения объектов модели в БД, а не xml-файл с сохраненным представлением полей базы данных и связей между таблицами [3]. Этот вариант авторам показался более удобным, так как с его помощью можно непосредственно в коде задавать различные изменения в БД.

Тогда программный модуль транслирует схему в структуры данных системы PolarDB с применением технологии «рефлексия» [6] по следующим правилам:

• каждый класс транслируется в определенную ячейку PolarDB с тем же названием;
• каждое поле класса сопоставляется с полем ячейки;
• стандартные типы C# транслируются во внутренние типы PolarDB;
• для определения полей, к которым должны быть созданы индексные структуры, используется маркерный атрибут [Index].

Среди набора классов, обеспечивающих функциональность технологии ORM на базе PolarDB, можно выделить два основных: DbContext и DbSet.

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

Задачу взаимодействия между таблицами БД, а также анализ и создание структуры данных решает класс DbContext.

DbSet класс, который представляет собой набор сущностей, хранящихся в БД.

Задачу взаимодействия таблиц можно решать несколькими способами:

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

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

4. Сравнительный анализ производительности ORM Polar и популярных ORM-решений

Для проведения сравнительного анализа производительности была разработана авторская методика тестирования.

Для этого, взяв за основу популярную модель NordWind [3, 8], описывающую условный магазин, было разработано специальное приложение, позволяющее через специализированный модуль-контейнер использовать различные популярные ORM-системы-связки в качестве СУБД данного приложения.

UML-диаграмма классов модели приведена на схеме.

Это позволило сравнить скорость поиска, скорость загрузки данных и скорость обновления данных для тестируемых систем, наиболее популярных на данный момент среди подобных решений. Они могут являться, по мнению авторов, конкурентами системы ORM Polar: Entity Framework [8], Hibernate [3] for MS SQL, Hibernate for MySQL. Итоговые результаты анализа можно увидеть в табл. 2.

Из табл. 2 видно, что система ORM Polar может быть эффективно использована для большого круга коммерческих приложений.

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

UML-диаграмма классов модели NordWind

Таблица 2

Сравнительные характеристики времени поиска 1000 случайных запросов популярных ORM-решений и ORM Polar (в мс)

Заключение

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

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

Данная статья поддержана грантом РФФИ № 14-07-00386 А.