Сравнительный анализ реляционной базы данных и документоориентированной NoSQL базы данных в разрезе их применения при создании локального чата/мессенджера Текст научной статьи по специальности «Компьютерные и информационные науки»

3. Филатова, Виолетта 1С: Предприятие 8.1. Бухгалтерия предприятия. Управление торговлей. Управление персоналом / Виолетта Филатова. - М., 2014. - 272 с.

4. Ширяев В.И., Управление предприятием: Моделирование, анализ, управление / В.И. Ширяев, И.А. Баев, Е.В. Ширяев. -М.: КД Либроком, 2015. - 272 с.

©Чеснокова А.В., 2018

УДК62

Якушин А.Ю., магистрант

кафедры «Автоматизированные системы управления» ФГБОУ ВО «Московский автомобильно-

дорожный государственный технический университет (МАДИ)»,

уакип 1774@yandex.ru Муковозов А. М., магистрант

кафедры «Автоматизированные системы управления» ФГБОУ ВО «Московский автомобильно-дорожный государственный технический университет (МАДИ)», graalogosh@gmail.com

Исмоилов М.И.,

кандидат технических наук, доцент кафедры «Автоматизированные системы управления».

ФГБОУ ВПО «Московский автомобильно-дорожный государственный технический университет (МАДИ)»,

ismoilov_mi@mail.ru

СРАВНИТЕЛЬНЫЙ АНАЛИЗ РЕЛЯЦИОННОЙ БАЗЫ ДАННЫХ И ДОКУМЕНТООРИЕНТИРОВАННОЙ NOSQL БАЗЫ ДАННЫХ В РАЗРЕЗЕ ИХ ПРИМЕНЕНИЯ ПРИ СОЗДАНИИ ЛОКАЛЬНОГО ЧАТА/МЕССЕНДЖЕРА

Аннотация

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

Ключевые слова

Постреляционные базы данных, NoSQL, мессенджер, документоориентированная модель,

реляционные базы данных.

Введение

Долгие годы в мире хранилищ данных безраздельно властвовала реляционная модель. Она идеально подходила под большинство решаемых задач, удовлетворяла все имеющиеся потребности по функциональности, масштабируемости и скорости обработки запросов, однако, современные реалии внесли свои изменения в требования к базам данных. Развитие интернета и интернет-сервисов, таких как поисковики, онлайн-магазины, онлайн-аукционы, мессенджеры, социальные сети и т.д. поменяли сам принцип работы с хранимыми данными, многократно увеличился их объём и количество обращений в единицу времени, существующая модель стала всё сильнее ограничивать разработчиков в возможностях. Эти факторы вынудили искать решение всё разрастающейся проблемы и привели к возникновению целого класса новых моделей хранения данных, получившего название NoSQL. В этой работе мы попытаемся разобраться, какая модель данных наилучшим образом подходит для работы с простейшим мессенджером, классическая реляционная или новая NoSQL ключ-значение.

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

Реляционные базы данных

История развития реляционных баз данных начинается с 1970 года, когда Эдгар Франк Кодд, работник IBM, разработал реляционную модель данных. С тех пор и по наши дни эта модель является доминирующей в мире баз данных. Все реляционные базы данных придерживаются ACID-принципов:

Atomicity - атомарность (гарантия того, что любая транзакция либо будет выполнена целиком, либо не будет выполнена вовсе).

Consistency - согласованность (гарантия того, что каждая успешная транзакция фиксирует только допустимые бизнес-правилами и ограничениями базы данных результаты).

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

Durability - долговечность (гарантия того, что изменения, внесённые успешной транзакцией, в случае сбоя системы, после её восстановления не будут потеряны).

Преимущества

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

Заранее определённая схема данных позволяет переложить большую часть проверок их целостности на СУБД, тем самым избегая усложнения логики работающего с БД приложения.

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

К числу положительных сторон можно также отнести разработанный и стандартизированный язык запросов SQL, использующийся при обращении к данным. Несмотря на то, что многие производители СУБД используют свои расширения SQL, переход с одной СУБД на другую требует минимальных как человеческих, так и финансовых затрат.

Недостатки

Но у реляционной модели данных имеются и существенные недостатки. В современном мире количество данных растёт лавинообразно, хранение их на одном сервере становится всё дороже и сложнее в техническом плане, для многих компаний на первое место встаёт лёгкость горизонтального масштабирования и быстрота обработки запросов, а не согласованность и атомарность транзакций. В этих условиях соблюдение ACID-принципов значительно снижает производительность БД, требует разработки схемы разделения данных по серверам, ввода программных надстроек для балансировки нагрузки и синхронизации данных между ними, контроля изолированности транзакций и т.д.

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

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

NoSQL база данных с документоориентированной моделью

NoSQL модели создавались с целью прикрыть слабые места реляционных баз данных и для решения

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

Рассмотрим пример. Предположим, нам надо создать простую базу данных, содержащую информацию о факультетах университета. Каждый факультет имеет сотрудников и студентов. Каждый студент, в свою очередь, обладает набором собственных параметров, таких как номер студенческого билета, имя и т.д. Возможная схема БД изображена на рисунке 1. База данных, содержащая коллекции документов, выделена оранжевым цветом, коллекции документов отмечены серым цветом, а сами документы - белым. Как видно из рисунка, некоторые коллекции (факультет 1, факультет 2, факультет 3, факультет 4) содержат в себе лишь вложенные коллекции, другие же коллекции (студенты, сотрудники) содержат в себе документы, характеризующие какие-либо объекты.

Рисунок 1 - Схема БД факультетов

Преимущества

Как видно из рисунка 1, документоориентированная модель характеризуется отсутствием чёткой схемы данных. Отсутствие заранее определённой задекларированной схемы позволяет разработчикам менять её «налету», в любой момент редактируя или удаляя уже имеющиеся коллекции и добавляя новые без необходимости переноса данных в обновлённую схему. Это свойство крайне удобно при создании динамически меняющегося продукта с постоянно увеличивающимся набором функций и возможностей.

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

NoSQL СУБД использую собственные API для манипулирования данными, которые зачастую во много раз проще разработанного для реляционных БД языка SQL. Это позволяет значительно ускорить обучение работников и снизить порог вхождения в профессию. Недостатки

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

NoSQL СУБД обладают достаточно простым API манипулирования данными, однако, из-за отсутствия стандартов, каждый производитель создаёт свой собственный, уникальный интерфейс взаимодействия, из-за чего перенос базы данных проекта на другую СУБД требует значительной переработки его программного кода. Также отсутствие стандартизированного языка запросов негативно сказывается на количестве специалистов, обладающих компетенциями в области конкретных СУБД, поскольку знания и опыт работы в одной системе абсолютно неприменимы при использовании другой.

Основным же недостатком всех NoSQL систем является их молодость. Они находятся лишь на начальном этапе своего развития, формирования концепции и принципов функционирования, что выражается в большом количестве ошибок, появлении сбоев в работе и ненадёжности. Описание простейшего мессенджера

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

Мессенджер - служба мгновенного обмена сообщениями через сеть интернет. Современные мессенджеры обладают очень большой аудиторией пользователей и каждый день пересылают огромное количество сообщений. К примеру, в WhatsApp зарегистрировано более 1 млрд человек и ежедневно отправляется свыше 60 млрд сообщений, его сервера испытывают постоянную высокую нагрузку и требуют периодического увеличения мощностей, а давление со стороны конкурентов вынуждает внедрять новые функции, влекущие за собой изменение схемы данных. На мой взгляд, мессенджер - идеальный выбор для тестирования возможностей реляционной и документоориентированной баз данных.

Наш простейший мессенджер будет обладать следующими возможностями: регистрация в мессенджере, создание новых диалогов, приём и отправка сообщений. Условия проведения исследования Описание характеристик сервера Процессор: Intel Core i5 3230M 2,60 GhHz Оперативная память: DDR3 4 Gb 798,1 MHz Видеокарта: NVIDIA GeForce GT 740M 2048 MBytes DDR3 Жёсткий диск: Samsung ST1000LM024 5400 rpm 1000 GB Операционная система: Windows 10 x64 Версия: 1709 Сборка 16299.125 ПО реляционной базы данных Microsoft SQL Server 2014 ver.12.0.2000.8 ПО документоориентированной NoSQL базы данных MongoDB 3.4 с графическим интерфейсом Robomongo (Robo 3T) ver. 1.1

Сравнительный анализ реляционной и документоориентированной NoSQL базы данных Реляционная база данных

Для проведения тестирования реляционной базы данных мною была выбрана Microsoft SQL Server, работающая под операционной системой Windows. Исходя из возможностей нашего мессенджера определим схему данных, способную поддерживать заданный функционал и изобразим её на рисунке 2.

users

id name

dialogs - -

У id id_user1 rd_user2

■od messages

9 id Id dialog

tort

time

id_user

Рисунок 2 -Схема данных для мессенджера в MS SQL Server Рассмотрим её более подробно.

Таблица users - содержит информацию о зарегистрированных в сервисе пользователях. Атрибуты:

• id - первичный ключ, телефонный номер пользователя, являющийся его уникальным идентификатором (для упрощения будем использовать целочисленный порядковый номер)

• name - имя пользователя

Таблица dialogs - содержит информацию о всех диалогах пользователей и об участниках диалогов. Атрибуты:

• id - первичный ключ, уникальный номер диалога

• id_user1 - внешний ключ, уникальный номер первого собеседника

• id_user2 - внешний ключ, уникальный номер второго собеседника

Таблица messages - содержит пересылаемые сообщения, время их отправки и отправителя. Атрибуты:

• id - первичный ключ, уникальный номер каждого сообщения

• id_dialog - внешний ключ, уникальный номер диалога, в котором отправлено сообщение

• text - текст сообщения

• time - дата и время отправки сообщения

• id_user - внешний ключ, уникальный номер отправителя сообщения

Теперь, когда схема данных сформирована, нам необходимо заполнить базу и вычислить время её заполнения. Для этого напишем запросы на языке SQL и сгенерируем 3 млн пользователей (Рис.3), 9 млн диалогов (Рис.5) и 9 млн сообщений (Рис.7).

Создание пользователей (регистрация)

insert^into users(name) values('Пользователь' + convert(varchar(B),

Рисунок 3 - SQL запрос генерирования пользователей Как видно из рисунка 4, на создание 3 млн пользователей понадобилось 8 минут 11 секунд.

(Отсутствует имя столбца) [ 2017-01-3014:29:46-263

(Отсутствует имя столбца)

Рисунок 4 - Время начала и окончания генерирования пользователей

Создание диалогов

select getCatel) declare §1 Int. set (1 - 1; declare ft lnt; set ft . 3eeee7e Ceclare fip Int. ••niie fi < leeeeei

begin

set Sp - e. «hlle Sp < 3 begin

Insert Into dialogs id_userl id_user2 values £1. i* set Sp - Sp - 1, set ft - ft - 1. end

set SI - fi * 1.

end

set si - ieeeeei

set ft - ггггг-г «hiie $i < leeeeei begin

set Sp - e. mMIc Sp < 3 begin

insert into dialogs id_userl id_userl values £1 S; set fp - Sp - 1; set ft - ft - 1, end

set fl - §1 ♦ 1; end

set si - leeeeei set ft . зеееете »niie si < seeeeei

begin

set fp - e. »Mile Sp < 3 begin

insert into dialogs id_userl id_user2 values £1 f' set $p - Sp - 1; "t ft - ft 1

end

set fi - fi - 1. end

select getcate

Рисунок 5 - SQL запрос генерирования диалогов

Как видно из рисунка 6, на создание 9 млн диалогов понадобилось 24 минуты 54 секунд 200 миллисекунд.

(Отсутствует имя столбца) [ 20174)1-30 15:30:32 . ¿47 ]

(Отсутствует имя столбца) Га170КЮ 15:55:27.047...........1

Рисунок 6 - Время начала и окончания генерирования диалогов

~ 78 ~

Создание сообщений (отправка/приём сообщений)

select getdate() declare (jJi int set = 1; while (Si < 3000000 begin

insert into Tessages id_dialog. text, time.id_user)

values (§i, 'Привет', getdate (), (3i) : insert into Tessages id_dialog. text, time.id_user)

values(§i, 'Как дела?', getdate(), (jjlij: insert into Tessages id_dialog. text, time.id_user)

values (@i, *У меня хорошо', getdate(), (jjli) : set gi = @i + 1 end

select getdate()

Рисунок 7 - SQL запрос генерирования сообщений

Как видно из рисунка 8, на создание 9 млн сообщений понадобилось 24 минут 22 секунды 914 миллисекунд.

(Отсутствует имя столбца) [2017^^219:53:^403...........]

(Отсутствует ими столбца)

| 2017Ч№20:17:ШТ7]

Рисунок 8 - Время начала и окончания генерирования сообщений

Занесём полученные данные в таблицу 1:

Таблица 1

Время выполнения операций реляционной БД

Название Время выполнения

Создание пользователей 8 минут 11 секунд

Создание диалогов 24 минуты 54 секунды 200 миллисекунд

Создание сообщений 24 минуты 22 секунды 914 миллисекунд

Документоориентированная NoSQL база данных

Для проведения тестирования документоориентированной базы данных мною была выбрана MongoDB, работающая под операционной системой Windows, а также графический интерфейс к ней -Robomongo. Исходя из возможностей нашего мессенджера определим предполагаемое отображение данных, способное поддерживать заданный функционал и изобразим его на рисунке 9.

Рисунок 9 - Отображение данных в документоориентированной NoSQL БД

~ 79 ~

Теперь, когда отображение данных определено, нам необходимо заполнить базу и вычислить время её заполнения. Для этого напишем запросы и сгенерируем 3 млн пользователей, 9 млн диалогов и 9 млн сообщений.

Создание пользователей (регистрация)

Запрос генерирования пользователей: for (var i = 0; i < 3000000; i++) { db.users.insert({id: i, name: "Пользователь "+i})

}

Время начала выполнения запроса: 00:37:09.820

Время окончания выполнения запроса: 01:01:08.893

Итого времени затрачено: 23 минуты 59 секунд 73 миллисекунды

Создание диалогов

Запрос генерирования диалогов: var j = 0;

for (var i = 1; i < 3000000; i++) {

db.dialogs.insert({id: j, id_user1: i, id_user2: i+1});

j++;

db.dialogs.insert({id: j, id_user1: i, id_user2: i+2});

j++

db.dialogs.insert({id: j, id_user1: i, id_user2: i+3});

j++

}

Время начала выполнения запроса: 01:19:22.922

Время окончания выполнения запроса: 02:40:42.385

Итого времени затрачено: 1 час 21 минута 19 секунд 463 миллисекунды

Создание сообщений (отправка/приём сообщений)

Запрос генерирования сообщений: var j = 0;

for (var i = 0; i < 3000000; i++) {

db.messages.insert({id: j, id_dialog: i, text: "Привет", time: db.system.time(), visible_user1: 1,

visible_user2: 1, id_user: i});

j++;

db.messages.insert({id: j, id_dialog: i, text: "Как дела?", time: db.system.time(), visible_user1: 1,

visible_user2: 1, id_user: i});

j++;

db.messages.insert({id: j, id_dialog: i, text: "У меня хорошо", time: db.system.time(), visible_user1: 1,

visible_user2: 1, id_user: i});

j++;

}

Время начала выполнения запроса: 17:51:04:892

Время окончания выполнения запроса: 19:09:44.664

Итого времени затрачено: 1 час 18 минут 39 секунд 772 миллисекунды

Занесём полученные данные в таблицу 2:

Таблица 2

Время выполнения операций NoSQL БД

Название Время выполнения

Создание пользователей 23 минуты 59 секунд 73 миллисекунды

Создание диалогов 1 час 21 минута 19 секунд 463 миллисекунды

Создание сообщений 1 час 18 минут 39 секунд 772 миллисекунды

Сравнение быстродействия баз данных Регистрация пользователей (Таблица 3)

Таблица 3

Время выполнения запроса на генерирование 3 млн пользователей

Реляционная база данных Документоориентированная NoSQL база данных

8 минут 11 секунд = 491 23 минуты 59 секунд 73 миллисекунды = 1439,73 секунды

Построим диаграммы для наглядного отображения скорости выполнения запроса (Рис.10):

ISQLTO UNtlMlOB

Рисунок 10 - Сравнительные диаграммы времени выполнения запроса на генерирование 3 млн пользователей

Если взять за 100 % время работы постреляционной базы данных, то классическая реляционная база данных справляется с той же задачей в 3 раза быстрее, что равно 34,10 % от времени работы NoSQL БД. Создание диалогов (Таблица 4)

Таблица 4

Время выполнения запроса на генерирование 9 млн диалогов

Реляционная база данных Документоориентированная NoSQL база данных

24 минуты 54 секунды 200 миллисекунд = 1494,2 секунды 1 час 21 минута 19 секунд 463 миллисекунды = 4879,463 секунды

Построим диаграммы для наглядного отображения скорости выполнения запроса (Рис.11):

»5QIРВ ■ NnSQJ. РВ -SGLDB - NaSQLDB

Рисунок 11 - Сравнительная диаграмма времени выполнения запроса на генерирование 9 млн диалогов

- 81

~ Л I ~

Если взять за 100 % время работы постреляционной базы данных, то классическая реляционная база данных справляется с той же задачей чуть менее чем в 3 раза быстрее, что равно 30,62 % от времени работы NoSQL БД.

Приём/отправка сообщений (Таблица 5)

Таблица 5

Время выполнения запроса на генерирование 9 млн сообщений

Реляционная база данных Документоориентированная NoSQL база данных

24 минуты 22 секунды 914 миллисекунд = 1462,914 секунды 1 час 18 минут 39 секунд 772 миллисекунды = 4719,772 секунды

Построим диаграммы для наглядного отображения скорости выполнения запроса (Рис.12):

| «они СИ а ад ой * Мейси [

Рисунок 12 - Сравнительная диаграмма времени выполнения запроса на генерирование 9 млн сообщений

Если взять за 100 % время работы постреляционной базы данных, то классическая реляционная база данных справляется с той же задачей чуть менее чем в 3 раза быстрее, что равно 31,00 % от времени работы NoSQL БД.

Средние показатели скорости работы (Таблица 6)

Таблица 6

Сводная таблица времени выполнения запросов

SQL DB (сек) NoSQL DB (сек)

Регистрация пользователей 491 1439,73

Создание диалогов 1494,2 4879,463

Приём/отправка сообщений 1462,914 4719,772

Среднее время работы системы 1149,371 3679,655

Построим диаграмму для наглядного отображения скорости выполнения запросов (Рис.13):

Среднее время работы системы

iSQLDB ■NoSQL DB

Рисунок 13 - Сравнительная диаграмма среднего времени выполнения запросов

~ 82 ~

По итогам трёх проведённых тестов видно, что в заданных условиях классическая реляционная база данных работает в среднем на 70% быстрее постреляционной документоориентированной базы. Исходя из этого можно сделать вывод, что постреляонная база данных подобного типа не подходит для проектов с малым количеством пользователей и нерастпределённым хранилищем.

©Якушин А.Ю., Муковозов А. М., Исмоилов М.И., 2018