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

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

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

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

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

Спасибо

Ответы

Ответ 1

Блокировка и фиксация.. Что должно произойти, если возможны частичные обновления. Это сложная инженерная проблема, заключающаяся в том, чтобы поддерживать SLA с задержкой в ​​15 мс с блокировкой.

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

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

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

Ответ 2

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

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

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

Ответ 3

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

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

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

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

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

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

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