У меня есть модель данных, которая, как говорят свойства A, B, C, D..G. Эта модель имеет составной ключ (A, B, C, D). Мне нужно сохранить объекты этой модели данных в лазурное хранилище. Должен ли я конкатенировать (A + B + C + D), а затем сохранить результат как значение ключа раздела (для более быстрого поиска?).Композитный ключ в качестве ключа раздела для хранения в лазурной таблице
Какова наилучшая практика выбора ключа раздела/строки в таких случаях?
Похоже хорошей отправной точкой.
Публикация ссылки моделирования данных не является ответом. В лучшем случае это комментарий (и у вас достаточно репутации для комментариев). –
Должен ли я конкатенации (A + B + C + D), а затем затем сохранить результат в качестве значения ключа секционирования (для быстрого извлечения операций?)
В этом официальном document упоминалось о рассмотрении запросов :
Знание запросов, которые вы будете использовать, позволит вам определить, какие свойства важны для PartitionKey. Свойства, которые используются в запросах, являются кандидатами для PartitionKey. Если объект имеет более двух ключевых свойств, вы можете использовать составной ключ для конкатенированных значений.
Что является лучшей практикой для выбора ключа раздела/ключ строки в таких случаях?
Для получения более подробной информации о запросе вам необходимо учитывать свойства, используемые в ваших запросах, в качестве кандидатов для PartitionKey или RowKey. Вот простой пример для вас, чтобы иметь лучшее представление о выборе ПК/РК:
Там есть таблица с именем продукта, который обладает следующими свойствами:
| ID | Name | CategoryID | SubCategoryID | DeliveryType | Price | Status | SalesRegion |
Если запрос часто основан в на CategoryID и SubCategoryID мы могли бы объединить CategoryID_SubCategoryID в качестве PartitionKey, чтобы быстро найти конкретный раздел и получить все продукты в пределах определенной категории. Для RowKey мы могли бы просто установить ID для запроса на конкретный идентификатор продукта или SalesRegion_Price_DeliveryType для фильтрации продуктов в заказе SalesRegion, Price, DeliveryType.
Кроме того, вы можете следить за этим tutorial о создании масштабируемой и удобной таблицы хранения Azure.
У этого действительно нет объективного ответа. Вы даже не поделились тем, как вам нужно искать свои данные, так как ваши конкретные потребности будут определять, как сопоставить данные с ключом раздела и ключом строки. Как написано, это только даст вам мнения, основанные ни на чем конкретном. –