Справочник по MongoDB · разбор реальных случаев
Кейсы
MongoDB
в реальных проектах
Девять случаев из практики: утечки на сотни миллионов записей, одиннадцатичасовой простой большого сервиса, независимый отчёт о транзакциях — и случаи, где база дала измеримый выигрыш. У каждого разобрана причина и указаны источники.
- Зачем раздел
- Цена решений, которые в задаче на занятии выглядят безобидно
- Что внутри
- Девять случаев: три по безопасности, три инженерных, три о выигрыше
- Источники
- Постмортемы, отчёты исследователей, документация
- В каждой карточке
- Что произошло, из-за чего, чем закончилось и ссылки
§0Как читать этот раздел
Источники у этих случаев разные, и надёжность у них тоже разная. Поэтому у каждого указан тип и ссылка, а материалы, опубликованные компанией-поставщиком, помечены отдельно.
Пометка вендорский кейс означает, что историю опубликовала сама MongoDB Inc. В таких материалах публикуют удачные внедрения; неудачные туда не попадают. Числа из них показывают, что получилось в конкретном проекте, — среднего по индустрии по ним не считают. Смотрите, кто опубликовал материал: у поставщика и у независимого исследователя разные причины его писать.
§1Безопасность: сервер, открытый из интернета
27 декабря 2016 года исследователь Виктор Геверс нашёл сервер MongoDB, открытый наружу и без пароля у административной учётной записи. Сначала таких баз было около двухсот; к 8 января 2017 года счёт шёл на 27 663. Схема была одинаковой: злоумышленник подключался, забирал или просто стирал данные и оставлял документ с требованием выкупа — около 0,2 BTC, тогда примерно 211 долларов. В сентябре 2017 года прошла вторая волна: три группы нападавших за несколько дней взяли ещё порядка 26 000 серверов.
- Причина
- Конфигурация сервера: он слушал внешний интерфейс, проверка подлинности не была включена. Уязвимость в самой базе для этого не понадобилась — доступ получали обычным клиентом.
- Что изменилось
- В MongoDB 3.6 (декабрь 2017)
mongodиmongosстали по умолчанию слушать только127.0.0.1. Чтобы открыть сервер наружу, теперь нужно осознанно прописать адрес вnet.bindIp. - Вывод
- Стенд курса без пароля допустим, пока он на вашей машине и не смотрит наружу. Первое, что делают с сервером перед выходом в сеть, — включают проверку подлинности и ограничивают адреса.
25 февраля 2019 года исследователи Боб Дьяченко и Винни Троя нашли общедоступную базу MongoDB на 150 ГБ без пароля. Она принадлежала сервису проверки почтовых адресов Verifications.io. В крупнейшем наборе было 809 миллионов записей, из них 763 миллиона уникальных: адреса почты, телефоны, имена, даты рождения, IP-адреса — открытым текстом. Паролей в утечке не было. Компания закрыла доступ в тот же день, 4 марта сайт отключили, а к середине марта она прекратила работу.
- Причина
- Та же: сервер доступен из интернета, проверка подлинности выключена. Данные хранились без шифрования.
- Особенность
- В базе лежали данные людей, которые о компании не слышали: список для маркетинговой рассылки собирали из сторонних источников.
- Вывод
- Размер утечки задаёт объём собранных данных; штат и известность компании тут ни при чём. Незакрытый порт у подрядчика вывел наружу данные сотен миллионов человек.
6 октября 2023 года посторонний получил доступ к части корпоративных приложений MongoDB Inc. через фишинг. Через сутки сессии истекли, но доступ к корпоративному мессенджеру остался — и 12–14 декабря с уже захваченной учётной записи разослали новые письма сотрудникам, чем вернули себе доступ. Аномалию заметили 13 декабря, клиентов уведомили 16 декабря. Утекли метаданные учётных записей и контакты клиентов.
- Чего не произошло
- По итогам расследования доступа к кластерам — ни в Atlas, ни в самостоятельных установках — у злоумышленника не было, систему аутентификации Atlas он не проходил. Расследование закрыли 3 января 2024 года.
- Вывод
- Угрозы для данных не заканчиваются на порте 27017: в модель угроз входит и учётная запись сотрудника поставщика. Компания опубликовала хронологию по дням, и по ней видно, как инцидент развивался.
§2Инженерия: аварии и споры о поведении базы
4 октября 2010 года сервис отметок Foursquare лежал одиннадцать часов. Данные были разложены на два шарда по 66 ГБ оперативной памяти, изначально примерно по 33 ГБ данных на каждом, разбитых на 200 кусков по идентификатору пользователя. Куски оказались неравными: к моменту аварии на одном шарде было около 50 ГБ, а второй перерос объём памяти — и сервер начал ходить на диск на каждом запросе.
Попытка добавить третий шард и перенести 5% данных не помогла: документы отметок маленькие, около 300 байт, и после удаления пятой части записей страницы остались частично занятыми. Потребовалась офлайн-компакция, занявшая ещё около четырёх часов.
- Причина
- Рост шардов никто не отслеживал. Куски делятся по объёму данных, поэтому одинаковое их число на шардах ещё не означает одинаковый размер.
- Что сделали
- Добавили шарды, перераспределили данные до ~20 ГБ на шард, сжали коллекции. Разработчики базы пообещали инкрементальную компакцию без остановки.
- Вывод
- Рабочий набор должен помещаться в оперативную память. Пока помещается, запросы быстрые; как только перестаёт, скорость падает обрывом, без плавного ухудшения.
Независимая лаборатория Jepsen проверила транзакции MongoDB 4.2.6 и нашла нарушения снимочной изоляции даже на самых строгих настройках чтения и записи: перекос чтения, циклические зависимости, дублирование записей. В отчёте описан случай, который авторы назвали «ретропричинной транзакцией»: чтение видит результат записи, которая произойдёт позже.
Отдельная претензия была к умолчаниям: уровень snapshot не давал снимка, если не сопровождался записью с подтверждением большинства, — даже для транзакций только на чтение. Jepsen рекомендовала заменить в маркетинге слово «ACID» на «snapshot isolated».
- Ответ
- MongoDB нашла ошибку в механизме повторов транзакций и выпустила исправление в 4.2.8, а также уточнила документацию: гарантии причинной согласованности держатся только при чтении и записи с
majority. - Что изменилось дальше
- Начиная с версии 5.0 подтверждение записи по умолчанию —
{ w: "majority" }вместо прежнего{ w: 1 }. Умолчание стало строгим — прямое следствие таких разборов. - Вывод
- Гарантии задаются версией сервера и настройками чтения и записи. Сверяйте их с документацией своей версии и с независимыми отчётами.
Самый частый антипаттерн документной модели описан в официальной документации отдельной статьёй. Массив, число элементов которого ничем не ограничено, — сессии пользователя, комментарии к посту, события устройства — со временем упирается в предел 16 МБ на документ. Задолго до предела он портит производительность: документ перестаёт помещаться там, где помещался, каждая запись переписывает его целиком, а индекс по массиву растёт вместе с ним.
- Как проявляется
- Сначала медленные запросы к «тяжёлым» документам, потом отказы записи при достижении предела размера.
- Как чинят
- Выносят список в отдельную коллекцию со ссылкой; хранят в документе только последние N элементов (подмножество); складывают события в «корзины» по времени.
- Где увидеть у себя
- В Atlas есть подсказки по схеме: сервис сам отмечает коллекции с неограниченными массивами. В своей установке то же видно по росту среднего размера документа.
§3Где база дала выигрыш
Здесь собраны случаи, где переход на документную модель или на управляемый сервис дал измеримый результат. Все три опубликованы самой MongoDB Inc., поэтому читать их нужно с поправкой из §0.
Фармацевтическая компания Novo Nordisk собрала платформу NovoScribe: отчёты о клинических исследованиях готовит языковая модель, а поиск нужных фрагментов идёт через векторный поиск в MongoDB Atlas в связке с Amazon Bedrock и LangChain. Подготовка одного отчёта сократилась с 12 недель до 10 минут; по данным компании, платформа готовит около 30% всех таких отчётов.
- При чём тут база
- Это типовая схема RAG: документы и их векторные представления лежат в одной базе, поэтому поиск по смыслу и обычный фильтр по полям выполняются одним запросом, без отдельного векторного хранилища.
- Как читать число
- «12 недель → 10 минут» относится к подготовке черновика. Проверка и утверждение отчёта остались на месте, так что ускорен один этап работы.
Сервис поиска работы Indeed переехал с собственной установки MongoDB на AWS и MongoDB Atlas — миграцию закончили в ноябре 2023 года. Команда разобрала 600 кластеров и 500 ТБ данных, нашла, что 85% затрат приходится на часть из них, и за полгода сократила расходы на 27% при изначальной цели в 19%.
- За счёт чего
- Оптимизация хранения (в одном из примеров — более 30% экономии), отключение простаивающих ресурсов и уменьшение числа реплик (ещё около 3%), отказ от стороннего хранилища резервных копий.
- Что отсюда полезно
- Экономию принесла инвентаризация: сначала посчитали, где уходят деньги, и только потом правили. Сам по себе переезд такого эффекта не даёт. В работе с запросами порядок тот же — сперва измерить.
Индийский сервис быстрой доставки Zepto после перехода на MongoDB сообщает о снижении задержки критичных программных интерфейсов на 40% и о запасе прочности: инфраструктура выдерживает шестикратный рост трафика без деградации.
- Контекст
- Доставка за минуты — нагрузка с резкими всплесками: акции, час пик, праздники. Смотреть в таких системах нужно на поведение под пиком, средняя скорость об этом ничего не говорит.
- Как читать число
- «−40%» относится к части программных интерфейсов; сравнение идёт с прежней архитектурой самой компании. Это не замер двух баз в равных условиях.
§4Что из этого следует для вашего кода
| Случай | Решение, которое к нему привело | Что делать в своей работе |
|---|---|---|
| 27 663 стёртых базы, 2017 | Сервер слушает внешний адрес, проверка подлинности выключена | Перед выходом в сеть — net.bindIp и учётные записи; проверить, что порт 27017 не виден снаружи |
| 809 млн записей, 2019 | Открытая база и хранение в открытом виде | Пароль и шифрование канала настраивают на первом же развёртывании |
| 11 часов простоя, 2010 | Рост шардов не отслеживался, рабочий набор перерос память | Следить за размером данных относительно памяти и за равномерностью распределения |
| Отчёт Jepsen, 2020 | Опора на умолчания вместо явных уровней согласованности | Для денег и остатков указывать majority явно, каким бы ни было умолчание версии |
| Растущий массив | Список без ограничения внутри документа | Ограничивать массив подмножеством или выносить в отдельную коллекцию с самого начала |
| Экономия 27%, Indeed | Разбор расходов по кластерам до всяких изменений | Тот же порядок в запросах: сначала explain и счётчики, потом правки |