Базы данных, контейнеры и элементы в Azure Cosmos DB
Область применения: 
Nosql Mongodb Кассандра Гремлин Таблица
Azure Cosmos DB — это полностью управляемая платформа как услуга (PaaS). Чтобы начать использовать Azure Cosmos DB, создайте учетную запись Azure Cosmos DB в группе ресурсов Azure в своей подписке. Затем создайте базы данных и контейнеры в учетной записи.
Учетная запись Azure Cosmos DB содержит уникальное доменное имя (DNS). Вы можете управлять DNS-именем с помощью множества средств, включая:
- Портал Azure
- Шаблоны диспетчера ресурсов Azure
- Шаблоны Bicep
- Azure PowerShell
- Azure CLI
- Пакеты SDK для управления Azure
- Azure REST API
Для репликации данных и высокой пропускной способности в учетной записи можно в любое время добавлять и удалять регионы Azure. В учетной записи можно настроить один или несколько регионов записи. Дополнительные сведения см. в статье "Управление учетной записью Azure Cosmos DB" с помощью портал Azure. Вы также можете настроить уровень согласованности по умолчанию в учетной записи.
Элементы в учетной записи Azure Cosmos DB
В настоящее время можно создать не более 50 учетных записей Azure Cosmos DB в подписке Azure. Это ограничение можно увеличить, выполнив запрос на поддержку.
Вы можете управлять практически неограниченным объемом данных и подготовленной пропускной способностью с помощью одной учетной записи Azure Cosmos DB. Для управления данными и подготовленной пропускной способностью необходимо создать одну или несколько баз данных в учетной записи, а затем создать один или несколько контейнеров для хранения данных.
На следующем рисунке показана иерархия элементов в учетной записи Azure Cosmos DB.
На следующем рисунке показана иерархия сущностей в учетной записи Azure Cosmos DB.
Базы данных Azure Cosmos DB
В Azure Cosmos DB база данных аналогична пространству имен. База данных — это просто группа контейнеров. В следующей таблице показано, как база данных соотносится с разными сущностями определенных API:
| Сущность Azure Cosmos DB | API для NoSQL | API для Apache Cassandra | API для MongoDB | API для Apache Gremlin | API для таблицы |
|---|---|---|---|---|---|
| База данных Azure Cosmos DB | База данных | Пространство ключей | База данных | База данных | Неприменимо |
Примечание.
С помощью API для учетных записей таблиц таблицы таблицы в Azure Cosmos DB создаются на уровне учетной записи для обеспечения совместимости с таблицами Azure служба хранилища.
Контейнеры Azure Cosmos DB
Контейнер Azure Cosmos DB — это место, где хранятся данные. В отличие от большинства реляционных баз данных, которые масштабируется с большими размерами виртуальных машин, Azure Cosmos DB масштабируется.
Данные хранятся на одном или нескольких серверах, называемых секциями. Чтобы увеличить секции, вы увеличиваете пропускную способность или автоматически увеличивается по мере увеличения хранилища. Эта связь обеспечивает практически неограниченное количество пропускной способности и хранилища для контейнера.
При создании контейнера необходимо указать ключ секции. Ключ секции — это свойство, которое вы выбираете из элементов, чтобы помочь Azure Cosmos DB эффективно распределять данные по секциям. Azure Cosmos DB использует значение этого свойства для маршрутизации данных в соответствующую секцию для записи, обновления или удаления. Вы также можете использовать ключ секции в предложении в WHERE запросах для эффективного извлечения данных.
Базовый механизм хранения данных в Azure Cosmos DB называется физической секцией. Физические секции могут иметь пропускную способность до 10 000 единиц запросов в секунду, и они могут хранить до 50 ГБ данных. Azure Cosmos DB абстрагирует эту концепцию секционирования с логическим разделом, который может хранить до 20 ГБ данных.
Логические секции позволяют службе обеспечить большую эластичность и более эффективное управление данными на базовых физических секциях при добавлении дополнительных секций. Дополнительные сведения о секционированиях и ключах секционирования см. в статье Секционирование и горизонтальное масштабирование в Azure Cosmos DB.
При создании контейнера пропускную способность можно настроить для использования в одном из следующих режимов:
Выделенная пропускная способность: пропускная способность контейнера зарезервирована исключительно для этого контейнера. Существует два типа выделенной пропускной способности: стандартная и автомасштабирование. Дополнительные сведения см. в статье "Подготовка стандартной (ручной) пропускной способности в контейнере Azure Cosmos DB.
Общая пропускная способность: пропускная способность указывается на уровне базы данных, а затем предоставляется общий доступ к 25 контейнерам в базе данных. Совместное использование пропускной способности исключает контейнеры, настроенные с собственной выделенной пропускной способностью.
Общая пропускная способность может быть хорошим вариантом, если все контейнеры в базе данных имеют аналогичные запросы и потребности в хранилище, или если не требуется прогнозируемая производительность данных. Дополнительные сведения см. в статье "Подготовка стандартной (ручной) пропускной способности в базе данных в Azure Cosmos DB.
Примечание.
Вы не можете переключаться между выделенной и общей пропускной способностью. Контейнеры, созданные в базе данных общей пропускной способности, не могут быть обновлены, чтобы иметь выделенную пропускную способность. Чтобы изменить контейнер с общего доступа к выделенной пропускной способности, необходимо создать новый контейнер и скопировать в него данные. Функция копирования контейнеров в Azure Cosmos DB упрощает этот процесс.
Контейнеры не зависят от схемы. Элементы в контейнере могут иметь произвольные схемы или разные сущности, если они используют один и тот же ключ секции. Например, контейнер может содержать элемент или документ с информацией профиля клиента, а также один или несколько элементов или документов, представляющих все заказы на продажу клиента. Вы можете поместить аналогичную информацию для всех клиентов в одном контейнере.
По умолчанию все данные, добавляемые в контейнер, автоматически индексируются без явного индексирования. Вы можете настроить индексирование контейнера, настроив его политику индексирования.
Чтобы избежать влияния на производительность, можно задать время жизни (TTL) для выбранных элементов в контейнере или в целом контейнере, чтобы автоматически удалить эти элементы в фоновом режиме с неиспользуемой пропускной способностью. Однако даже если истек срок действия данных не удаляется, он не отображается в операциях чтения. Дополнительные сведения см. в статье "Настройка времени жизни в Azure Cosmos DB".
Azure Cosmos DB предоставляет встроенную возможность для отслеживания измененных данных, называемого каналом изменений. Его можно использовать для подписки на все изменения данных в контейнере.
Вы можете регистрировать хранимые процедуры, триггеры, определяемые пользователем функции и процедуры слияния для контейнера.
Каждый документ в контейнере должен иметь id свойство, уникальное в значении свойства логического ключа для этого контейнера. Это сочетание свойств можно использовать для предоставления уникального ограничения в контейнере без явного определения.
Вы также можете указать уникальное ограничение ключа в контейнере Azure Cosmos DB, использующего одно или несколько свойств. Ограничение уникального ключа гарантирует уникальность одного или нескольких значений для каждого логического ключа секции. Если вы создаете контейнер с помощью уникальной политики ключей, вы не можете создавать новые или обновленные элементы со значениями, дублирующими значения, указанные уникальным ограничением ключа.
Контейнер предназначен для сущностей, относящихся к API, как показано в следующей таблице:
| Сущность Azure Cosmos DB | API для NoSQL | API для Cassandra | API для MongoDB | API для Gremlin | API для таблицы |
|---|---|---|---|---|---|
| Контейнер Azure Cosmos DB | Контейнер | Таблица | Коллекция | График | Таблица |
Примечание.
Убедитесь, что вы не создаете два контейнера с одинаковым именем, но разными регистрами. Некоторые части платформы Azure не учитывает регистр, и такой тип именования может привести к путанице или столкновению диагностических данных и действий в контейнерах.
Панель свойств контейнера Azure Cosmos DB
Контейнер Azure Cosmos DB имеет набор системных свойств. В зависимости от используемого API некоторые свойства могут быть недоступны напрямую. В следующей таблице описываются системные свойства:
| Системные свойства | Система, созданная или настраиваемая пользователем | Характер использования | API для NoSQL | API для Cassandra | API для MongoDB | API для Gremlin | API для таблицы |
|---|---|---|---|---|---|---|---|
_rid |
Создано системой | Уникальный идентификатор контейнера. | Да | No | No | No | No |
_etag |
Создано системой | Тег сущности, используемый для управления оптимистическим параллелизмом. | Да | No | No | No | No |
_ts |
Создано системой | Последняя обновленная метка времени контейнера. | Да | No | No | No | No |
_self |
Создано системой | Адресный URI контейнера. | Да | No | No | No | No |
id |
Настраивается пользователем | Имя контейнера. | Да | Да | Да | Да | Да |
indexingPolicy |
Настраивается пользователем | Политика создания индекса для контейнера. | Да | No | Да | Да | Да |
TimeToLive |
Настраивается пользователем | Автоматическое удаление элемента из контейнера после заданного периода времени. Дополнительные сведения см. в разделе "Время жизни". | Да | No | No | No | Да |
changeFeedPolicy |
Настраивается пользователем | Политика чтения изменений, внесенных в элементы в контейнере. Дополнительные сведения см. в статье Канал изменений. | Да | No | No | No | Да |
uniqueKeyPolicy |
Настраивается пользователем | Политика обеспечения уникальности одного или нескольких значений в логическом разделе. Дополнительные сведения см. в статье Ограничения уникальных ключей. | Да | No | No | No | Да |
AnalyticalTimeToLive |
Настраивается пользователем | Автоматическое удаление элемента из контейнера после заданного периода времени в контексте аналитического хранилища. Дополнительные сведения см. в аналитическом хранилище. | Да | No | Да | No | No |
Элементы Azure Cosmos DB
В зависимости от используемого API отдельные сущности данных могут представляться различными способами:
| Сущность Azure Cosmos DB | API для NoSQL | API для Cassandra | API для MongoDB | API для Gremlin | API для таблицы |
|---|---|---|---|---|---|
| Элемент Azure Cosmos DB | Товар | Строка | Документ | Узел или ребро | Товар |
Свойства элемента
Каждый элемент Azure Cosmos DB имеет следующие системные свойства. В зависимости от используемого API некоторые из них могут быть недоступны напрямую.
| Системные свойства | Система, созданная или определяемая пользователем | Характер использования | API для NoSQL | API для Cassandra | API базы данных для MongoDB | API для Gremlin | API для таблицы |
|---|---|---|---|---|---|---|---|
_rid |
Создано системой | Уникальный идентификатор элемента | Да | No | No | No | No |
_etag |
Создано системой | Тег сущности, используемый для управления оптимистической блокировкой. | Да | No | No | No | No |
_ts |
Создано системой | Метка времени последнего обновления элемента | Да | No | No | No | No |
_self |
Создано системой | Адресуемый URI элемента. | Да | No | No | No | No |
id |
Можно использовать | Определяемое пользователем уникальное имя в логическом разделе | Да | Да | Да | Да | Да |
| Определяемые пользователем свойства | Определено пользователем | Определяемые пользователем свойства в представлении API (включая JSON, BSON и CQL) | Да | Да | Да | Да | Да |
Примечание.
Уникальность свойства id обеспечивается в каждой логической секции. Несколько документов могут иметь одно и то же id значение свойства с разными значениями ключа секции.
Операции с элементами
Элементы Azure Cosmos DB поддерживают следующие операции. Для выполнения операций можно использовать любой из API Azure Cosmos DB.
| Операция | API для NoSQL | API для Cassandra | API для MongoDB | API для Gremlin | API для таблицы |
|---|---|---|---|---|---|
| Вставка, замена, удаление, upsert, чтение | Да | Да | Да | Да | Да |
Следующие шаги
Узнайте, как управлять учетной записью Azure Cosmos DB и другими понятиями: