Ограничения для уникальных ключей в Azure Cosmos DB

ОБЛАСТЬ ПРИМЕНЕНИЯ: NoSQL

Уникальные ключи добавляют уровень целостности данных в контейнер Azure Cosmos DB. При создании контейнера Azure Cosmos DB создается уникальная политика ключей. Уникальные ключи гарантируют уникальность одного или нескольких значений в пределах логической секции. Вы также можете гарантировать уникальность для каждого ключа секции.

После создания контейнера с политикой уникальных ключей в логической секции блокируется создание любых новых или обновленных элементов с дублирующимися значениями, как указано в ограничении уникальных ключей. Ключ секции в сочетании с уникальным ключом гарантирует уникальность элемента в области контейнера.

Например, рассмотрим контейнер Azure Cosmos DB с Email address уникальным ограничением ключа и CompanyID ключом секции. Когда вы настроите уникальный ключ для адреса электронной почты пользователей, каждый элемент будет гарантированно содержать уникальный адрес электронной почты в пределах каждого CompanyID. Невозможно создать два элемента с дублирующимся адресом электронной почты и с тем же значением ключа секции. В API Azure Cosmos DB для NoSQL элементы хранятся в виде значений JSON. В этих JSON значениях учитывается регистр. При выборе свойства в качестве уникального ключа можно вставить значения с учетом регистра для этого свойства. Например, если в свойстве Name определен уникальный ключ, "Svetlana" отличается от "svetlana", и вы можете вставить оба элемента в контейнер.

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

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

CompanyID	Имя	Фамилия	Адрес электронной почты
Contoso	Гэби	Дюперре	gaby@contoso.com
Contoso	Гэби	Дюперре	gaby@fabrikam.com
Fabrikam	Гэби	Дюперре	gaby@fabrikam.com
Fabrikam	Иван	Дюперре	gaby@fabrikam.com
Fabrkam		Дюперре	gaby@fabraikam.com
Fabrkam			gaby@fabraikam.com

При попытке вставить новый элемент с сочетанием значений, которое указано в предыдущей таблице, вы получите ошибку. Такая ошибка означает, что ограничение уникального ключа не соблюдается. Вы получаете Resource with specified ID or name already exists либо Resource with specified ID, name, or unique index already exists в виде возвращаемого сообщения.

Определение уникального ключа

Вы можете определить уникальные ключи только при создании контейнера Azure Cosmos DB. Уникальный ключ ограничивается логической секцией. В предыдущем примере, если контейнер секционируется по почтовому индексу, вы получите одинаковые элементы в каждой логической секции. При создании уникальных ключей учитывайте следующие аспекты.

• Вы не можете изменить уникальный ключ для имеющегося контейнера. Другими словами, после создания контейнера с политикой уникальных ключей эту политику невозможно изменить.

• Чтобы задать уникальный ключ для уже существующего контейнера, создайте новый контейнер с ограничением уникального ключа. Используйте соответствующее средство миграции данных, чтобы переместить все данные из старого контейнера в новый. Для контейнеров SQL используйте задания копирования контейнеров для перемещения данных. Для контейнеров MongoDB используйте mongoimport.exe или mongorestore.exe для перемещения данных.

• Политика уникальных ключей может содержать не более 16значений путей. Например, значениями могут быть /firstName, /lastName и /address/zipCode. Каждая политика уникальных ключей может иметь не более 10 ограничений уникальных ключей или сочетаний. В предыдущем примере имя, фамилия и адрес электронной почты в совокупности считаются одним ограничением. Это ограничение использует 3 из 16 допустимых путей.

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

• Разреженные уникальные ключи не поддерживаются. Если для некоторых уникальных путей отсутствуют значения, для них в ограничении уникальности используется значение null. Это означает, что такое ограничение допускает наличие только одного элемента со значением null.

• В именах уникальных ключей учитывается регистр. Например, рассмотрим контейнер с ограничением уникального ключа равным /address/zipcode. Если в данных есть поле с именем ZipCode, Azure Cosmos DB вставляет "null" в качестве уникального ключа, так как zipcode не совпадает с ZipCode. Учет регистра в этой ситуации приводит к тому, что другие записи со значением ZipCode добавлены не будут, ведь новое значение null нарушит требование уникальности ключа.

Следующие шаги

• Подробнее о логических разделах.
• Узнайте, как определять уникальные ключи при создании контейнера
• Если вы планируете ресурсы для миграции в Azure Cosmos DB, Для планирования ресурсов можно использовать сведения об имеющемся кластере базы данных.
  • Если вам известно только количество виртуальных ядер и серверов в существующем кластере баз данных, прочитайте об оценке единиц запроса на основе этих данных.
  • Если вам известна стандартная частота запросов для текущей рабочей нагрузки базы данных, ознакомьтесь со статьей о расчете единиц запросов с помощью планировщика ресурсов Azure Cosmos DB