Запрос контейнера Azure Cosmos DB

  • Статья

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

В этой статье описывается, как запрашивать контейнеры (коллекции, графы и таблицы) в Azure Cosmos DB. В частности, здесь рассматривается как работают запросы in-partition (запрос в секции) и cross-partition (запрос между секцииями) в Azure Cosmos DB.

Запрос в секции

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

Например, рассмотрим приведенный ниже запрос с фильтром равенства DeviceId. Если этот запрос выполняется в контейнере, секционируемом в DeviceId, этот запрос выполняет фильтрацию по одной физической секции.

SELECT * FROM c WHERE c.DeviceId = 'XMS-0001'

Как и в предыдущем примере, этот запрос также выполняет фильтрацию по одной секции. Добавление фильтра Location в не приводит к изменению следующего запроса:

SELECT * FROM c WHERE c.DeviceId = 'XMS-0001' AND c.Location = 'Seattle'

Вот запрос, имеющий фильтр диапазона для ключа секции и не относящийся к одиночной физической секции. Запрос in-partition должен иметь фильтр равенства, включающий ключ секции:

SELECT * FROM c WHERE c.DeviceId > 'XMS-0001'

Запрос между секциями

Следующий запрос не имеет фильтра для ключа секции (DeviceId). Таким образом, он должен быть реализован для всех физических секций, где он выполняется по индексу каждой секции:

SELECT * FROM c WHERE c.Location = 'Seattle`

Каждая физическая секция имеет собственный индекс. Таким образом, при выполнении межсекционного запроса к контейнеру фактически выполняется один запрос на каждую физическую секцию. Azure Cosmos DB автоматически объединяет результаты по разным физическим секциям.

Индексы в разных физических секциях друг от друга независимы. В Azure Cosmos DB нет глобального индекса.

Параллельный запрос между секциями

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

Вы можете управлять параллельным выполнением запросов, регулируя следующие параметры.

  • MaxConcurrency: позволяет установить максимальное количество одновременных сетевых подключений к секциям контейнера. Если для параметра установить значение -1, пакет SDK будет регулировать степень параллелизма. MaxConcurrency Если для задано значение 0, существует одно сетевое подключение к секциям контейнера.

  • MaxBufferedItemCount: задержка запросов на транзакции и использование памяти на стороне клиента. Если пропустить этот параметр или задать значение -1, пакет SDK будет регулировать число буферизованных элементов при параллельном выполнении запросов.

Из-за возможности Azure Cosmos DB выполнять параллелизацию запросов между секциями задержка запросов обычно масштабируется, так как система добавляет физические секции. Однако при увеличении общего числа физических секций плата за единицы запросов значительно увеличивается.

При выполнении межсекционного запроса вы, по сути, выполняете отдельный запрос для каждой физической секции. Хотя межсекционные запросы используют индекс, если они доступны, они по-прежнему не так эффективны, как запросы в секции.

Полезный пример

Ниже приведена аналогия, чтобы лучше объяснить межсекционные запросы:

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

С помощью этого примера можно сравнивать запросы in-partition и cross-partition:

Запрос в секции (пример)

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

Запрос cross-partition (fan-out)

Если водитель доставки не знает правильный жилой комплекс (физическая секция), он должен проехать в каждый жилой дом и проверить список со всеми номерами квартир жителей (индекс). Как только водитель прибывает в каждый жилой комплекс, он по-прежнему может использовать список адресов каждого жителя. Тем не менее, они должны проверить список каждого жилого комплекса, независимо от того, живут ли там получатели пакетов или нет. В этом примере показано, как работают межсекционные запросы. Хотя они могут использовать индекс (то есть им не нужно стучать в каждую дверь), они должны отдельно проверять индекс для каждой физической секции.

Запрос cross-partition (охватывающий только несколько физических секций)

Если водитель доставки знает, что все получатели посылки живут в нескольких жилых комплексах, им не нужно ездить к каждому из них. Хотя вождение в несколько жилых комплексах по-прежнему требует больше работы, чем посещение только одного здания, водитель доставки по-прежнему экономит значительное время и усилия. Если в фильтре запроса есть ключ секции с ключевым словом IN , он проверяет только соответствующие индексы физической секции на наличие данных.

Избегайте запросов между секциями

Для большинства контейнеров наличие нескольких межсекционных запросов неизбежно, что вполне нормально! Почти все операции запросов поддерживаются в разных секциях, как для логических ключей секций, так и для физических секций. Azure Cosmos DB также имеет много оптимизаций в механизме запросов и клиентских пакетах SDK для параллельного выполнения запросов в физических секциях.

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

Избежание применения запросов cross-partition обычно имеет большое значение только для больших контейнеров. Плата взимается не менее 2,5 ЕЗ при каждой проверке индекса физической секции на наличие результатов, даже если никакие элементы в физической секции не соответствуют фильтру запроса. Таким образом, если у вас есть только одна (или всего несколько) физических секций, межсекционные запросы не потребляют значительно больше единиц запросов, чем запросы в секции.

Число физических секций связано с объемом предоставляемых единиц запросов. Каждая физическая секция поддерживает до 10 000 подготовленных единиц запросов и может хранить до 50 ГБ данных. Azure Cosmos DB автоматически управляет физическими секциями. Количество физических секций в контейнере зависит от подготовленной пропускной способности и используемого хранилища.

Следует стараться избегать запросов между секциями, если рабочая нагрузка соответствует следующим критериям:

  • Вы планируете использовать более 30 000 единиц запросов
  • Вы планируете хранить более 100 ГБ данных

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

Чтобы узнать о секционировании в Azure Cosmos DB, ознакомьтесь со следующими статьями: