Share via

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

  • Статья

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

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

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

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

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

Примечание.

Хотите поделиться мнением о встроенном кэше? Нам очень интересно ваше мнение! Вы можете поделиться им непосредственно с командой разработчиков Azure Cosmos DB по адресу cosmoscachefeedback@microsoft.com

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Кэш запросов

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

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

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

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

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

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

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

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

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

Важно!

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

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

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

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

Примечание.

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

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

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

MaxIntegratedCacheStaleness

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

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

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

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

Примечание.

Минимальное MaxIntegratedCacheStaleness значение равно 0, а максимальное значение — 10 лет. Если не настроено явно, значение MaxIntegratedCacheStaleness по умолчанию — 5 минут.

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

Время Запросить Response
t = 0 с Выполнение запроса A с параметром MaxIntegratedCacheStaleness = 30 секунд Возвращает результаты из внутренней базы данных (с обычной стоимостью в ЕЗ) и заполняет кэш
t = 0 с Выполнение запроса Б с параметром MaxIntegratedCacheStaleness = 60 секунд Возвращает результаты из внутренней базы данных (с обычной стоимостью в ЕЗ) и заполняет кэш
t = 20 с Выполнение запроса A с параметром MaxIntegratedCacheStaleness = 30 секунд Возвращает результаты из интегрированного кэша (стоимость 0 ЕЗ)
t = 20 с Выполнение запроса Б с параметром MaxIntegratedCacheStaleness = 60 секунд Возвращает результаты из интегрированного кэша (стоимость 0 ЕЗ)
t = 40 с Выполнение запроса A с параметром MaxIntegratedCacheStaleness = 30 секунд Возвращает результаты из внутренней базы данных (с обычной стоимостью в ЕЗ) и обновляет кэш
t = 40 с Выполнение запроса Б с параметром MaxIntegratedCacheStaleness = 60 секунд Возвращает результаты из интегрированного кэша (стоимость 0 ЕЗ)
t = 50 с Выполнение запроса Б с параметром MaxIntegratedCacheStaleness = 20 секунд Возвращает результаты из внутренней базы данных (с обычной стоимостью в ЕЗ) и обновляет кэш

Как правильно настраивать MaxIntegratedCacheStaleness.

Обход интегрированного кэша (предварительная версия)

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

Узнайте, как обойти интегрированный кэш.

Метрики

Рекомендуется отслеживать некоторые ключевые метрики для интегрированного кэша. К этим метрикам относятся:

  • DedicatedGatewayCPUUsage — использование ЦП с типами функций Avg, Max и Min Aggregation для данных во всех узлах выделенного шлюза.
  • DedicatedGatewayAverageCPUUsage (не рекомендуется) — среднее использование ЦП во всех узлах выделенного шлюза.
  • DedicatedGatewayMaximumCPUUsage (не рекомендуется) — максимальное использование ЦП во всех узлах выделенного шлюза.
  • DedicatedGatewayMemoryUsage — использование памяти с типами функций Avg, Max и Min Aggregation для данных во всех узлах выделенного шлюза.
  • DedicatedGatewayAverageMemoryUsage (не рекомендуется) — среднее использование памяти во всех узлах выделенного шлюза.
  • DedicatedGatewayRequests — общее количество запросов к выделенному шлюзу во всех узлах выделенного шлюза.
  • IntegratedCacheEvictedEntriesSize — средний объем данных, вытесняемый из интегрированного кэша политикой наиболее давнего использования во всех узлах выделенного шлюза. Это значение не включает данные, истекшие из-за превышения MaxIntegratedCacheStaleness времени.
  • IntegratedCacheItemExpirationCount — среднее количество элементов, вытесненных из интегрированного кэша из-за превышения времени MaxIntegratedCacheStaleness для кэшированных результатов операций точечного чтения во всех узлах выделенного шлюза.
  • IntegratedCacheQueryExpirationCount — среднее количество запросов, вытесненных из интегрированного кэша из-за превышения времени MaxIntegratedCacheStaleness для кэшированных результатов запросов во всех узлах выделенного шлюза.
  • IntegratedCacheItemHitRate — доля операций точечного чтения, которые использовали интегрированный кэш (от общего числа операций точечного чтения, направленных через выделенный шлюз с согласованностью на уровне сеанса или согласованностью в конечном счете). Это средние значения по экземплярам интегрированного кэша во всех узлах выделенного шлюза.
  • IntegratedCacheQueryHitRate — доля запросов, которые использовали интегрированный кэш (от общего числа запросов, направленных через выделенный шлюз с согласованностью на уровне сеанса или согласованностью в конечном счете). Это средние значения по экземплярам интегрированного кэша во всех узлах выделенного шлюза.

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

Screenshot of the Azure portal that shows the location of integrated cache metrics.

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

Устранение распространенных проблем

В приведенных ниже примерах показано, как отлаживать некоторые распространенные сценарии.

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

См. 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. Но зато добавление новых узлов позволит улучшить объем запросов, которые может обрабатывать кластер выделенного шлюза.

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