Cosmos db идентификатор пользователя / адрес электронной почты в качестве ключа раздела

Question

У меня есть дилемма о выборе лучшего (синтаксического) значения для ключа раздела для хранения пользовательских данных.

Пользовательский документ имеет: - идентификатор (гид) - электронная почта (используется для входа, например) - данные профиля

Существует 2 основных типа запросов:

1. Ищу пользователя по id (большинство запросов)
2. Поиск пользователя по email (логин и некоторые запросы администратора)

Я хочу избежать перекрестных запросов.

Если я выберу id для partitionKey (синтетическое поле), тогда запросы на вход в систему будут перекрестными. С другой стороны, если я выберу email, то если пользователь когда-либо изменит электронную почту - это проблема.

Что я думаю, так это ввести новый тип в коллекцию. Что-то вроде:

userId: guid,
userEmail: “email1”,
partitonKey: “users-mappings”

тогда я могу иметь User сам документ как:

id: someguid,
type: “user”,
partitionKey: “user_someguid”,
profileData: {}

таким образом, когда пользователь входит в систему, я сначала проверяю тип / раздел сопоставлений по email, получаю guid, а затем проверяю фактический User документ по guid.

также, таким образом, электронная почта может быть изменена без влияния на разбиение.

это правильный подход? какие-то проблемы с этим? я что-то упустил?

Answer 1

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

Основано на вашем описании:

1. Поиск пользователя по идентификатору (большинство запросов)

2. Поиск пользователя по электронной почте (логин и некоторые запросы администратора)

Я предлагаю вам расставить приоритеты по наиболее частым запросам, то есть id.

Моя причина:

1.id не изменится легко, относительно стабилен.

2.Сеанс или cookie могут быть сохранены после входа в систему, поэтому для входа в систему не так много доступа, как для идентификатора.

3.id - ваше наиболее частое условие запроса, поэтому невозможно каждый раз пересекать все разделы.

4.Если вы беспокоитесь о производительности входа, не забудьте добавить политику индексации для email столбца. Это также может повысить производительность.