Разработка с MongoDB: когда документная база данных подходит продукту

MongoDB — документная база данных, которая хранит записи в документах BSON и делает документ естественной единицей получения, обновления и атомарности. Она является сильным выбором, когда продукт работает с самодостаточными бизнес-агрегатами, вложенную структуру которых читают и изменяют вместе: товаром каталога со свойствами определённой категории, опубликованным объектом содержимого, снимком настроек, профилем клиента или состоянием устройства. Архитектурное преимущество возникает благодаря согласованию способа хранения с поведением приложения, а не благодаря отказу от проектирования.

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

MongoDB поддерживает транзакции, соединение данных через конвейеры агрегирования, проверку, интеграции с поиском, репликацию и горизонтальное распределение. Эти возможности не отменяют компромиссов. Работа между документами дороже хорошо спроектированной операции над одним документом; распределённые транзакции требуют координации; агрегирование не исправляет нечёткой ответственности; копии не заменяют резервного копирования; горизонтальное распределение не делает каждый запрос масштабируемым. Обоснованное решение определяет, какие преимущества действительно будет использовать нагрузка и какую сложность команда принимает взамен.

Гибким документам всё равно нужны продуманные границы

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

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

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

Нагрузки, которым MongoDB может дать преимущество

• Агрегаты содержимого и настроек: страницы, учебные материалы, кампании, правила или настройки устройств, варианты которых имеют ограниченную вложенную структуру и извлекаются целиком.
• Неоднородные каталоги и профили: записи имеют устойчивые идентичность и жизненный цикл, тогда как свойства отдельных категорий различаются, а общие фильтры можно осознанно индексировать.
• Крупные потоки операционных событий: независимо записываемые и ограниченные во времени сведения уместны, если сроки хранения, индексы, секционирование или горизонтальное распределение, агрегирование и последующая аналитика спроектированы по измеренному спросу.
• Службы с высокой пропускной способностью, пригодные к распределению: устойчивый ключ маршрутизации, локальные операции над агрегатами, ограниченные документы, предсказуемые индексы и явные правила согласованности позволяют масштабироваться без постоянных обращений ко всем сегментам с последующим объединением результата.

Масштабируйтесь по доказательствам из запросов, а не по репутации базы данных

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

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

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

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

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

Когда реляционная база данных служит более безопасной основой

Реляционная база данных обычно служит более понятной основой, когда предметную область определяют множество независимых сущностей и связей, целостность охватывает несколько сущностей, произвольные соединения и отчётность имеют центральное значение, а команде полезны нормализованные факты с декларативными внешними ключами и ограничениями. Бухгалтерский учёт, реестры, распределение запасов, состояния заказов и платежей, кадровые записи, права доступа и регулируемая отчётность часто выигрывают от реляционной семантики. PostgreSQL также может хранить JSON рядом с типизированными реляционными столбцами, поэтому одних лишь меняющихся атрибутов недостаточно для выбора документной базы.

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

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

Проектируйте документы вокруг чтения, записи и инвариантов

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

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

Защищайте весь путь доступа. Предоставляйте приложениям отдельные идентичности и только необходимые действия с базой данных; отделяйте привилегии владения, переноса, поддержки, аналитики и выполнения. Ограничивайте сетевые пути, должным образом шифруйте передачу и сохранённые данные, меняйте секреты, проводите аудит существенного доступа, контролируйте выгрузки и не записывайте чувствительные значения в журналы. Изоляция клиентских организаций должна проходить через фильтры, составные индексы, обновления, конвейеры агрегирования, фоновые задания, кеши, файлы и административные средства. Отсутствующее условие клиентской организации — это уязвимость безопасности, а не ошибка запроса.

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

MongoDB оправдывает своё место, когда один ограниченный документ воплощает бизнес-агрегат, который приложение читает, изменяет, защищает и масштабирует как единое целое. Гибкость полезна лишь внутри модели с назначенным ответственным.— GARNO.TECH Engineering Team

Подтверждайте выбор испытанием, приближенным к реальной эксплуатации

Выбирайте MongoDB, когда ограниченные документные агрегаты соответствуют естественным операциям продукта, а требования к запросам, согласованности, росту, доступности, восстановлению, безопасности и команде выдерживают показательное испытание. Отдавайте предпочтение реляционной основе, когда преобладают связи и целостность между сущностями, или специализированному хранилищу, когда его требует одна измеренная нагрузка. Решение может меняться вместе с доказательствами; документируйте предположения и сигнал для повторного рассмотрения.

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

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