Часто задаваемые вопросы об интегрированном кэше Azure Cosmos DB
ОБЛАСТЬ ПРИМЕНЕНИЯ: NoSQL
Интегрированный кэш Azure Cosmos DB — это кэш в памяти, встроенный в Azure Cosmos DB. В этой статье приведены ответы на часто задаваемые вопросы об интегрированном кэше Azure Cosmos DB.
Часто задаваемые вопросы
Почему интегрированный кэш требует выделенного шлюза?
Если вы подключились к Azure Cosmos DB в режиме шлюза, вы использовали стандартный шлюз. В то время как серверная часть Azure Cosmos DB (включающая подготовленную пропускную способность и хранилище) имеет выделенную емкость для каждого контейнера, стандартный шлюз используется совместно многими клиентами. Для многих клиентов очень удобно совместно использовать стандартный шлюз, так как вычислительные ресурсы, потребляемые каждым клиентом, минимальны. Так как интегрированный кэш зависит от учетной записи Azure Cosmos DB и требует значительных ресурсов ЦП и памяти, для него требуются выделенные узлы шлюза.
Что такое выделенный шлюз?
Выделенный шлюз — это серверный вычислительный ресурс, который выполняет роль внешнего интерфейса для данных в учетной записи Azure Cosmos DB. При подключении к конечной точке выделенного шлюза с помощью режима шлюза приложение отправляет запрос на выделенный шлюз, который затем направляет запрос в разные внутренние секции. Использование прямого режима с выделенным шлюзом поддерживается, но эти запросы не будут использовать интегрированный кэш.
Дает ли использование выделенного шлюза другие преимущества, повышающие производительность, по сравнению с использованием стандартного шлюза?
Как правило, запросы, направляемые выделенным шлюзом, будут иметь чуть более низкую и более устойчивую задержку, чем запросы, направляемые стандартным шлюзом. Даже запросы, не использующие интегрированный кэш, будут по-прежнему иметь немного меньшую задержку, чем при применении стандартного шлюза.
Какую задержку следует ожидать при использовании интегрированного кэша?
Запрос, направляемый интегрированным кэшем, выполняется быстро, поскольку кэшированные данные хранятся в памяти в выделенном шлюзе, а не в серверной части.
Для кэшированных операций точечного чтения следует ожидать среднюю задержку в 2–4 мс. Для кэшированных запросов задержка зависит от запроса. Кэш запросов работает путем кэширования ответа обработчика запросов для конкретного запроса. Затем этот ответ отправляется обратно клиенту в пакет SDK для обработки. Для простых запросов требуется выполнение минимальной работы в пакете SDK, а средние задержки в 2–4 мс являются типичными. Более сложные запросы с GROUP BY
или DISTINCT
требуют большей обработки в пакете SDK, поэтому задержка может быть выше даже при использовании кэша запросов.
Если вы ранее подключились к Azure Cosmos DB в режиме прямого подключения и перешли на подключение с выделенным шлюзом, то для некоторых запросов может наблюдаться небольшое увеличение задержки. Для использования режима подключения через шлюз необходимо отправить запрос на шлюз (в данном случае выделенный шлюз), а затем соответствующим образом направить его в серверную часть. Режим прямого подключения, как следует из его названия, позволяет клиенту обмениваться данными напрямую с серверной частью, устраняя необходимость дополнительного прыжка. Соглашения об уровне обслуживания по задержке для запросов с использованием выделенного шлюза не существует.
Если приложение ранее использовало режим прямого подключения, то преимущества от применения интегрированного кэша будут существенными только при следующих сценариях:
- Наличие задержки считывания точки для больших элементов (> 16 КБ)
- Большие единицы запроса или сложные запросы
Если приложение ранее использовало режим подключения через шлюз с применением стандартного шлюза, интегрированный кэш обеспечит сокращение задержки почти во всех сценариях.
Распространяется ли соглашение об уровне обслуживания, описывающее доступность Azure Cosmos DB, на выделенный шлюз и интегрированный кэш?
Для сценариев, в которых требуется высокий уровень доступности, необходимо подготовить как минимум 3 узла выделенного шлюза, чтобы соответствовать требованиям Соглашения об уровне обслуживания по доступности Azure Cosmos DB. Например, если в рабочей среде требуется один узел выделенного шлюза, необходимо подготовить два дополнительных узла в учетной записи на случай возможных простоев, сбоев или обновлений. Если подготовлен только один узел выделенного шлюза, доступность в таких сценариях будет временно отсутствовать. Кроме того, убедитесь, что в выделенном шлюзе имеется достаточно узлов, чтобы обслуживать рабочую нагрузку.
Интегрированный кэш доступен только для API для NoSQL прямо сейчас. Вы планируете выпустить его для других API?
Расширение интегрированного кэша за пределами API для NoSQL планируется в долгосрочной стратегии, но выходит за рамки начальной области интегрированного кэша.
Какой тип согласованности поддерживает интегрированный кэш?
Интегрированный кэш поддерживает согласованность сеансов и итоговую согласованность. Вы также можете настроить необязательный параметр MaxIntegratedCacheStaleness, который задает верхнюю границу для кэшируемых данных.
Следующие шаги
- Интегрированный кэш
- Настройка интегрированного кэша
- Выделенный шлюз
- Если вы планируете ресурсы для миграции в Azure Cosmos DB, Для планирования ресурсов можно использовать сведения об имеющемся кластере базы данных.
- Если вам известно только количество виртуальных ядер и серверов в существующем кластере баз данных, см. сведения об оценке единиц запросов на основе виртуальных ядер и серверов.
- Если вам известна стандартная частота запросов для текущей рабочей нагрузки базы данных, ознакомьтесь со статьей о расчете единиц запросов с помощью планировщика ресурсов Azure Cosmos DB