Сравните выбор реляционной схемы и документного хранилища для каталога с постоянно меняющимися атрибутами: какой главный компромисс возникает?
Главный компромисс проходит между строгой целостностью данных и гибкостью схемы. Реляционная модель лучше защищает типы, связи и ограничения, но изменение структуры и поддержка разнородных атрибутов требуют больше проектных усилий. Документное хранилище упрощает добавление новых полей и хранение разных форматов документов, однако переносит часть контроля целостности в приложение и усложняет согласованные связи между сущностями.
Реляционные базы данных создавались для структурированных данных, где важны формальные связи, транзакции и проверяемые ограничения. Фиксированная схема позволяла обнаруживать ошибки при записи, поддерживать ссылки между таблицами и выполнять сложные согласованные изменения.
Документные хранилища получили распространение в задачах, где структура записей меняется быстрее, чем схема базы, а данные естественно представляются самостоятельными агрегатами. Такой подход снижает стоимость эволюции формата, но не устраняет требования к проектированию: запросы, индексы, версии документов и правила совместимости всё равно нужно определить.
В каталоге товары разных типов могут иметь различные атрибуты: размер, материал, напряжение или срок годности. При этом система должна поддерживать фильтрацию, сортировку, обновление карточек и иногда согласованную работу с ценами, остатками и категориями.
Если без анализа выбрать документное хранилище только ради гибкой схемы, фильтрация по произвольным полям может стать дорогой, а связи с остатками и ценами — сложными. Если выбрать полностью нормализованную реляционную схему, появятся многочисленные таблицы атрибутов, сложные соединения или частые миграции, что замедлит развитие каталога.
Сначала фиксируют паттерны доступа, границы агрегата и инварианты, а не выбирают базу по формату данных. Нужно определить, какие поля обязательны, какие участвуют в фильтрах, какие обновляются независимо и какие данные должны изменяться атомарно.
Реляционная схема подходит, когда важны строгие ограничения, сложные связи, уникальность, транзакции между сущностями и предсказуемые запросы. Ее можно дополнить JSON-полем для редко используемых или быстро меняющихся атрибутов, но часто фильтруемые значения потребуют продуманных индексов и контроля типов.
Документная модель подходит, когда товар обычно читается как целый агрегат, атрибуты сильно различаются между типами, а междокументные связи ограничены. Она уменьшает число соединений и упрощает добавление полей, но дублирование данных требует стратегии обновления, а отсутствие междокументных ограничений увеличивает риск рассогласования.
Ключевой компромисс — не просто гибкость против жесткости схемы, а место, где поддерживается целостность. В реляционной модели значительная часть правил выражается средствами базы, тогда как в документной модели их чаще реализуют в сервисе, проверяют при чтении и поддерживают миграциями версий документов.
Практичный вариант — разделить данные по их природе. Каталоговые атрибуты можно хранить в документной форме внутри товара, а цены, остатки и финансовые ограничения — в реляционной модели или отдельном сервисе с четкими инвариантами. Такой гибрид повышает сложность эксплуатации и синхронизации, поэтому его выбирают только при явной пользе от разделения.
Представим маркетплейс, где продавцы добавляют новые категории каждую неделю. Вариант с отдельными таблицами для каждого типа товара дает строгие типы и удобные ограничения, но требует миграций и усложняет общий поиск по атрибутам. Вариант с универсальной таблицей атрибутов уменьшает число миграций, но может привести к сложным соединениям, неоднородным типам значений и трудной оптимизации фильтров.
Документное хранение карточки упрощает публикацию новых категорий и чтение полной страницы товара. Однако цены и остатки нельзя бездумно дублировать в карточке: независимое обновление может показать покупателю устаревшую стоимость или наличие.
Выбранное решение — хранить изменяемые описательные атрибуты в документе каталога, а цену и остаток — в отдельном источнике с явными правилами актуальности. Для часто используемых фильтров вводятся индексы и ограниченный набор нормализованных поисковых полей; произвольные атрибуты остаются менее оптимизированными. Это сохраняет скорость развития каталога, не смешивая гибкие описательные данные с критичными инвариантами.
Нет. Схема просто становится менее формальной и частично переносится в приложение. Нужно определить допустимые типы, обязательность полей, версии документов, правила обратной совместимости и обработку старых записей. Иначе разные версии сервиса начнут по-разному интерпретировать одни и те же данные.
Нет. Гибкость записи не гарантирует приемлемую стоимость поиска. Для фильтрации требуются подходящие индексы, ограничение числа поддерживаемых предикатов или отдельный поисковый индекс; индексация каждого возможного поля увеличивает размер индексов и стоимость записи. Поэтому список реальных запросов должен быть известен до выбора модели хранения.
Нет. Дублирование ускоряет чтение агрегата и уменьшает количество соединений, но создает несколько копий факта. При изменении источника нужно выбрать стратегию: синхронно обновлять копии, публиковать события с повторной обработкой или принимать временную рассогласованность. Если данные критичны, необходимо явно определить источник истины и допустимую задержку обновления.