Общие сведения о кэше, встроенном в Azure Cosmos DB

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

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

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

Интегрированный кэш автоматически настраивается в выделенном шлюзе. Интегрированный кэш состоит из двух частей:

• Кэш элементов для операций точечного чтения
• Кэш для запросов

Интегрированный кэш — это кэш со сквозным чтением и записью с политикой вытеснения "Наименее недавно использовавшийся" (LRU). Кэш элементов и кэш запросов используют одинаковую емкость в интегрированном кэше, а политика вытеснения LRU применяется к обоим. Данные вытесняются из кэша строго на основе того, когда он был наименее недавно использован, независимо от того, является ли это точка чтения или запроса. Кэшированные данные в каждом узле зависят от данных, которые были недавно записаны или считаны этим конкретным узлом. Если элемент или запрос кэшируется на одном узле, он необязательно кэшируется на других узлах.

Рабочие нагрузки, которые используют преимущества интегрированного кэша

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

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

Рабочие нагрузки, которые соответствуют следующим характеристикам, должны оцениваться, помогает ли интегрированный кэш снизить затраты:

• Рабочие нагрузки с интенсивными операциями чтения
• Многочисленные повторяющиеся операции точечного чтения больших элементов
• Много повторяющихся запросов с высоким уровнем загрузки ресурсов
• Ключ активного раздела для операций чтения

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

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

• Рабочие нагрузки с интенсивными операциями записи
• Редко повторяющиеся операции точечного чтения или запросы
• Нагрузки, читающие канал изменений

Кэш элементов

Кэш элементов используется для операций чтения точек (поиск ключей и значений на основе идентификатора элемента и ключа секции).

Заполнение кэша элементов

• Новые операции записи, обновления и удаления автоматически заполняются в кэше элементов узла, через который направляется запрос.
• Элементы из запросов на чтение точек, при которых элемент отсутствует в кэше узла (промах кэша), через который направляется запрос, добавляются в кэш элементов.
• Чтение запросов для нескольких элементов, таких как ReadMany, наполняет кэш запросов как набор, а не кэш элементов как отдельные элементы.
• Запросы, которые являются частью транзакционного пакета или в массовом режиме , не заполняют кэш элементов.

Недействительность и вытеснение кэша элементов

Так как каждый узел имеет независимый кэш, возможно, что элементы являются недействительными или вытеснены в кэше одного узла, а не других. Элементы в кэше заданного узла являются недействительными и вытеснены на основе следующих критериев:

• Обновление или удаление элемента
• Наименее недавно использовавшийся (LRU)
• Время хранения кэша (иными словами, MaxIntegratedCacheStaleness)

Кэш запросов

Кэш запросов используется для кэширования запросов. Кэш запросов преобразует запрос в поиск ключей и значений, где ключ — текст запроса, а значение — результаты запроса. Встроенный кэш не имеет обработчика запросов; он сохраняет только поиск ключа или значения для каждого запроса. Результаты запроса хранятся в виде набора, и кэш не отслеживает отдельные элементы. Данный элемент может храниться в кэше запросов несколько раз, если он отображается в результирующем наборе нескольких запросов. Обновления базовых элементов не отражаются в результатах запроса до тех пор, пока не будет достигнута максимальная допустимая устарелость встроенного кэша для запроса, и запрос обслуживается из серверной базы данных.

Заполнение кэша запросов

• Если кэш не имеет результата для этого запроса (промаха кэша) на узле, через который он был перенаправлен, запрос отправляется в серверную часть. После выполнения запроса кэш сохраняет результаты для этого запроса.
• Запросы с той же фигурой, но различные параметры или параметры запроса, влияющие на результаты (например, максимальное число элементов), хранятся в виде собственной пары "ключ-значение".
• Чтение запросов для нескольких элементов, таких как ReadManyзаполнение кэша запросов. ReadMany результаты хранятся в виде набора, а запросы с различными входными данными хранятся в виде собственной пары "ключ-значение".

Вытеснение кэша запросов

Вытеснение кэша запросов основано на узле, через который был перенаправлен запрос. Возможно, запросы можно вытеснить или обновить на одном узле, а не на другом.

• Наименее недавно использовавшийся (LRU)
• Время хранения кэша (иными словами, MaxIntegratedCacheStaleness)

Работа с кэшем запросов

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

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

Согласованность интегрированного кэша

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

Самый простой способ — настроить сессионную или конечную согласованность для всех операций чтения на уровне учетной записи. Однако если вам нужно, чтобы согласованность применялась только к некоторым из операций чтения, можно настроить её на уровне запроса.

Согласованность сеанса

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

Максимальная устарелость интегрированного кэша

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

Настройка MaxIntegratedCacheStaleness в запросе, который приводит к заполнению кэша, не влияет на длительность хранения этого запроса в кэше. MaxIntegratedCacheStaleness обеспечивает согласованность при попытке считывания кэшированных данных. Глобальный параметр хранения TTL или кэша отсутствует, поэтому данные удаляются только из кэша, если интегрированный кэш заполнен или выполняется новое чтение с более низким MaxIntegratedCacheStaleness возрастом текущей кэшной записи.

Это улучшение работы большинства кэшей и позволяет выполнять следующие другие настройки:

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

Чтобы составить более четкое представление о параметре MaxIntegratedCacheStaleness, изучите следующий пример:

Сведения о настройке MaxIntegratedCacheStalenessсм. в разделе "Настройка MaxIntegratedCacheStaleness".

Обход интегрированного кэша

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

Обход встроенного кэша для элементов с редким доступом экономит пространство кэша для элементов с большим числом повторений, увеличивая потенциал экономии запросов и уменьшая вытеснения. Запросы, которые обходят кэш, по-прежнему направляются через выделенный шлюз. Эти запросы обрабатываются на серверной стороне и требуют расхода RUs.

Сведения об обходе встроенного кэша см. в разделе "Обход интегрированного кэша".

Метрики

Рекомендуется отслеживать некоторые ключевые DedicatedGateway и IntegratedCache метрики для интегрированного кэша. Дополнительные сведения об этих метриках см. в статье "Поддерживаемые метрики" для Microsoft.DocumentDB/DatabaseAccounts.

Все существующие метрики доступны по умолчанию из метрик в портал Azure (не классические метрики):

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

Устранение распространенных неполадок

В следующих примерах показано, как выполнить отладку некоторых распространенных сценариев:

Я не могу определить, использует ли мое приложение выделенный шлюз

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

Я не могу определить, попадают ли мои запросы в интегрированный кэш

Щелкните IntegratedCacheItemHitRate и IntegratedCacheQueryHitRate. Если оба из этих значений равны нулю, запросы не попадают в интегрированный кэш. Убедитесь, что вы используете выделенный шлюз строка подключения, подключаетесь к режиму шлюза и используете сеанс или в конечном итоге согласованность.

Я хочу определить, является ли размер выделенного шлюза слишком малым

Щелкните IntegratedCacheItemHitRate и IntegratedCacheQueryHitRate. Высокие значения (например, предыдущие 0.7-0.8) являются хорошим признаком того, что выделенный шлюз достаточно велик.

Если у IntegratedCacheItemHitRate или IntegratedCacheQueryHitRate малое значение, проверьте IntegratedCacheEvictedEntriesSize. Если значение IntegratedCacheEvictedEntriesSize высокое, это может означать, что будет полезен больший размер выделенного шлюза. Вы можете поэкспериментировать, увеличивая размер выделенного шлюза и сравнивая новые значения IntegratedCacheItemHitRate и IntegratedCacheQueryHitRate. Если более крупный выделенный шлюз не улучшает IntegratedCacheItemHitRate или IntegratedCacheQueryHitRate, возможно, операции чтения просто повторяются недостаточно часто, чтобы интегрированный кэш мог оказать заметное влияние.

Я хочу определить, является ли выделенный шлюз слишком большим

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

Если большая часть данных вытесняется из кэша из-за превышения MaxIntegratedCacheStaleness, а не LRU, возможно, ваш кэш больше, чем требуется. Если суммарное значение IntegratedCacheItemExpirationCount и IntegratedCacheQueryExpirationCount почти достигает значения IntegratedCacheEvictedEntriesSize, вы можете попробовать уменьшить размер выделенного шлюза и сравнить показатели производительности.

Мне нужно понять, требуются ли дополнительные узлы выделенного шлюза.

В некоторых случаях, если задержка неожиданно высока, могут понадобиться дополнительные выделенные узлы шлюза, а не более крупные узлы. По значениям DedicatedGatewayCPUUsage и DedicatedGatewayMemoryUsage можно оценить, поможет ли увеличение числа узлов выделенного шлюза сократить задержку. Рекомендуем учитывать, что все экземпляры интегрированного кэша полностью независимы друг от друга, а значит, добавление дополнительных выделенных узлов шлюза не поможет уменьшить IntegratedCacheEvictedEntriesSize. Однако добавление дополнительных узлов улучшает объем запросов, который может обрабатывать выделенный кластер шлюза.

Следующие шаги

• Часто задаваемые вопросы об интегрированном кэше Azure Cosmos DB
• Настройка интегрированного кэша Azure Cosmos DB
• Общие сведения о выделенном шлюзе Azure Cosmos DB
• Вы пытаетесь выполнить планирование емкости для миграции в Azure Cosmos DB? Для планирования ресурсов можно использовать сведения об имеющемся кластере базы данных.
  • Если вы знаете количество виртуальных ядер и серверов в существующем кластере базы данных, см. статью Преобразование количества виртуальных ядер или виртуальных ЦПУ в нереляционной базе данных в Azure Cosmos DB RU/s
  • Если вы знаете типичные скорости запросов для текущей рабочей нагрузки базы данных, см. статью "Оценка RU/s с помощью планировщика емкости Azure Cosmos DB.