Подтвердить что ты не робот

Azure Cosmos DB - Понимание ключа раздела

Я создаю нашу первую базу Azure Cosmos - я буду импортировать в первую коллекцию, данные из таблицы в одной из наших баз данных SQL Server. При настройке коллекции у меня возникли проблемы с пониманием смысла и требований к ключу раздела, которые я специально должен назвать при настройке этой первоначальной коллекции.

Я прочитал документацию здесь: (https://docs.microsoft.com/en-us/azure/cosmos-db/documentdb-partition-data) и до сих пор не уверен, как продолжить соглашение об именах этого ключа раздела.

Может кто-нибудь помочь мне понять, как я должен думать об именовании этого ключа раздела? См. Снимок экрана ниже для поля, которое я пытаюсь заполнить. Имя ключа раздела

В случае, если это помогает, импортируемая таблица состоит из 7 столбцов, включая уникальный первичный ключ, столбец неструктурированного текста, столбец URL и несколько других вторичных идентификаторов для этого URL-адреса. Не уверен, что какая-либо из этих данных имеет какое-либо отношение к тому, как я должен назвать свой раздел.

EDIT: я добавил скриншот из нескольких записей из таблицы, из которой я импортирую, по запросу от @Porschiey.

введите описание изображения здесь

4b9b3361

Ответ 1

Честно, видео здесь * было ОСНОВНОЙ помощью для понимания разбиения на разделы в CosmosDb.

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

Хорошие примеры включают Местоположение (например, Город), Идентификатор Клиента, Команда и многое другое. Естественно, это дико зависит от вашего решения; поэтому, возможно, если вы опубликуете, как выглядит ваш объект, мы могли бы порекомендовать хороший ключ раздела.

EDIT: Следует отметить, что PartitionKey не требуется для коллекций под 10 ГБ. (спасибо Дэвиду Макогуну)


* Видео, которое использовалось для работы на этой странице документации MS, озаглавленной "Разбиение и горизонтальное масштабирование в Azure Cosmos DB", но с тех пор было удалено. Приведена прямая ссылка.

Ответ 2

CosmosDB может использоваться для хранения любого предела данных. Как это делается в конце, используется ключ раздела. Это то же самое, что и основной ключ? - НЕТ

Первичный ключ: однозначно идентифицирует данные Клавиша раздела помогает в осколке данных (например, один раздел для города Нью-Йорк, когда город является ключом раздела).

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

Ответ 3

Разделительный ключ используется для ошпаривания, он действует как логический раздел для ваших данных и предоставляет Cosmos DB естественную границу для распределения данных по разделам.

Подробнее об этом можно прочитать здесь: https://docs.microsoft.com/en-us/azure/cosmos-db/partition-data

Ответ 4

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

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

Ответ 5

Ключ раздела действует как логический раздел.

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

Как это влияет на запрос?

При запросе вы указали бы ключ раздела в качестве параметров канала и не включили его в свой фильтр.

Например: если ваш запрос был

SELECT * FROM T WHERE T.CustomerId= 'CustomerId';

Сейчас будет

var options = new FeedOptions{ PartitionKey = new PartitionKey(CustomerId)};

var query = _client.CreateDocumentQuery(CollectionUri,$"SELECT * FROM T",options).AsDocumentQuery();