A comparative analysis of the features of designing and realization of requests in relational and document-oriented database using DBMS SQL Server and MongoDB as an example

Full Text

1. Анализ особенностей проектирования систем баз данных SQL и NoSQL

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

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

Базовыми понятиями в MongoDB являются коллекции и документы [2]. Коллекция является эквивалентом таблицы в реляционных системах управления базами данных. Коллекция существует в одной базе данных [2].

Документ – запись в коллекции и базовая единица данных в MongoDB [2]. Документы в коллекции могут иметь разные поля. Как правило, все документы в коллекции имеют аналогичное или связанное назначение. Документы аналогичны объектам JSON, но существуют в базе данных в формате с большим количеством типов, известным как BSON [2].

С учетом анализа особенностей структуры данных в рассматриваемой документно-ориентированной СУБД сформулированы следующие правила.

 

Таблица 1

Правила перехода от концептуальной модели к логической

 

 

Правила перехода от концептуальной модели к документно-ориентированной модели базы данных:

1. Если степень связи 1:1 и класс принадлежности обоих сущностей является обязательным, то в документно-ориентированной модели создается один документ, одним из полей которого является вложенный документ, содержащий данные о второй сущности.
2. Если степень связи 1:1 и класс принадлежности одной сущности является обязательным, а другой – необязательным, то в документно-ориентированной модели создается один документ, одним из полей которого может быть вложенный документ, содержащий данные о второй сущности.
3. Если степень связи 1:1 и класс принадлежности ни одной сущности не является обязательным, то в документно-ориентированной модели создается два документа, при этом в каждом из них может содержаться поле, хранящее ссылку(идентификатор) на другой документ.
4. Если степень связи 1:n и класс принадлежности n-связной сущности является обязательным, то в документно-ориентированной модели возможны 2 варианта:

- один документ, одним из полей которого является вложенный документ, содержащий данные о второй сущности

- два документа, при этом второй документ содержит поле, хранящее ссылку(идентификатор) на первый документ.

5. Если степень связи 1:n, класс принадлежности n-связной сущности является необязательным и нет дополнительных полей, то в документно-ориентированной модели возможны 2 варианта:

- один документ, одним из полей которого может быть вложенный документ, содержащий данные о второй сущности

- два документа, при этом второй документ может содержать поле, хранящее ссылку(идентификатор) на первый документ.

Если степень связи 1:n, класс принадлежности n-связной сущности является необязательным и есть дополнительные поля, то создается два документа, при этом второй документ содержит массив объектов следующего типа:

arr1:[{                          K1id: ObjectId,                    data: String                       }, ...              ], где KNid – ссылка на другой документ

  data – дополнительное поле

6. Если степень связи m:n и нет дополнительных полей, создается 2 документа, каждый из которых содержит массив ссылок на другой документ. Если степень связи m:n и есть дополнительные поля, создается 2 документа, каждый из которых содержит массив объектов следующего типа:

arrN:[{                          KNid: ObjectId,                               data: String                       }, ...              ], где KNid – ссылка на другой документ

  data – дополнительное поле

2. Сравнительный анализ применения правил перехода от концептуальной модели к логической для реляционных и документно-ориернтированных баз данных на примере описания предметной области «Студент вуза»

Описанные правила использованы на примере концептуальной модели базы данных “Студент вуза”. Модель сущность-связь базы данных “Студент вуза” приведена ниже (рис. 1).

Согласно правилам Джексона, осуществлен переход к логической модели реляционной базы данных по методологии IDEF1X (рис. 2).

Согласно разработанным правилам перехода от концептуальной модели к логической, осуществлен переход к документно-ориентированной модели (рис. 3).

Видно, что по количеству объектов более предпочтительна документно-ориентированная модель (4 коллекции против 7 таблиц).

3. Разработка алгоритмов и программная реализация решения задачи сравнительного анализа выполнения запросов в системах баз данных SQL и NoSQL на примере СУБД MS SQL Server и MongoDB

Для реализации спроектированных моделей реляционной и объектно-ориентированной базы даны были выбраны СУБД MS SQL Server и MongoDB. MS SQL Server – это мощная и надежная система управления данными, обеспечивающая множество функций, защиту данных и высокую производительность для внедренных приложений-клиентов, «легких» веб-приложений и локальных хранилищ данных. SQL Server предназначен для развертывания и создания прототипов; его можно получить бесплатно и свободно распространять вместе с приложениями.

 

Рис. 1. Концептуальная модель базы данных «Студент вуза»

 

Рис. 2. Логическая модель базы данных «Студент вуза» по методологии IDEF1X

 

Рис. 3. Документно-ориентированная модель базы данных “Студент вуза”

 

MongoDB (от англ. humongous – огромный) – документо-ориентированная СУБД с открытым исходным кодом, не требующая описания схемы таблиц. Классифицирована как NoSQL, использует JSON-подобные документы и схему базы данных. Написана на языке C++. MongoDB реализует новый подход к построению баз данных, где нет таблиц, схем, запросов SQL, внешних ключей и многих других вещей, которые присущи реляционным базам данных.

Для подсчета времени выполнения запросов в MS SQL Server в работе использована утилита SQL Server Profiler - это интерфейс для создания трассировок и управления ими, а также для анализа и воспроизведения полученных результатов[3].

Для подсчета времени выполнения запросов в MongoDB – системная коллекция system.profile. Профилировщик базы данных собирает подробную информацию о коман-дах базы данных, выполняемых для работаю-щего экземпляра mongod. Профилировщик записывает все данные, которые он собирает, в коллекцию system.profile, ограниченную коллекцию в базе данных администратора[2].

Для заполнения реляционной и объектно-ориентированной базы данных тестовыми записями были написаны соответ-ственно хранимые процедуры в SQL Server и программный код на языке JavaScript с использованием NodeJS.

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

Результаты измерения времени выпол-нения перечисленных запросов в разных системах для разного объема данных приведены в таблицах 2 и 3.

На рисунках 4, 5 и 6 представлены графики зависимости среднего времени выполнения запросов на выборку и удаление от количества записей в базе данных.

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

Заключение

По количеству объектов более предпочтительна документно-ориентирован-ная модель (4 коллекции против 7 таблиц). По объему памяти, занимаемому данными для рассматриваемого примера при одинаковом количестве записей в SQL и NoSQL базах данных, выигрывает также документно-ориентированный подход.

 

Таблица 2

Запросы на выборку данных

100000 записей	MS SQL Server	MongoDB
1.1. выборка из одной таблицы	1957ms	310ms
1.2. выборка из двух таблиц	2251ms	417ms
1.3. выборка из двух таблиц с условием	475ms	181ms
1.4. выборка из двух таблиц с условием и сортировкой	555ms	272ms
1.5. выборка с группировкой	1270ms	17922ms
1.6. выборка с соединением всех таблиц	4980ms	53010ms
1000 записей	SQL Server	MongoDB
1.1. выборка из одной таблицы	121ms	4ms
1.2. выборка из двух таблиц	165.2ms	7ms
1.3. выборка из двух таблиц с условием	3.4ms	3ms
1.4. выборка из двух таблиц с условием и сортировкой	10ms	3ms
1.5. выборка с группировкой	15.6ms	327ms
1.6. выборка с соединением всех таблиц	622ms	551ms
10 записей	SQL Server	MongoDB
1.1. выборка из одной таблицы	1.8ms	0ms
1.2. выборка из двух таблиц	1.16ms	0ms
1.3. выборка из двух таблиц с условием	3.4ms	1ms
1.4. выборка из двух таблиц с условием и сортировкой	2.4ms	1ms
1.5. выборка с группировкой	1.7ms	4ms
1.6. выборка с соединением всех таблиц	343ms	29ms

 

Таблица 3

Запросы на изменение данных

100000 записей	SQL Server	MongoDB
2.1. вставка записи	3.2ms	0ms
2.2. обновление записи	1.2ms	0ms
2.3. удаление записи	112ms	64ms
2.4. вставка записи	7.8ms	55ms
2.5. обновление записи	9.8ms	0ms
2.6. удаление записи	1.8ms	0ms

 

Продолжение табл. 3

1000 записей	SQL Server	MongoDB
2.1. вставка записи	1.2ms	0ms
2.2. обновление записи	1.1ms	0ms
2.3. удаление записи	20.4ms	0ms
2.4. вставка записи	8.6ms	0ms
2.5. обновление записи	2ms	0ms
2.6. удаление записи	1.7ms	0ms
10 записей	SQL Server	MongoDB
2.1. вставка записи	2.6ms	0ms
2.2. обновление записи	1ms	0ms
2.3. удаление записи	11.8ms	0ms
2.4. вставка записи	2.6ms	0ms
2.5. обновление записи	1.8ms	0ms
2.6. удаление записи	1.5ms	0ms

 

Рис. 4. График зависимости среднего времени выполнения запроса на выборку из одной таблицы от количества записей

 

Рис. 5. График зависимости среднего времени выполнения запроса на выборку с группировкой от количества записей

 

Рис. 6. График зависимости среднего времени выполнения запроса на удаление от количества записей

 

About the authors

Vladislav Vyacheslavovich Filatov

Samara University

Author for correspondence.
Email: phil182@mail.ru

undergraduate student of the Faculty of Informatics

Russian Federation, 443086, Russia, Samara, Moskovskoye Shosse, 34

Elena Ivanovna Chigarina

Samara University

Email: chigarinaei@gmail.com

associate professor of the Department of Information Systems and Technologies of the Samara University

Russian Federation, 443086, Russia, Samara, Moskovskoye Shosse, 34

Supplementary files