🪴 BLOG IT

Перестаньте использовать MongoDB как SQL

4 min read

MongoDB — это не просто «SQL без таблиц». Это совершенно другая парадигма. Если вы подходите к MongoDB с реляционным мышлением, вы, скорее всего, столкнетесь с плохо работающими запросами, лишней сложностью и разочаровывающим опытом разработки.

Многие разработчики совершают ошибку, применяя традиционные принципы проектирования SQL, такие как нормализация и строгая реляционная модель, непосредственно в MongoDB. Хотя эти идеи отлично подходят для реляционных баз данных, в MongoDB они часто приносят больше вреда, чем пользы.

Ошибка 1: Нормализация всего

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

Но MongoDB оптимизирована для производительности и гибкости. Она поощряет встраивание связанных данных в один документ, чтобы уменьшить необходимость в объединениях и улучшить эффективность чтения.

Реляционный подход (SQL):

  • таблица users

  • таблица posts с user_id как внешним ключом

Подход, основанный на документах (MongoDB):

{
  "_id": 1,
  "name": "Alice",
  "posts": [
    { "id": 101, "title": "My first post" },
    { "id": 102, "title": "Another update" }
  ]
}

Встраивание данных таким образом имеет смысл, когда отношение “один ко многим” и встроенные документы не нужны отдельно.

Ошибка 2: Чрезмерное использование ссылок

В SQL ссылки (внешние ключи) являются основой целостности данных. Но в MongoDB они часто приводят к неэффективным операциям. Каждая ссылка требует отдельного запроса или агрегации с использованием $lookup, что увеличивает сложность и снижает производительность.

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

Ошибка 3: Мнение, что объединения бесплатны

MongoDB поддерживает объединения через оператор $lookup в агрегациях. Но они не такие быстрые и удобные, как в SQL. Производительность MongoDB лучше всего проявляется, когда их вообще избегать.

Если вы пишете запросы, имитирующие сложные объединения нескольких таблиц, сделайте шаг назад. Задайтесь вопросом, можно ли перепроектировать модель данных, чтобы уменьшить необходимость в объединениях. Часто это можно решить с помощью встроенных документов или тщательной денормализации.

Ошибка 4: Проектирование с оптимизацией записи вместо чтения

SQL базы данных часто оптимизированы для записей и согласованности, особенно в нормализованных схемах. MongoDB, с другой стороны, оптимизирована для ваших паттернов чтения.

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

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

Ошибка 5: Игнорирование ограничений по размеру документа

MongoDB имеет лимит на размер документа в 16 МБ. Если вы слишком сильно встраиваете данные, то можете столкнуться с этим ограничением. Важно сбалансировать встраивание с использованием ссылок, особенно в отношениях, которые могут расти бесконечно, например, история транзакций пользователя или системные журналы.

Используйте встраивание для ограниченных, тесно связанных данных. Используйте ссылки для неограниченных, слабо связанных данных.

Как думать в стиле MongoDB

  1. Начните с паттернов запросов: проектируйте схему на основе того, как ваше приложение читает данные.

  2. моделирование документов: группируйте связанные данные в один документ, когда это возможно.

  3. Оптимизируйте: уменьшите количество обращений к базе данных.

  4. Не бойтесь дублирования: в мире NoSQL избыточность данных иногда является особенностью, а не недостатком.

  5. Мониторьте и улучшайте: используйте профайлер MongoDB и инструменты мониторинга, чтобы выявлять медленные запросы и изменять данные соответственно.

Заключение

MongoDB — это не просто замена SQL базы данных. Это мощный инструмент, но только если вы используете его по его правилам. Понимание его модели, ориентированной на документы, открывает возможности для гибкости и масштабируемости. Неправильное использование MongoDB приводит к разочарованию и узким местам.

Если вы постоянно используете ссылки, объединения или нормализацию — сделайте паузу и переосмыслите. Возможно, вы неправильно используете MongoDB.

Graph View

Backlinks