Блог

Я работаю с Azure CosmosDB, и, более конкретно, с API Gremlin, и я немного зациклен на том, что выбрать в качестве ключа раздела.

Действительно, поскольку я использую данные graph, не все вершины соответствуют одной и той же схеме данных. Если я выберу свойство, которое не является общим для всех вершин, Azure не позволит мне хранить вершины, у которых нет значения для ключа раздела. Проблема в том, что единственное свойство, которое у них у всех есть общее, это /id , но Azure не позволяет использовать это свойство в качестве ключа раздела.

Означает ли это, что мне нужно создать свойство, которое будет общим для всех моих вершин? Разве это немного не убивает назначение данных graph? Или я что-то упускаю?

Например, в моем случае я хочу смоделировать объект и его части. Каждый объект и каждая часть имеют свойство /identificationNumber . Было бы лучше использовать это свойство в качестве ключа разделения или создать новое свойство /partitionKey , предназначенное для целей разделения? Меня беспокоит то, что, если я выберу /identificationNumber в качестве ключа раздела, и если моя модель данных должна будет развиваться в будущем, если мне придется моделировать новые объекты без /identificationNumber , мне придется искусственно добавлять это свойство к этим объектам модели данных, что может привести к некоторой путанице.

Создание специального свойства для использования в качестве синтетического ключа раздела является хорошей практикой, если нет очевидного существующего свойства для использования. Этот подход может смягчить случаи, когда у вас нет /identificationNumber в некоторых объектах, поскольку в этих случаях вы можете присвоить какое-либо другое значение в качестве partitionKey . Это также обеспечивает гибкость при проведении рефакторинга /identificationNumber в будущем, поскольку partitionKey это то, что должно быть неизменным.

Мы не должны беспокоиться об «искусственном свойстве», потому что это неотъемлемо при использовании разделенной базы данных. Это не обязательно должно быть доступно пользователям, но разработчики должны понимать, что Cosmos несколько отличается от традиционных баз данных. Также можно перейти на новый ключ раздела, скопировав все данные в новый контейнер, в худшем случае сожаления в будущем. Вероятно, лучше всего начать работу над проектом с наилучшего предположения и посмотреть, как все работает, и, возможно, повторить различные идеи для сравнения производительности и т.д.