Модель ресурсов Azure Cosmos DB

ОБЛАСТЬ ПРИМЕНЕНИЯ: API SQL API Cassandra API Gremlin API таблиц API Azure Cosmos DB для MongoDB

Azure Cosmos DB — это полностью управляемая платформа как услуга (PaaS). Чтобы начать использовать Azure Cosmos DB, создайте учетную запись Azure Cosmos DB в группе ресурсов Azure в своей подписке. Затем создайте базы данных и контейнеры в учетной записи.

Ваша учетная запись Azure Cosmos DB содержит уникальное DNS-имя, и ею можно управлять с помощью портала Azure, шаблонов ARM или Bicep, Azure PowerShell, Azure CLI или любого пакета SDK для управления Azure или REST API. Дополнительные сведения см. в статье Управление учетной записью Azure Cosmos с использованием портала Azure. Для репликации данных и высокой пропускной способности в учетной записи можно в любое время добавлять и удалять регионы Azure. В учетной записи можно настроить один или несколько регионов записи. Дополнительные сведения см. в статье Добавление регионов Azure в учетную запись и их удаление. В учетной записи можно настроить уровень согласованности по умолчанию.

Элементы в учетной записи Azure Cosmos DB

На данный момент по подписке Azure можно создать до 50 учетных записей Azure Cosmos DB (это мягкое ограничение, которое можно увеличить, отправив запрос на поддержку). Одна учетная запись Azure Cosmos DB может управлять практически неограниченным объемом данных и подготовленной пропускной способностью. Для управления своими данными и подготовленной к работе пропускной способностью можно создать одну или несколько баз данных в своей учетной записи, а затем один или несколько контейнеров для хранения ваших данных. На следующем изображении показана иерархия элементов в учетной записи Azure Cosmos DB:

Иерархия учетной записи Azure Cosmos DB

Ниже показана иерархия разных сущностей в учетной записи Azure Cosmos DB:

Сущности учетной записи Azure Cosmos DB

Базы данных Azure Cosmos DB

В Azure Cosmos DB база данных аналогична пространству имен. База данных — это просто группа контейнеров. В следующей таблице показано, как база данных соотносится с разными сущностями определенных API:

Сущность Azure Cosmos DB API SQL API Cassandra API Azure Cosmos DB для MongoDB API Gremlin API таблиц
База данных Azure Cosmos База данных Пространство ключей База данных База данных Н/Д

Примечание

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

Контейнеры Azure Cosmos DB

Контейнер Azure Cosmos DB — это место, где хранятся данные. В отличие от большинства реляционных баз данных, которые масштабируются с увеличением размера виртуальных машин, масштаб Azure Cosmos DB горизонтально увеличивается. Данные хранятся на одном или нескольких серверах, называемых секциями. Чтобы увеличить пропускную способность или хранилище, добавляются дополнительные секции. Это обеспечивает практически неограниченную пропускную способность и хранилище для контейнера. При создании контейнера необходимо указать ключ секции. Это свойство, которое вы выбираете из своих документов для хранения. Затем значение этого свойства используется для маршрутизации данных в секцию для записи, обновления или удаления. Его также можно использовать в предложении WHERE в запросах для эффективного получения данных.

Базовый механизм хранения данных в Azure Cosmos DB называется физической секцией. Они могут иметь пропускную способность до 10 000 ЕЗ/с и хранить до 50 ГБ данных. Azure Cosmos DB абстрагирует это с помощью логической секции, которая может хранить до 20 ГБ данных. Логические секции позволяют службе обеспечивать большую эластичность и лучшее управление данными в базовых физических секциях по мере добавления новых секций. Дополнительные сведения о секционировании и ключах секций см. в статье Секционирование данных.

При создании контейнера пропускную способность можно настроить для использования в одном из следующих режимов:

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

  • Общая пропускная способность. Здесь пропускная способность указывается на уровне базы данных, а затем совместно используется до 25 контейнерами в базе данных (за исключением контейнеров, для которых настроена выделенная пропускная способность). Это может быть хорошим вариантом, когда все контейнеры в базе данных имеют одинаковые запросы и требования к хранилищу или когда вам не нужна предсказуемая производительность для данных. Дополнительные сведения см. в статье Подготовка пропускной способности для базы данных

Примечание

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

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

Вы можете установить время жизни (TTL) для выбранных элементов в контейнере или для всего контейнера, чтобы автоматически удалять эти элементы в фоновом режиме с неиспользованной пропускной способностью, во избежание снижения производительности. Но даже если они не будут удалены, любые данные с истекшим сроком действия не будут отображаться ни в одном чтении. Дополнительные сведения см. в статье Настройка срока жизни для контейнера.

Azure Cosmos DB предоставляет встроенную возможность отслеживания измененных данных, называемую каналом изменений, которую можно использовать для подписки на все изменения данных в вашем контейнере. Дополнительные сведения см. в статье Канал изменений в Azure Cosmos DB.

Вы можете регистрировать хранимые процедуры, триггеры, определяемые пользователем функции и процедуры слияния для контейнера.

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

Контейнер соотносится с сущностями, является специализированным для сущностей определенных API, как показано в таблице ниже.

Сущность Azure Cosmos DB API SQL API Cassandra API Azure Cosmos DB для MongoDB API Gremlin API таблиц
Контейнер Azure Cosmos Контейнер Таблица Коллекция График Таблица

Примечание

При создании контейнеров следите за тем, чтобы не создать два контейнера с одинаковыми именами, но в разных регистрах. Некоторые части платформы Azure не учитывают регистр. Это может привести к путанице или коллизии данных телеметрии и действий над контейнерами с такими именами.

Панель свойств контейнера Azure Cosmos DB

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

Системные свойства Генерируемые системой или настраиваемые пользователем Цель API SQL API Cassandra API Azure Cosmos DB для MongoDB API Gremlin API таблиц
_rid Генерируемые системой Уникальный идентификатор контейнера. Да Нет Нет Нет Нет
_etag Генерируемые системой Тег сущности, используемый для управления оптимистической блокировкой. Да Нет Нет Нет Нет
_ts Генерируемые системой Метка времени последнего обновления контейнера. Да Нет Нет Нет Нет
_self Генерируемые системой Адресуемый URI контейнера. Да Нет Нет Нет Нет
идентификатор Настраиваемые пользователем Имя контейнера Да Да Да Да Да
indexingPolicy Настраиваемые пользователем Предоставляет возможность изменять индексы Да Нет Да Да Да
timeToLive Настраиваемые пользователем Позволяет автоматически удалять элементы из контейнера через заданное время. Дополнительные сведения см. в статье Срок жизни. Да Нет Нет Нет Да
changeFeedPolicy Настраиваемые пользователем Используется для считывания изменений, внесенных в элементы в контейнере. Дополнительные сведения см. в статье Канал изменений. Да Нет Нет Нет Да
uniqueKeyPolicy Настраиваемые пользователем Гарантируют уникальность одного или нескольких значений в пределах логической секции. Дополнительные сведения см. в статье Ограничения уникальных ключей. Да Нет Нет Нет Да
AnalyticalTimeToLive Настраиваемые пользователем Позволяет автоматически удалять элементы из контейнера через заданное время. Дополнительные сведения см. в статье Срок жизни. Да Нет Да Нет Нет

Элементы Azure Cosmos DB

В зависимости от того, какой API вы используете, данные могут представлять либо элемент в контейнере, либо документ в коллекции, либо запись в таблице, либо узел или ребро в графе. В следующей таблице показано, как элемент Azure Cosmos соотносится с разными сущностями определенных API:

Сущность Azure Cosmos DB API SQL API Cassandra API Azure Cosmos DB для MongoDB API Gremlin API таблиц
Элемент Azure Cosmos DB Item Строка Документ Узел или ребро Item

Свойства элемента

Каждый элемент Azure Cosmos имеет следующие системные свойства. В зависимости от используемого API некоторые из них могут быть недоступны напрямую.

Системные свойства Генерируется системой или определяется пользователем Цель API SQL API Cassandra API Azure Cosmos DB для MongoDB API Gremlin API таблиц
_rid Генерируемые системой Уникальный идентификатор элемента Да Нет Нет Нет Нет
_etag Генерируемые системой Тег сущности, используемый для управления оптимистической блокировкой. Да Нет Нет Нет Нет
_ts Генерируемые системой Метка времени последнего обновления элемента Да Нет Нет Нет Нет
_self Генерируемые системой Адресуемый URI элемента. Да Нет Нет Нет Нет
идентификатор Можно использовать Определяемое пользователем уникальное имя в пределах логической секции. Да Да Да Да Да
Определяемые пользователем свойства Определяемые пользователем маршруты Определяемые пользователем свойства в собственном формате API (включая JSON, BSON и CQL). Да Да Да Да Да

Примечание

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

Операции с элементами

Элементы Azure Cosmos поддерживают приведенные ниже операции. Для выполнения этих операций можно использовать любой из интерфейсов API Azure Cosmos.

Операция API SQL API Cassandra API Azure Cosmos DB для MongoDB API Gremlin API таблиц
Вставка, замена, удаление, обновление или вставка, чтение Да Да Да Да Да

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

Узнайте, как управлять учетной записью Azure Cosmos, и ознакомьтесь с другими концепциями: