Не удается найти ключ раздела, размер которого не превышает 10 ГБ.

У меня есть объект, который я вставляю в documentDB. Этот объект имеет два строковых свойства по 4000 символов каждое.

Если я выберу собственный идентификатор объекта в качестве ключа раздела, я никогда не достигну предела в 10 ГБ, но каждый раздел будет иметь размер всего несколько килобайт и будет содержать только один объект.

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


azure azure-cosmosdb
person SimpleDesign    schedule 31.08.2017    source источник
comment
ИМХО, было бы полезно, если бы вы могли отредактировать свой вопрос и включить туда образцы документов, содержащих ваш объект.   -  person Gaurav Mantri    schedule 31.08.2017
comment
Гаурав, это просто объект с двумя длинными свойствами, оба содержат строку из 4000 символов. Если я вставлю сюда образец, он займет много места на экране...   -  person SimpleDesign    schedule 31.08.2017
comment
Я немного запутался в вашей модели данных: это просто идентификатор и две (очень большие) строки? Означает ли это, что вы никогда не выполняете запросы к строковым полям? Если это так, я не совсем понимаю, почему вы пытаетесь сохранить в документе. В любом случае: на этот вопрос здесь действительно никто не может ответить; ключ раздела будет специфичным для ваших данных, и у вас сейчас нет никаких метаданных, кроме идентификатора.   -  person David Makogon    schedule 31.08.2017
comment
Спасибо за помощь Дэвиду, помимо двух больших свойств есть свойство имени клиента, идентификатор и порядок текста в большой истории. текст — это часть большего целого или рассказа, если хотите. так что есть также свойство, которое говорит, каков порядок фрагментов, поэтому я могу собрать все фрагменты вместе, чтобы сформировать начальную историю.   -  person SimpleDesign    schedule 31.08.2017
comment
С риском упрощения ваш первый вариант (id в качестве ключа раздела), как правило, является лучшим выбором. Имейте в виду, что Azure Cosmos DB не будет создавать физические разделы для каждого ключа, а будет хранить ключи в одном разделе до тех пор, пока он не будет заполнен. Что вас беспокоит в таком подходе?   -  person Aravind Krishna R.    schedule 28.09.2017
comment
Большое спасибо, Aravind, я проверил, и ваше предложение решает мою проблему, я не знал, что Azure Cosmos DB не будет создавать физические разделы для каждого ключа, а вместо этого будет хранить ключи в одном разделе, пока он не достигнет емкости. эта информация решает мою проблему! Благодарю вас!. если вы можете поделиться документацией, я могу узнать больше из того же источника документации.   -  person SimpleDesign    schedule 29.09.2017

Ответы (1)


arrow_upward
2
arrow_downward

Благодаря комментарию Аравинда я нашел решение, которое я могу использовать, и это идентификатор объекта. Вот что сказал Аравинд: «Имейте в виду, что Azure Cosmos DB не будет создавать физические разделы для каждого ключа, а будет хранить ключи в одном разделе до тех пор, пока он не будет заполнен». Большое спасибо Aravind за решение моей проблемы! (-: Хорошего дня!

person SimpleDesign    schedule 29.09.2017