it-swarm.com.ru

Шаблон обновления Azure Cosmos DB

Недавно я начал использовать Cosmos DB для проекта, и у меня возникли некоторые проблемы с дизайном. Исходя из фона SQL, я понимаю, что связанные данные должны быть вложены в документы в базе данных NoSQL. Это означает, что документы могут стать довольно большими, хотя. 

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

Должен ли я читать всю сторону сервера документов, обновлять значение и записывать документ обратно для немедленного обновления? Это кажется проблематичным, если документы большие, что неизбежно будет, если все ваши данные будут вложенными.

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

Спасибо

13
Ross

Блокировка и фиксация. Вот что должно произойти, если возможны частичные обновления. Сложно с инженерной проблемой сохранить задержку записи <15 мс SLA с блокировкой.

Это кажется проблематичным, если документы большие, что неизбежно будет, если все ваши данные будут вложенными.

Определите свой страх - сожженные блоки запросов, память хоста приложения, входящий/исходящий сетевой трафик? Вы верите, что это проблема, но не указываете конкретные результаты. Я не говорю, что вы не правы или сомневаетесь в эффективности подхода частичного обновления, я просто говорю, что аргумент невелик.

Обычно вы хотите, чтобы JOIN ничего в NoSQL, поэтому я полностью с вами в последнем абзаце.

4
evilSnobu

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

  • Нужна ли отдельная часть доступа к части документа? Если да, то создайте ссылочный документ, а если нет, то создайте внедренный документ.

    И если вы хотите знать, что выбрать, я думаю, вам следует взглянуть на этот вопрос для MongoDb, но он вам поможет Embedded vs Referenced Document

2
vikscool

Внедрение или ссылка - самая распространенная проблема, с которой я сталкиваюсь при разработке структуры документа в мире NoSQL.

Во встроенных отношениях дочерние объекты были встроены в родительский документ. В ссылочных отношениях дочерние объекты в отдельных документах и ​​их родительские объекты в другом документе, в основном имеющие два (или более) типа документов.

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

1. Вам нужно получить все дочерние объекты вместе с родительскими объектами? Если да, используйте встроенные отношения.

2. Ваш вариант использования позволяет получать объекты по отдельности? В этом случае использовать шаблон отношений.

В большинстве случаев, когда я работал, я использовал паттерн отношений. Например: социальный график (профили с деревом отношений), точки приближения (поиск близости на основе GeoJSON), классифицированный листинг и т.д.

Шаблон отношений также легче обновлять и поддерживать, поскольку объекты хранятся в отдельных документах.

0
spideringweb