MongoDB

MongoDB — правильный выбор, когда данные по своей природе документо-ориентированы с вложенными структурами и переменными атрибутами для каждой записи. Каталоги товаров, где у каждой категории свои уникальные поля (у электроники — напряжение и подключения, у одежды — размеры и материалы), — классический пример. PostgreSQL потребовал бы либо разреженных колонок, либо сложного EAV-паттерна. MongoDB также выигрывает для IoT-слоёв приёма миллионов показаний датчиков с гетерогенными схемами, пайплайнов логирования событий и CMS, где структуры страниц различаются по типу. Если вашей нагрузке нужны сложные многотабличные JOIN, строгая ссылочная целостность или ACID-транзакции между коллекциями, PostgreSQL остаётся лучшей основой.

Шардирование MongoDB распределяет данные по нескольким серверам на основе shard-ключа, обеспечивая линейное масштабирование пропускной способности записи. Правильно выбранный shard-ключ — обычно хешированное поле с высокой кардинальностью — гарантирует равномерное распределение без горячих точек. В продакшене шардированные кластеры, которые мы развёртывали, обрабатывают 50 000+ операций записи в секунду на трёх и более шардах. MongoDB 7.0 ввёл queryable encryption и улучшил производительность балансировщика, делая ребалансировку менее разрушительной для живого трафика. Для нагрузок с преобладанием чтения replica sets с secondary-preferred read preference распределяют запросы между нодами.

Три самые частые проблемы производительности MongoDB — неконтролируемый рост документов, отсутствие индексов на паттернах запросов и неудачный выбор shard-ключей. Документы, растущие через push в массивы без ограничений, могут превысить лимит BSON в 16 МБ и деградируют по производительности чтения задолго до этого предела — мы устанавливаем лимиты на размер массивов и выносим исторические данные в отдельные коллекции. Отсутствие составных индексов заставляет выполнять collection scan при фильтрованных запросах — мы планируем индексы при проектировании схемы. Плохие shard-ключи создают горячие точки, когда один шард обрабатывает непропорциональный трафик — мы тестируем распределение ключей с продакшен-подобными объёмами данных.

Цены MongoDB Atlas начинаются примерно от $57/месяц за M10 shared-инстанс для разработки, а продакшен-кластеры M30 с 8 ГБ RAM и автоматическими бэкапами стоят порядка $400-600/месяц. Self-hosted replica set на AWS с тремя r6g.large инстансами (16 ГБ RAM каждый) обходится примерно в $350/месяц только за вычисления, плюс инженерное время на управление бэкапами, мониторинг и апгрейды. Atlas экономит 15-20 часов операционной работы в месяц, но стоит на 30-50% больше по прямым расходам. Для команд без выделенного DBA Atlas обычно более выгоден. Для организаций с существующими DevOps-командами и строгими требованиями к резидентности данных self-hosted на EKS или bare metal даёт больше контроля.

Aggregation Pipeline — фреймворк MongoDB для трансформации и анализа данных непосредственно в базе. Он обрабатывает документы через последовательность стадий: $match для фильтрации, $group для агрегации, $lookup для джойнов, $unwind для развёртки массивов и $project для преобразования полей. Он идеален для расчёта метрик бизнес-аналитики, сессионизации потоков событий, построения воронок и генерации отчётов без экспорта данных в отдельный аналитический движок. Производительность зависит от правильного порядка стадий: размещение $match в начале сокращает количество документов для последующих стадий, а индексы на полях $match и $sort обеспечивают использование index scan вместо collection scan.