🇺🇸 Зачем хранить агрегаты с помощью NoSQL?
В последние годы мы столкнулись с огромным ажиотажем по поводу использования нереляционных баз данных, и теперь решение, какую выбрать модель устойчивости, может быть чем-то сложным.
Выбор наилучшего способа сохранить состояние объектов домена будет зависеть от вашего проекта, но мы не можем не знать о вариантах и сбалансировать плюсы и минусы.
Я хотел бы оставить здесь размышление об использовании баз данных NoSQL и устойчивости агрегатов. Может быть, это поможет вам принять решение.
По словам Мартина Фаулера, для того, чтобы те же концепции обсуждались в этом посте, агрегат - это совокупность объектов предметной области, которые можно рассматривать как единое целое.
Я хочу начать это размышление с разговора о модели реляционной базы данных, указав, что вам придется разделить свою бизнес-модель на таблицы, столбцы и отношения. С этим типом модели данных вам всегда придется прилагать усилия к инфраструктуре для преобразования строк результирующего набора в объекты вашего домена, даже если вы используете ORM. Также очень распространено использование шаблонов проектирования для преобразования ваших данных во что-то актуальное для вашего домена, например, шаблон factory.
См. Ниже изображение, сделанное Мартином Фаулером, которое очень ясно показывает эту сложность.
В этом сценарии мы можем поднять три шага для моделирования системы с реляционной базой данных: создать таблицы и отношения между ними, создать стратегию для получения данных, создать стратегию для преобразования этих данных в объекты вашего домена.
С другой стороны, базы данных NoSQL предлагают бессхематичный способ хранения / восстановления этих данных за счет простоты ключа / значения.
Есть несколько продуктов, реализующих эту идею с небольшими вариациями, но все они разделяют одну и ту же концепцию: хранение документов (обычно JSON), идентифицируемых ключом.
Эта модель отлично подходит для приложений, потому что хранение / восстановление данных выполняется естественным образом на большинстве языков программирования, путем сериализации агрегированного состояния в JSON и преобразования JSON в объекты.
Кроме того, базы данных NoSQL предлагают отличную возможность масштабирования для вашего бизнеса. Они смоделированы таким образом, чтобы данные можно было обрабатывать в кластерах. IBM подготовила подробную статью, показывающую этот случай, включая большинство игроков на NoSQL, которая также может помочь в принятии решения о вашей модели.
Побочные эффекты этой модели связаны с тем, что вы прочитаете эти данные, потому что, если мы заглянем в коллекцию «SalesOrders» и нам нужно будет знать заказы, сделанные в определенный день, или все заказы с общей стоимостью больше, чем 100 долларов США, у нас не будет определенного ключа для этих запросов, и в результате мы получим «полное сканирование таблицы» в каждом запросе.
В приведенном выше примере вопросы аналитики показаны поверх данных, в этом случае на эти вопросы можно ответить через аналитическую базу данных с использованием хранилищ данных. На стороне транзакции у нас будут только транзакционные действия, такие как восстановление заказа на продажу, изменение статуса, отмена и т. Д.
Наконец, использование NoSQL для хранения состояния агрегатов выглядит разумным из-за низкой стоимости обслуживания, масштабируемости и простоты внедрения решения. Единственное ограничение - это способ запроса данных.
Если есть что-то еще, что не было затронуто в этом размышлении, и вы думаете, что это уместно поделиться, пожалуйста, оставьте комментарий.
Эта статья также доступна на португальском.
