Базы данных по сравнению
MongoDB: документы, а не доктрина
MongoDB популяризировала хранилище документов с горизонтальным масштабированием, и с тех пор история включает в себя дисциплину проектирования схемы, модель набора реплик, более простую, чем большинство настроек SQL HA, и лицензирование (SSPL), которое заметно продвинуло вперед самостоятельное размещение. Он выигрывает для конкретных форм данных, и наши сравнения nosql-vs-sql и postgresql-vs-mongodb охватывают аргументы; это отдельная статья о том, когда сам двигатель заслуживает пьедестала.
Главное
- Документы BSON намеренно обеспечивают гибкость схемы, что означает, что дисциплина проектирования схемы смещается от файлов миграции к настройкам приложения по умолчанию: встроенные документы для шаблонов чтения многих по сравнению со ссылками для реляционной связи «один ко многим» остаются решением, которое влияет или снижает производительность.
- Конвейер агрегирования — это место, где живет аналитическая работа: специально созданные этапы (сопоставление, группировка, поиск, развертывание) заменили специальное сокращение карты; для большинства операционной аналитики агрегирование плюс индекс важнее доставки данных на склад.
- Наборы реплик дешево справляются с общей высокой доступностью: один основной плюс дополнительный с автоматическим переключением при сбое и настройками чтения; Шардинг — это реальная функция распределенных данных для рабочих нагрузок с масштабированием записи, но она несет в себе операционный вес (балансировка блоков, ключи сегментирования), который подлежит проверке проекта, а не модернизации.
- Индексация TTL и коллекции временных рядов изначально охватывают вариант использования «журналов и метрик»: ограниченное хранение без удаления документов с помощью cron и специально созданное хранилище временных рядов для высокочастотного приема метрик.
- Эксплуатационные различия: эквивалентности вакуума, близкого к обслуживанию, не существует, но частота обновления и консолидация отложенной опциональности (проверка схемы с помощью валидаторов, транзакции начиная с 4.x) имеют значение; драйверы, индексы, нехватка памяти отображаются в виде планов запросов (объясните), а не журналов медленных запросов.
- Честное лицензирование: версия сообщества имеет лицензию SSPL, которую исключают некоторые платформы управляемых поставщиков; Atlas — это путь, поддерживаемый поставщиком, а самостоятельное размещение остается распространенным явлением в контейнерных развертываниях, где допустим SSPL.
Заметка из практики
Схема отключения MongoDB, которая больше всего научила наших клиентов, всегда была одной и той же: ключ сегмента, выбранный во время прототипа, превращается в производственную версию, а повторный сегмент становится проектом. Шард-ключи — это архитектурные решения, а не монгольская археология.
Частые вопросы
Является ли MongoDB хорошей заменой реляционной базы данных?
Иногда для правильно вложенных рабочих данных; для реляционных проектов с большим количеством соединений — нет: здесь задача вашего приложения — ссылочная целостность. В нашей статье nosql-vs-sql рассматривается правило честного принятия решения.
Как обрабатывать миграцию между документами, изменяющими схему?
Добавляя самостоятельно дисциплину управления версиями схемы: валидаторы и поля версий, а также сценарии целевой миграции; нет ALTER TABLE, на который можно было бы опереться.
А как насчет лицензии (SSPL) для провайдеров SaaS?
Вы можете разместить его самостоятельно И использовать его в облаке в качестве хранилища приложений, но как услуга, предлагающая это, — это совсем другая история; проверьте коммерческие условия, прежде чем предлагать клиентам альтернативный хостинг Atlas.
Почему осколочный ключ так важен?
Потому что маршрутизация, балансировка и сходство запросов возникают после выбора шардирования: последующий перешардинг работающей системы — это реальное оперативное действие.
Как мы берём на себя базы данных по сравнению
Честно: чаще всего к нам приходят после того, как команда попробовала справиться сама. Выбор ядра базы данных для размещения рабочих нагрузок по сравнению с гарантиями корректности, эксплуатационной значимостью и реальной стоимостью: встроенные механизмы против серверов, MySQL против PostgreSQL, SQL против хранилищ документов, а также устаревший практический пример, который постоянно возвращается. Услуга Администрирование серверов и Оптимизация скорости сайтов существует как раз затем, чтобы не изучать базы данных по сравнению на своих ошибках: настройку, ночные сюрпризы и постоянное наблюдение мы берём на себя.