MongoDB спонсировал этот пост.
Слишком часто разработчиков несправедливо обвиняют в небрежном отношении к целостности данных. Логика такова: без жесткой структуры базы данных SQL разработчики будут писать код импульсивно, пропуская формальное проектирование и рассматривая его как препятствие, а не как жизненно важный шаг в построении надежных систем.
Из-за этого заблуждения многие администраторы баз данных (DBA) полагают, что единственный способ гарантировать качество данных — это использовать реляционные базы данных. Они думают, что использование базы данных документов, такой как MongoDB, означает, что они не могут быть уверены, что моделирование данных будет выполнено правильно.
Поэтому администраторы баз данных вынуждены заранее определять и развертывать схемы в выбранной ими базе данных, прежде чем какое-либо приложение сможет сохранять или совместно использовать данные. Это также означает, что любое развитие приложения требует от администраторов баз данных проверки и запуска сценария миграции, прежде чем новая версия достигнет пользователей.
Однако разработчики заботятся о целостности данных не меньше, чем администраторы баз данных. Они вкладывают значительные усилия в модель предметной области приложения и избегают ее ослабления, сопоставляя ее с нормализованной структурой данных, которая не отражает варианты использования приложения.
Разные модели баз данных, разные модели данных
Реляционные и документальные базы данных используют разные подходы к моделированию данных.
В базе данных документов вы по-прежнему проектируете свою модель данных. Что меняется, так это то, где и как происходит проектирование, в тесном соответствии с моделью предметной области и шаблонами доступа приложения. Это особенно актуально для команд, практикующих проектирование на основе предметной области (DDD), где разработчики тратят время на понимание объектов предметной области, взаимосвязей и шаблонов использования.
Модель данных развивается вместе с процессом разработки — мозговой штурм идей, создание прототипов, выпуск минимально жизнеспособного продукта (MVP) для получения ранних отзывов и переход к стабильному, готовому к производству приложению.
Реляционное моделирование часто начинается с нормализованного проекта, созданного до полного понимания приложения. Эта модель должна затем обслуживать разнообразные будущие рабочие нагрузки и непредсказуемое распределение данных. Например, схема базы данных, разработанная для академического программного обеспечения, может использоваться как начальными школами, так и крупными университетами. Это иллюстрирует силу реляционных баз данных: логическая модель, предоставляемая приложениям, одинакова, даже если рабочие нагрузки сильно различаются.
Моделирование документов, напротив, адаптировано к использованию конкретного приложения. Вместо перевода модели предметной области в нормализованные таблицы, что добавляет абстракцию и скрывает оптимизацию производительности, MongoDB хранит агрегаты непосредственно в том виде, в котором они отображаются в вашем коде и бизнес-логике. Документы отражают бизнес-транзакции и хранятся в виде смежных блоков на диске, обеспечивая согласованность физической модели со схемой предметной области и оптимизацию шаблонов доступа.
Вот еще несколько способов сравнения этих двух моделей.
Моделирование документов обрабатывает отношения
Часто думают, что реляционные базы данных превосходны в «сильных связях» между данными, но отчасти это происходит из-за неправильного понимания названия — отношения относятся к математическим наборам кортежей (строк), а не к связям между ними, которые являются отношениями. Нормализация фактически ослабляет сильные связи, отделяя сущности, которые позже сопоставляются во время запроса посредством объединений.
В диаграммах сущностей-связей (ERD) отношения показаны как простые ссылки «один-к-одному» или «один-ко-многим», реализованные через первичные и внешние ключи. ERD не фиксируют такие характеристики, как направление навигации или владение между объектами. Отношения «многие-ко-многим» моделируются с помощью таблиц соединений, которые разделяют их на два отношения «один-ко-многим». Единственное свойство отношений в ERD — это различие между «один-к-одному» (прямая линия) и «один-ко-многим» («гусиная лапка»), а модель данных одинакова независимо от того, является ли «многие» несколькими или миллиардами.
Диаграммы классов унифицированного языка моделирования (UML) в объектно-ориентированном проектировании, по сравнению с этим, богаче: они имеют направление навигации и различают ассоциацию, агрегацию, композицию и наследование. В MongoDB эти концепции естественным образом отображаются:
- Состав (например, заказ и его строки заказа) часто отображаются как встроенные документы, имеющие общий жизненный цикл и предотвращающие частичное удаление.
- Агрегация (клиент и его заказы) использует ссылки, когда жизненные циклы различаются или когда родительская собственность является общей.
- Наследование могут быть представлены с помощью полиморфизма, концепция ERD не фиксирует напрямую и не обходится с помощью столбцов с нулевым значением.
Модели предметной области в объектно-ориентированных приложениях и документах MongoDB лучше отражают отношения реального мира. В реляционных базах данных схемы являются жесткими для сущностей, а отношения разрешаются во время выполнения с помощью соединений — больше похоже на то, как специалист по данным обнаруживает корреляции во время анализа. Внешние ключи SQL предотвращают появление потерянных строк, но на них явно не ссылаются при написании SQL-запросов. Каждый запрос может определять разные отношения.
Проверка схемы защищает целостность данных
MongoDB является гибкой схемой, а не бессхемной. Эта функция особенно ценна для проектов на ранних стадиях, таких как мозговой штурм, создание прототипа или создание MVP, поскольку вам не нужно выполнять операторы языка определения данных (DDL) перед записью данных. Схема находится в коде приложения, а документы хранятся как есть, без дополнительной предварительной проверки, поскольку согласованность обеспечивается одним и тем же приложением, которое их записывает и читает.
По мере развития модели вы можете определять правила проверки схемы непосредственно в базе данных — требования к полям, типы данных и допустимые диапазоны. Вам не нужно объявлять каждое поле сразу. Вы добавляете проверку по мере того, как схема становится более зрелой, стабильной и общедоступной. Это обеспечивает согласованную структуру, когда несколько компонентов зависят от одних и тех же полей или при индексировании, поскольку в индексе полезны только поля, используемые приложением.
Гибкость схемы повышает скорость разработки на каждом этапе вашего приложения. На ранних этапах создания прототипа вы можете свободно добавлять поля, не беспокоясь о немедленной проверке. Позже, когда будет реализована проверка схемы, вы сможете положиться на базу данных для обеспечения целостности данных, что уменьшит необходимость писать и поддерживать код, проверяющий входящие данные.
Проверка схемы также может обеспечить соблюдение физических границ. Если вы встраиваете элементы заказа в документ заказа, вы можете убедиться, что массив не превышает определенного порога. Вместо полного сбоя — как в случае с ограничениями проверки SQL (которые часто вызывают необработанные ошибки приложения) — MongoDB может регистрировать предупреждение, предупреждая команду, не нарушая работу пользователя. Это позволяет приложению оставаться доступным, одновременно отмечая потенциальные аномалии или необходимые изменения.
Логика приложения и внешние ключи
В базах данных SQL внешние ключи представляют собой ограничения, а не фактические определения отношений, которые оцениваются во время запроса. SQL-соединения определяют отношения, перечисляя столбцы в качестве предикатов фильтра, а внешние ключи не используются в предложении JOIN. Внешние ключи помогают предотвратить определенные аномалии, такие как появление дочерних элементов-сирот или каскадное удаление, возникающие в результате нормализации.
MongoDB использует другой подход: внедряя тесно связанные сущности, вы заранее решаете основные проблемы целостности. Например, встраивание строк заказа в документ заказа означает, что потерянные позиции по своей природе невозможны. Ссылочные отношения обрабатываются логикой приложения, часто считывая из стабильных коллекций (списков значений) перед внедрением их значений в документ.
Поскольку модели MongoDB созданы с учетом известных шаблонов доступа и жизненных циклов, ссылочная целостность поддерживается с помощью бизнес-правил, а не применяется в целом. На практике это лучше отражает реальные процессы, где обновления или удаления должны соответствовать определенным условиям (например, снижение цен может применяться к текущим заказам, а повышение цен — нет).
В реляционных базах данных схема не зависит от приложения, поэтому необходимо защищать от любых возможных модификаций языка манипулирования данными (DML), а не только от тех, которые являются результатом действительных бизнес-транзакций. Для этого в приложении потребуются дополнительные блокировки или более высокие уровни изоляции, поэтому зачастую более эффективно объявить внешние ключи, которые база данных будет применять.
Однако, когда сценарии использования домена хорошо понятны, защита требуется только для нескольких случаев и может быть интегрирована в саму бизнес-логику. Например, продукт никогда не будет удален, пока его используют текущие транзакции. Бизнес-процесс часто помечает продукт как недоступный задолго до того, как он будет физически удален, а транзакции достаточно кратковременны, чтобы не было дублирования, что предотвращает возникновение сирот без дополнительных проверок.
В моделях, управляемых предметной областью, где схема разработана с учетом конкретных сценариев использования приложения, целостность может полностью управляться командой приложения наряду с бизнес-правилами. Хотя дополнительная проверка базы данных может служить защитой, она может ограничить масштабируемость, особенно при сегментировании, и ограничить гибкость. Альтернативой является запуск конвейера периодического агрегирования, который асинхронно обнаруживает аномалии.
В следующий раз, когда вы услышите этот миф
MongoDB не означает «отсутствие дизайна». Это означает интеграцию проектирования базы данных с проектированием приложений — внедрение, ссылки, проверку схемы и проверки целостности на уровне приложения для отражения фактической семантики предметной области.
Такой подход делает моделирование данных первостепенной задачей для разработчиков, поскольку оно напрямую согласуется со способом представления объектов предметной области в коде. Структура базы данных развивается вместе с приложением, а целостность обеспечивается на том же языке и в тех же конвейерах, которые доставляют само приложение.
В средах, где администраторы баз данных видят только модель базы данных и операции SQL, внешние ключи могут оказаться незаменимыми. Но в рабочем процессе DevOps, где одна и та же команда обрабатывает и базу данных, и приложение, правила схемы могут быть сначала реализованы в коде, а затем уточнены в базе данных по мере стабилизации спецификаций. Это позволяет избежать поддержки двух отдельных моделей и связанных с ними накладных расходов на миграцию, обеспечивая более быстрые итеративные выпуски с сохранением целостности.
MongoDB со штаб-квартирой в Нью-Йорке — это компания, предоставляющая платформу данных для разработчиков, которая дает новаторам возможность создавать, трансформировать и разрушать отрасли, раскрывая возможности программного обеспечения и данных. Узнайте больше Последние новости MongoDB ТЕНДЕНЦИОННЫЕ ИСТОРИИ YOUTUBE.COM/THENEWSTACK Технологии развиваются быстро, не пропустите ни одной серии. Подпишитесь на наш канал YouTube, чтобы смотреть все наши подкасты, интервью, демонстрации и многое другое. ПОДПИСАТЬСЯ Группа, созданная в Sketch. Франк Пахо — защитник разработчиков в MongoDB, опытный консультант по базам данных и евангелист облачных технологий с обширным опытом работы в Oracle, PostgreSQL и облачных технологиях. Франк, известный своим глубоким техническим опытом, является востребованным оратором и наставником в… Читать далее от Франка Пашо
