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

ПРИМЕНИМО К: API SQL

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

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

Для примера рассмотрим контейнер Azure Cosmos, в котором настроен уникальный ключ Email address с ограничением по адресу электронной почты и ключ секции CompanyID. Когда вы настроите уникальный ключ для адреса электронной почты пользователей, каждый элемент будет гарантированно содержать уникальный адрес электронной почты в пределах каждого CompanyID. Невозможно создать два элемента с дублирующимся адресом электронной почты и с тем же значением ключа секции. В API-интерфейсе SQL Azure Cosmos DB (Core) элементы хранятся в формате значений 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. Уникальный ключ ограничивается логической секцией. В предыдущем примере, если контейнер секционируется по почтовому индексу, вы получите повторяющиеся элементы в каждой логической секции. При создании уникальных ключей учитывайте следующие аспекты.

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

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

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

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

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

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

Дальнейшие действия