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

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

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

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

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

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

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

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

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

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

• Чтобы задать уникальный ключ для уже существующего контейнера, создайте новый контейнер с ограничением уникального ключа. Используйте соответствующее средство миграции данных, чтобы переместить все данные из старого контейнера в новый. Для контейнеров SQL используйте задания копирования контейнеров 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
• Пытаетесь составить план мощностей для миграции в Azure Cosmos DB? Для планирования ресурсов можно использовать сведения об имеющемся кластере базы данных.
  • Если вам известно только количество виртуальных ядер и серверов в существующем кластере баз данных, прочитайте об оценке единиц запроса с использованием виртуальных ядер или виртуальных процессоров.
  • Если вы знаете типичные частоты запросов для текущей рабочей нагрузки базы данных, ознакомьтесь с оценкой единиц запросов с помощью планировщика емкости Azure Cosmos DB.