Примечание.
Для доступа к этой странице требуется авторизация. Вы можете попробовать войти или изменить каталоги.
Для доступа к этой странице требуется авторизация. Вы можете попробовать изменить каталоги.
Как клиент подключается к Azure Cosmos DB, имеет важные последствия для производительности, особенно для наблюдаемой задержки на стороне клиента. Azure Cosmos DB предлагает простую модель программирования RESTful по протоколу HTTPS, называемому режимом шлюза . Кроме того, он предлагает эффективный протокол TCP, который также является RESTful в своей модели обмена данными и использует TLS для начальной проверки подлинности и шифрования трафика, называемого прямым режимом.
Доступные режимы подключения
Два доступных режима подключения:
Режим шлюза
Режим шлюза поддерживается на всех платформах SDK. Если приложение работает в корпоративной сети с строгими ограничениями брандмауэра, режим шлюза является лучшим выбором, так как он использует стандартный порт HTTPS и одну конечную точку DNS. Однако компромисс производительности заключается в том, что режим шлюза включает дополнительные сетевые прыжки каждый раз, когда данные считываются или записываются в Azure Cosmos DB. Мы также рекомендуем использовать режим подключения через шлюз при запуске приложений в средах с ограниченным количеством подключений сокетов.
При использовании пакета SDK в Функциях Azure, особенно в плане потребления, помните о текущих ограничениях на подключения.
Прямой режим
Прямой режим поддерживает подключение через протокол TCP, используя TLS для начальной проверки подлинности и шифрования трафика, и обеспечивает более высокую производительность, так как есть меньше сетевых прыжков. Приложение подключается непосредственно к серверным репликам. В настоящее время режим direct поддерживается только на платформах пакета SDK для .NET и Java.
Эти режимы подключения фактически определяют маршрут, по которому данные от запросов на чтение и запись документов идут с вашего клиентского компьютера к разделам в серверной части Azure Cosmos DB. Прямой режим — предпочтительный вариант для оптимальной производительности; он позволяет клиенту открывать TCP-подключения непосредственно к секциям в серверной части Azure Cosmos DB и отправлять запросы напрямуюбез посредника. В отличие от этого, в режиме шлюза запросы, сделанные клиентом, направляются на так называемый сервер шлюза во фронтенде Azure Cosmos DB, который, в свою очередь, распределяет ваши запросы к соответствующим партициям в серверной части Azure Cosmos DB.
Диапазоны портов службы
При использовании прямого режима необходимо убедиться, что клиент может получить доступ к портам в диапазоне от 10000 до 20000, так как Azure Cosmos DB использует динамические TCP-порты. Это в дополнение к портам шлюза. При использовании прямого режима в частных конечных точках Azure Cosmos DB может использовать полный диапазон TCP-портов от 0 до 65535. Если эти порты не открыты в клиенте, и вы пытаетесь использовать протокол TCP, может появиться сообщение об ошибке "503 Служба недоступна".
В следующей таблице показана сводка режимов подключения, доступных для различных API и портов служб, используемых для каждого API:
| Режим подключения | Поддерживаемый протокол | Поддерживаемые SDK | API и порт службы |
|---|---|---|---|
| Gateway | HTTPS | Все пакеты SDK | SQL (443), MongoDB (10255), Таблица (443), Cassandra (10350), Graph (443) |
| Напрямую | TCP (зашифрован с помощью TLS) | .NET SDK, Java SDK | При использовании общедоступной конечной точки или конечных точек службы: порты в диапазоне от 10000 до 20000 При использовании частных конечных точек: порты в диапазоне от 0 до 65535 |
Архитектура подключения к прямому режиму
Как описано в руководстве, клиенты прямого режима подключаются непосредственно к внутренним узлам через протокол TCP. Каждый внутренний узел представляет реплику в наборе реплик , принадлежащих физической секции.
Маршрутизация
Когда пакет SDK Azure Cosmos DB в прямом режиме выполняет операцию, необходимо определить, к какой серверной реплике подключиться. Первым шагом является знание физической секции, к которой должна перейти операция, и для этого пакет SDK получает сведения о контейнере, включающие определение ключа секции из узла шлюза. Кроме того, ему требуются сведения о маршрутизации, содержащие TCP-адреса реплик. Сведения о маршрутизации доступны также из узлов шлюза, и оба считаются метаданными плоскости управления. После получения сведений о маршрутизации пакет SDK может продолжить открытие TCP-подключений к репликам, принадлежащим целевой физической секции, и выполнить операции.
Каждый набор реплик содержит одну первичную реплику и три вторичных реплики. Операции записи всегда направляются на первичные узлы реплики, а операции чтения можно обслуживать с первичных или вторичных узлов.
Так как сведения о контейнере и маршрутизации часто не изменяются, он кэширован локально на пакетах SDK, чтобы последующие операции могли воспользоваться этой информацией. Уже установленные TCP-подключения также повторно используются в операциях. Если иное не настроено с помощью параметров пакетов SDK, подключения постоянно сохраняются во время существования экземпляра пакета SDK.
Как и в любой распределенной архитектуре, компьютеры с репликами могут пройти обновление или обслуживание. Служба гарантирует согласованность набора реплик, но любое перемещение реплики приведет к изменению существующих TCP-адресов. В таких случаях пакеты SDK должны обновлять сведения о маршрутизации и повторно подключаться к новым адресам с помощью новых запросов шлюза. Эти события не должны влиять на общее соглашение об уровне обслуживания P99.
Объем подключений
Каждый физический раздел имеет набор из четырех реплик, чтобы обеспечить оптимальную производительность, SDK в конечном итоге устанавливают подключения ко всем репликам для нагрузок, смешивающих операции записи и чтения. Параллельные операции распределяют нагрузку между существующими подключениями, чтобы использовать пропускную способность, которую предоставляет каждая реплика.
Существует два фактора, определяющие количество TCP-подключений, открывающих пакет SDK:
Количество физических разделов
В устойчивом состоянии пакет SDK имеет одно подключение для каждой реплики для каждой физической секции. Чем больше количество физических секций в контейнере, тем больше число открытых подключений. По мере маршрутизации операций по разным секциям подключения устанавливаются по запросу. Затем среднее число подключений будет числом физических разделов, умноженным на четыре.
Объем одновременных запросов
Каждое установленное подключение может служить настраиваемому количеству параллельных операций. Если объем параллельных операций превышает это пороговое значение, открываются новые подключения для их обслуживания, и, возможно, для физического раздела число открытых подключений превышает устойчивое количество подключений. Это поведение ожидается для рабочих нагрузок, которые могут иметь пики в своем объёме работы. Для пакета SDK для .NET эта конфигурация устанавливается maxRequestsPerTcpConnection, а для пакета SDK java можно настроить с помощью класса DirectConnectionConfig.
По умолчанию подключения постоянно поддерживаются для повышения производительности будущих операций (открытие подключения имеет вычислительные издержки). В некоторых сценариях может потребоваться закрыть подключения, которые не используются в течение некоторого времени, что может немного повлиять на будущие операции. Для пакета SDK для .NET эта конфигурация устанавливается с помощью IdleTcpConnectionTimeout, а для пакета SDK java можно настроить с помощью класса DirectConnectionConfig. Не рекомендуется устанавливать эти конфигурации на низкие значения, так как это может привести к тому, что подключения часто закрываются и влияют на общую производительность.
Сведения о реализации для конкретного языка
Для деталей реализации касательно языка, смотрите:
Дальнейшие шаги
Для конкретных оптимизаций производительности платформы SDK:
- Советы по производительности пакета SDK для .NET версии 2
- Советы по производительности пакета SDK для .NET версии 3
- Советы по производительности пакета SDK для Java версии 4
Пытаетесь составить план мощностей для миграции в Azure Cosmos DB? Для планирования ресурсов можно использовать сведения об имеющемся кластере базы данных.
- Если вы знаете количество виртуальных ядер и серверов в существующем кластере базы данных, ознакомьтесь с описанием оценки единиц запросов с помощью виртуальных ядер или виртуальных ЦП.
- Если вам известна стандартная частота запросов для текущей рабочей нагрузки базы данных, ознакомьтесь со статьей о расчете единиц запросов с помощью планировщика ресурсов Azure Cosmos DB.