Сравнительный анализ особенностей проектирования и реализации запросов в реляционных и документно-ориентированных базах данных на примере СУБД SQL Server и MongoDB.
- Авторы: Филатов В.В.1, Чигарина Е.И.1
-
Учреждения:
- Самарский университет
- Выпуск: № 1 (16) (2020)
- Страницы: 111-118
- Раздел: Информатика и вычислительная техника
- Дата публикации: 15.12.2020
- URL: https://vmuis.ru/smus/article/view/9269
- ID: 9269
Цитировать
Полный текст
Аннотация
Все современные автоматизированные системы используют для хранения данных либо хранилища, либо базы данных. Существует множество видов систем управления базами данных, поддерживающих реляционные, объектные, документно-ориентированные и другие модели данных. Задача данной работы – определение особенностей проектирования, а также достоинств и недостатков хранения, манипулирования данными в реляционных и документно-ориентированных базах данных, используя при этом системы управления базами данных MS SQL Server и MongoDB.
Полный текст
Анализ особенностей проектирования систем баз данных SQL и NoSQL
При проектировании баз данных выделяют такие основные этапы как концептуальное, логическое и физическое проектирование. На концептуальном уровне вне зависимости от структуры данных делается описание модели хранения в терминах модели «сущность-связь». Для перехода к логической модели для реляционных баз данных используются правила Джексона, а для перехода к документно-ориентированной модели таких правил нет.
С учетом особенностей структуры данных, реализуемой в MongoDB, в таблице 1 приведено сравнение правил перехода от концептуальной модели к логической модели реляционной базы данных и документно-ориентированной базы данных с учетом всех существующих видов связей, особенностей классов принадлежностей сущностей и мощностей связей (табл. 1).
Базовыми понятиями в MongoDB являются коллекции и документы [2]. Коллекция является эквивалентом таблицы в реляционных системах управления базами данных. Коллекция существует в одной базе данных [2].
Документ – запись в коллекции и базовая единица данных в MongoDB [2]. Документы в коллекции могут иметь разные поля. Как правило, все документы в коллекции имеют аналогичное или связанное назначение. Документы аналогичны объектам JSON, но существуют в базе данных в формате с большим количеством типов, известным как BSON [2].
С учетом анализа особенностей структуры данных в рассматриваемой документно-ориентированной СУБД сформулированы следующие правила.
Таблица 1
Правила перехода от концептуальной модели к логической
Правила перехода от концептуальной модели к документно-ориентированной модели базы данных:
- Если степень связи 1:1 и класс принадлежности обоих сущностей является обязательным, то в документно-ориентированной модели создается один документ, одним из полей которого является вложенный документ, содержащий данные о второй сущности.
- Если степень связи 1:1 и класс принадлежности одной сущности является обязательным, а другой – необязательным, то в документно-ориентированной модели создается один документ, одним из полей которого может быть вложенный документ, содержащий данные о второй сущности.
- Если степень связи 1:1 и класс принадлежности ни одной сущности не является обязательным, то в документно-ориентированной модели создается два документа, при этом в каждом из них может содержаться поле, хранящее ссылку(идентификатор) на другой документ.
- Если степень связи 1:n и класс принадлежности n-связной сущности является обязательным, то в документно-ориентированной модели возможны 2 варианта:
- один документ, одним из полей которого является вложенный документ, содержащий данные о второй сущности
- два документа, при этом второй документ содержит поле, хранящее ссылку(идентификатор) на первый документ.
- Если степень связи 1:n, класс принадлежности n-связной сущности является необязательным и нет дополнительных полей, то в документно-ориентированной модели возможны 2 варианта:
- один документ, одним из полей которого может быть вложенный документ, содержащий данные о второй сущности
- два документа, при этом второй документ может содержать поле, хранящее ссылку(идентификатор) на первый документ.
Если степень связи 1:n, класс принадлежности n-связной сущности является необязательным и есть дополнительные поля, то создается два документа, при этом второй документ содержит массив объектов следующего типа:
arr1:[{ K1id: ObjectId, data: String }, ... ], где KNid – ссылка на другой документ
data – дополнительное поле
- Если степень связи m:n и нет дополнительных полей, создается 2 документа, каждый из которых содержит массив ссылок на другой документ. Если степень связи m:n и есть дополнительные поля, создается 2 документа, каждый из которых содержит массив объектов следующего типа:
arrN:[{ KNid: ObjectId, data: String }, ... ], где KNid – ссылка на другой документ
data – дополнительное поле
Сравнительный анализ применения правил перехода от концептуальной модели к логической для реляционных и документно-ориернтированных баз данных на примере описания предметной области «Студент вуза»
Описанные правила использованы на примере концептуальной модели базы данных “Студент вуза”. Модель сущность-связь базы данных “Студент вуза” приведена ниже (рис. 1).
Согласно правилам Джексона, осуществлен переход к логической модели реляционной базы данных по методологии IDEF1X (рис. 2).
Согласно разработанным правилам перехода от концептуальной модели к логической, осуществлен переход к документно-ориентированной модели (рис. 3).
Видно, что по количеству объектов более предпочтительна документно-ориентированная модель (4 коллекции против 7 таблиц).
Разработка алгоритмов и программная реализация решения задачи сравнительного анализа выполнения запросов в системах баз данных 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. График зависимости среднего времени выполнения запроса на удаление от количества записей
Об авторах
Владислав Вячеславович Филатов
Самарский университет
Автор, ответственный за переписку.
Email: phil182@mail.ru
магистрант факультета информатики
Россия, 443086, Россия, г. Самара, Московское шоссе, 34Елена Ивановна Чигарина
Самарский университет
Email: chigarinaei@gmail.com
доцент кафедры информационных систем и технологий Самарского университета
Россия, 443086, Россия, г. Самара, Московское шоссе, 34Дополнительные файлы
