MySQL или MongoDB: что выбрать

MySQL или MongoDB: что выбрать

Какая СУБД подойдет для ваших задач.

Все базы данных (БД) можно поделить на две группы — реляционные (SQL) и нереляционные (NoSQL). У них разные подходы к организации и структурированию информации. 

Вместе с Антоном Бондарем, Big Data Consultant и лектором курса Data Engineering, разбираемся в SQL и NoSQL.

Чем отличаются модели баз данных 

В основе реляционных БД — математика (например, теория множеств). Данные заранее описываются внутри таблиц, а таблицы связываются между собой по внешним ключам и JOIN. В итоге вы получаете четкую схему данных (так устроена MySQL). Нереляционные БД могут быть основаны на графах, документах, объектах, парах «ключ-значение» и хранить данные без явных механизмов связывания. Схема БД получается динамической (этот подход используется в MongoDB).

MySQL: плюсы и минусы 

MySQL считается решением по умолчанию для задач, где нужны реляционные БД. Она доступна на всех платформах, а многие сервисы (например, хостинги) поддерживают ее «из коробки». К тому же MySQL бесплатна и имеет открытый исходный код, а ее структурированность обеспечивает простоту работы. У разных реляционных систем управления базами данных (РСУБД) — почти одинаковый синтаксис, не нужно будет переучиваться.

Строгая организация данных усложняет изменение структуры БД: чем больше таблиц, связей и самих данных, тем труднее. Если нужно улучшать производительность БД, придется выбрать вертикальное масштабирование. При горизонтальном вы можете использовать реплики БД для чтения. Но чем их больше, тем сложнее согласовывать данные между ними.

Антон: «Если данные структурированы, реляционные базы данных — отличный выбор. РСУБД обеспечивают целостность данных и поддерживают ACID-транзакции, что очень важно в высоконагруженных транзакционных системах».

MongoDB: плюсы и минусы

MongoDB — это документоориентированная СУБД, которая хранит данные в виде JSON, коллекции — вместо таблиц, а в качестве языка использует MQL (MongoDB Query Language). То, что данные не нормализованы, позволяет менять дизайн хранилища. Например, вы можете добавлять новые поля без ущерба для имеющихся данных, а значит, не нужно переписывать готовую бизнес-логику. C точки зрения безопасности, плюс NoSQL СУБД — невозможность SQL-инъекций. Но есть и недостатки. Например, MongoDB поддерживает регулярные выражения для сопоставления строковых шаблонов, а в них можно встроить инъекцию. 

Еще одна проблема NoSQL — отсутствие поддержки хранимых процедур (логику БД придется писать на уровне приложения). Как следствие, MongoDB не очень подходит для аналитики, отчетности и обработки данных.

Антон: «NoSQL-решения могут быть ACID compliable. Они способны обеспечить аналогичную РСУБД безопасность транзакций, но с некоторыми условиями. Например, MongoDB смогла поддерживать аналогичную РСУБД безопасность транзакций только с версии 4.2. Но главное преимущество нереляционных БД — возможность горизонтального масштабирования. Благодаря ему вы повышаете производительность, но не снижаете отказоустойчивость».

Производительность и безопасность

При тестировании быстродействия нужно учитывать дизайн БД и нагрузку. Бенчмарк не всегда корректен, так как у MongoDB и MySQL разные подходы к хранению и работе с данными. Часть операций работает медленнее или недоступна на разных СУБД. Например, MongoDB не поддерживает операции JOIN, а MySQL работает медленнее при удалении данных без индекса.

Alt text

Анализ запросов в MySQL, PostgreSQL, MongoDB / Петр Зайцев (Percona)

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

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

Ещё статьи
Инструкция от Product Analyst Lead в SQUAD.
История, архитектура и основы обучения.