Scientific journal

Modern high technologies

ISSN 1812-7320

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

ИФ РИНЦ = 0,940

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

Наиболее часто в качестве СУБД выбирается реляционная система, которая идеально решает задачи обеспечения целостности данных и многие другие, но она уступает при работе с большими данными. При этом использование NoSQL баз данных (БД) позволяет работать с большими данными. Однако при использовании реляционных СУБД требуется тщательная подготовка на этапе проектирования системы, так как структура данных должна быть определена заранее. В свою очередь NoSQL СУБД не требуют такого тщательного процесса проектирования баз данных, потому что они работают с гибкими схемами, благодаря которым приложение можно реализовывать поэтапно. Цель выполненного исследования – проанализировать характеристики реляционных и нереляционных СУБД, влияющие на проектирование и разработку программного обеспечения, дать рекомендации о применимости систем.

Сравнение характеристик SQL И NoSQL СУБД

На данный момент наиболее используемыми типами баз данных являются реляционные (SQL) и нереляционные (NoSQL) БД. Как видно из табл. 1, самыми распространенными в 2022 г., согласно рейтингу DB-Engines, являются реляционные СУБД: Oracle, MySQL и Microsoft SQL Server [1].

В табл. 2 представлены популярные в 2022 г. нереляционные системы, где самыми популярными СУБД являются: MongoDB, Redis и Cassandra [1].

Рассмотрим характеристики, влияющие на разработку БД, при проектировании схем баз данных в реляционной и нереляционной СУБД на примерах двух систем: MySQL и MongoDB.

Основное различие между двумя системами: MySQL и MongoDB заключается в том, что при реляционном подходе необходима тщательная подготовка перед разработкой БД [2]. При проектировании реляционной схемы базы данных для бизнес-процесса «Создание публикаций на веб-сайте» проводится анализ предметной области, логическое и физическое проектирование. Также определяются сущности, необходимые для данного бизнес-процесса, их атрибуты, типы данных и связи между сущностями. В ходе выполнения этапов проектирования получена реляционная модель данных, представленная на рис. 1.

Таблица 1

Рейтинг популярности реляционных СУБД

Таблица 2

Рейтинг популярности нереляционных СУБД

Рис. 1. Реляционная схема базы данных на примере MySQL

Рис. 2. Сопоставление таблиц MySQL с документами MongoDB

При использовании нереляционного подхода приложение можно проектировать сразу же без такой тщательной подготовки.

В MongoDB базы данных состоят из коллекций, которые являются эквивалентами таблиц в реляционных СУБД. В коллекциях хранятся данные в виде документов. Документ эквивалентен строке в таблице. Только в строке данные представлены в виде набора колонок, а в документе данные представлены в виде JSON-структуры (известной как BSON в MongoDB). И если в реляционных БД в строке имеются столбцы, то в MongoDB – поля. На рис. 2 представлены таблицы из MySQL и их отображение в MongoDB.

Еще одно из отличий MongoDB от MySQL заключается в том, что MongoDB обладает динамической схемой данных [3]. То есть один документ может иметь два поля, а второй – пять. Это позволяет легко добавлять и удалять поля. При использовании MySQL схему данных необходимо определить заранее, чтобы достичь согласованности. Также отметим, что при нереляционном подходе на тип данных поля не накладываются ограничения. Другими словами, одно и то же поле в одном документе может иметь данные типа int (целое значение), а в другом содержать тип array (массив).

Рассмотрим пример. В коллекции «users» можно создать документы с разной структурой. На рис. 3 представлены документы с разной структурой в одной коллекции.

Рис. 3. Документы с разной схемой

Во второй документ добавили поля age и favorite_themes. При этом второе поле имеет несколько значений. При реляционном подходе в таблицу, которая хранит информацию о пользователях, необходимо было бы добавить поле age, а также создать как минимум одну таблицу для описания любимых тем пользователя. Таким образом, в виде документов можно эффективно реализовывать различные схемы, при этом при использовании реляционного подхода потребовалось бы несколько таблиц. Например, при проектировании в MySQL получилось три таблицы, а MongoDB позволяет несколько объектов объединить в один документ (рис. 4).

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

Однако, так как в MongoDB нет ограничений и правил на внешние ключи, то необходимо аккуратно относиться к связям и операциям над ними. Например, поле id_author в документе из коллекции «posts» является просто полем, которое содержит данные, и вся логика, связанная с их интерпретацией, должна быть реализована в приложении. То есть, если в id_author вставить ссылку на несуществующий документ из коллекции «users», то в MongoDB не возникнет ошибка о том, что соответствующая запись с таким идентификатором в коллекции «users» не была найдена. При этом в реляционной СУБД возникнет ошибка.

Для манипуляции данными MySQL использует язык SQL, а MongoDB – JavaScript [4]. Несмотря на разницу используемых подходов для работы с данными MongoDB отлично справляется со всеми типовыми задачами.

MongoDB обладает еще одним существенным преимуществом перед MySQL, заключающемся в функциях репликации и сегментирования, так как это решает проблему с масштабируемостью, характерную для реляционных систем [5]. При использовании реляционного подхода в основном реализуется возможность вертикального масштабирования.

Основные характеристики, влияющие на процесс разработки приложений баз данных, представлены в табл. 3.

Рис. 4. Объединение таблиц в один документ на примере MongoDB

Рис. 5. Варианты связей между документами в MongoDB

Таблица 3

Сравнительные параметры реляционной MySQL и нереляционной MongoDB СУБД

СУБД MySQL лучше выбрать при следующих условиях:

− имеются логические требования к данным, которые могут быть определены заранее;

− необходимо обеспечивать целостность данных;

− имеется достаточный опыт работы и хорошая техническая поддержка проекта;

− может понадобиться быстрый переход с одной СУБД на другую.

При выборе MongoDB целесообразно придерживаться следующих рекомендаций:

− при проектировании базы данных для обеспечения гибкости системы необходимо учитывать требования пользователей;

− объединение объектов в один документ следует производить при их совместном использовании, в других вариантах их желательно хранить в разных документах;

− допускается частичное дублирование данных, так как это может уменьшить время вычислений;

− объединение данных лучше выполнять при записи самих данных, а не при их чтении;

− необходима оптимизация схемы базы в соответствии с наиболее частыми запросами данных.

Заключение

Представлен сравнительный анализ характеристик реляционных и нереляционных СУБД, влияющих на проектирование и разработку программного обеспечения, даны рекомендации о применимости систем. Анализ проводился на примерах двух СУБД: MySQL и MongoDB. Результат анализа будет полезен для разработчиков приложений, поскольку позволяет первоначально выбрать определенную технологию, однако позже при уточнении требований к системе, может использоваться и другой подход. Показаны характеристики СУБД, по которым можно определить, какая система лучше подойдет для того или иного проекта. MySQL лучше выбрать для проекта, если имеется предопределённая структура и заданные схемы баз данных. Иначе следует выбрать MongoDB, потому что данная СУБД отлично подходит для быстрорастущих проектов без определенной схемы данных. Сравнение характеристик SQL и NoSQL СУБД, влияющих на разработку приложений баз данных, актуально, так как в настоящее время происходит импортозамещение и переход с иностранных сервисов на российские. Иностранные продукты заменяются либо на ПО с открытым исходным кодом, либо на существующие российские аналоги, либо создаются новые отечественные системы. Также согласно указу Президента РФ, уделяется достаточное внимание обеспечению мер для развития информационных технологий [6].