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

Введение

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

Целью настоящей работы является сравнение реляционных и NoSQL баз данных на примере PostgreSQL и MongoDB соответственно.

Маркетплейс как сценарий сравнения реляционных и NoSQL баз данных

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

При использовании реляционной базы данных естественным решением является нормализованная схема базы данных с таблицами orders, order_items, payments и т.д. Поиск товаров с фильтрацией может выполняться с помощью индексов.

Однако маркетплейсы имеют разнообразный каталог товаров. Именно он становится узким местом в реляционной модели данных: атрибуты каждого товара различные, из-за чего требуется использовать модель Entity-Attribute-Value, что резко усложняет запросы и снижает производительность.

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

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

Экспериментальное исследование производительности

Для сравнения производительности PostgreSQL версии 18.4 и MongoDB версии 8.3.7 было проведено экспериментальное исследование на вычислительной машине со следующей конфигурацией: AMD Ryzen 3 3100, 16 ГБ оперативной памяти и операционная система Windows 11 25H2. Тестирование проводилось с применением бэкэнд приложения написанного на языке Java 21 с фреймворком Spring версии 4.1.0.

Нагрузочное тестирование проводилось на протяжении одной минуты 50 виртуальными пользователями. Нагрузка генерировалась с учетом паттернов, характерных для двух рассмотренных сценариев. Создание нагрузки проводилось с помощью ПО Grafana K6 версии 2.1.0.

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

Для PostgreSQL таблицы были нормализованы в соответствии с третьей нормальной формой. Были созданы связанные сущности products и attributes. Сущность products хранит основные сведения о товаре, а сущность attributes - пары ключ-значение – название атрибута и его значение, связанные с товаром отношением один ко многим через внешний ключ. Для ускорения запросов были созданы индексы на внешние ключи сущностей (идентификатор продукта и категории).

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

Тестовый сценарий включал пакетную вставку 100 продуктов от 50 виртуальных пользователей, а также чтение 1000 товаров с фильтрацией товаров по категориям.

Таблица 1.

Результаты сравнения производительности пакетной вставки данных

Таблица 2.

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

По результатам тестирования пакетной вставки продуктов в PostgreSQL, было выполнено 1056 итераций. Задержка выполнения запроса по 95-му перцентилю составила 1.58 секунд, что является ощутимым.

Для MongoDB аналогичный показатель составил 0.1 секунды, что в 15 раз меньше значения, полученного для PostgreSQL в данном сценарии тестирования.

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

По результатам тестирования чтения товаров с фильтрацией по категориям было выполнено 211 итераций. Задержка выполнения запроса в PostgreSQL по 95-му перцентилю составила 11 секунд, что существенно превышает показатель, полученный в тесте вставки.

Для MongoDB 95-й перцентиль составил 0.4 секунд, что выше, чем при вставке, но значительно ниже значения для PostgreSQL в данном тесте (примерно в 27 раз).

Из-за того, что задавалось общее время выполнения, количество завершенных операций между тестами различается. Операции вставки выполнялись быстрее операции чтения, поэтому за одну минуту в тесте вставки было завершено 1056 итераций, тогда как в тесте чтения - только 211. Поскольку в каждой итерации запрос направлялся последовательно к обеим СУБД, количество операций для PostgreSQL и MongoDB в рамках одного теста совпадало, что гарантировало симметричность и корректность сравнения.

Таким образом, документно-ориентированная NoSQL база данных MongoDB продемонстрировала более низкие задержки. Это объясняется тем, что документная модель позволяет извлекать товар вместе с вложенными атрибутами без выполнения соединений между таблицами. Следует отметить, что в данном эксперименте сравниваются не только сами СУБД, но и различные подходы к организации данных: нормализованная схема в PostgreSQL и денормализованная документная модель в MongoDB. Поэтому зафиксированное снижение задержек при работе с MongoDB обусловлено спецификой выбранного сценария хранения каталога товаров и не является универсальной характеристикой производительности данной СУБД для иных классов задач.

Заключение

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

Реляционная модель данных все еще остается предпочтительным решением в системах, где критично обеспечение целостности операций. Использование нормализации позволяет избежать аномалий данных и избежать противоречий между ними. Между тем, сценарий каталога маркетплейса демонстрирует ограничения реляционного подхода. Необходимость хранения атрибутов товара приводит к использованию модели Entity-Attribute-Value, что снижает производительность запросов.

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

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