DocumentDB: Как улучшить структуру данных для обновления

Так, например, у меня есть коллекция документов, как это:DocumentDB: Как улучшить структуру данных для обновления

{ 
    hotField1 : 0, 
    hotField2 : "", 
    coldField1 : 0, 
... 
    coldFieldN : "" 
}

В этой области низкотемпературные свойства записываются один раз, и доступ иногда горячие свойства записываются, а затем довольно часто доступный \ обновленный (но в разных случаях использования, это не тот же суб-документ или части одного и того же объекта). Объем документов довольно большой (1M и более), размер горячих данных по меньшей мере в десять раз меньше, чем холодный.

Поскольку частичное обновление до сих пор самый разыскиваемый еще не реализована функция, единственным способом обновления hotField1 является:

Запрос полный документ
Изменение либо hotField1 или hotField2
Ответь весь документ

Это дорогостоящее с точки зрения RU, и оно не масштабируется так хорошо.

Таким образом, вопрос заключается в том, как организовать такие данные & звонки в DocumentDB для минимизации затрат?

Обнаруженные альтернативы:

~~Очевидно лучше: получить одно свойство; изменение; обновление~~ - не.
Отделитесь от двух коллекций, используйте хранимые процедуры для извлечения из Главной коллекции, а затем из Словаря?
Поместить hotFields1-2 в качестве поддокумента ({ sub: {hf1:0, hf2:""}}) и как-то только обновить его? (Я не уверен, что это возможно)

PS. C# в тегах для используемой клиентской библиотеки. Если ему не хватает smth, то его можно использовать вместо REST-интерфейса.

источник

2017-01-23 Sanctus

# 3 также невозможно сегодня. Моя первая рекомендация состоит в том, чтобы построить его с помощью простого подхода «все в одном документе» и сравнить его. Если это не до табака, то настройте выделенную пропускную способность, если используете секционированную коллекцию или перейдите на более высокий уровень S, если нет. Если это еще не подходит, рассмотрите более сложный дизайн разбиения на основе того, насколько «горячим» является поле. По моему опыту, предположения инженера о том, что будет быстро и что не будет от реальности. Вам нужно экспериментировать. –

@LarryMaccherone, у нас уже есть рабочая система для РСУБД, поэтому у нас уже есть некоторая статистика. Можете ли вы уточнить, что вы подразумеваете под более сложным дизайном? – Sanctus

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

Пока нет точных «лучше «Ответ:

Ваш № 2 не будет работать с хранимыми процедурами, поскольку хранимые процедуры привязаны к коллекции.

Обновление поддокумента (выбор # 3) ничем не отличается от обновления свойств верхнего уровня - вы все еще извлекаете и переписываете документ (поддокумент является еще одним свойством в документе).

В то время как он может или не может уменьшить RU (вам нужно было бы сравнить, как указал Ларри в комментариях), вы можете сохранить свои свойствами в отдельном (меньшем) документе (или нескольких небольших документах). При меньшем количестве свойств во время обновлений будет меньше полосы пропускания и меньше обновления индекса. Однако, поскольку теперь вы получаете более одного документа (возможно, через несколько вызовов), вы можете обнаружить, что это действие отрицает экономию RU при хранении в одном документе.

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

источник

2017-01-23 22:12:53

Я потратил некоторое время на размышление о том, стоит ли хранить отдельные документы. По-видимому - нет. Я точно знаю, что частичные обновления запланированы, но, очевидно, это не просто. Разве не разумно сначала сделать особый тип данных - поддокумент. Таким образом, это будет не обычный объект JSON {}, а небольшой документ в терминах DocDB (то есть с _etag и другими _ полями). Я полагаю, что это возможно для Concurrency Control, потому что для частичного обновления для каждого пользовательского свойства документа потребуется что-то вроде _etag. Затем под-документ действителен для CC. Как вы думаете? – Sanctus

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

NoSQL на основе документов заменяет документ после изменения одного или всех свойств.

С точки зрения стоимости, она основана на сборке.

Итак, если у вас есть БД с двумя коллекциями в нем и каждый с уровнем производительности S1, то есть, 25 долларов США в месяц.

$ 25 х 2 = $ 50

Case вам нужна более высокую производительность, и изменить один к S2 вы будете платить:

$ 50 + $ 25 = $ 75

источник

2017-01-23 20:12:03

Не совсем то, что я хотел, но имеет приятное понимание – Sanctus

DocumentDB: Как улучшить структуру данных для обновления

ответ

Смежные вопросы