Cache integrado do Azure Cosmos DB - Visão geral

APLICA-SE A: NoSQL

O cache integrado do Azure Cosmos DB é um cache na memória que ajuda a garantir custos gerenciáveis e baixa latência à medida que o volume de solicitações cresce. O cache integrado é fácil de configurar e você não precisa gastar tempo escrevendo código personalizado para invalidação de cache ou gerenciamento de infraestrutura de back-end. O cache integrado usa o gateway dedicado em sua conta do Azure Cosmos DB. Ao provisionar seu gateway dedicado, você pode escolher o número de nós e o tamanho do nó com base no número de núcleos e memória necessários para sua carga de trabalho. Cada nó de gateway dedicado tem um cache integrado separado dos outros.

Um cache integrado é configurado automaticamente dentro do gateway dedicado. O cache integrado tem duas partes:

• Um cache de itens para leituras pontuais
• Um cache de consulta para consultas

O cache integrado é um cache de leitura e gravação com uma política de remoção LRU (Least Recently Used). O cache de itens e os caches de consulta compartilham a mesma capacidade dentro do cache integrado e a política de remoção LRU se aplica a ambos. Os dados são removidos do cache estritamente com base em quando foram usados menos recentemente, independentemente de ser uma leitura pontual ou consulta. Os dados armazenados em cache dentro de cada nó dependem dos dados que foram recentemente gravados ou lidos através desse nó específico. Se um item ou consulta é armazenado em cache em um nó, ele não é necessariamente armazenado em cache nos outros.

Cargas de trabalho que se beneficiam do cache integrado

O principal objetivo do cache integrado é reduzir os custos para cargas de trabalho de leitura pesada. A baixa latência, embora útil, não é o principal benefício do cache integrado porque o Azure Cosmos DB já é rápido sem cache.

As leituras de pontos e consultas que atingem o cache integrado têm uma carga de RU de 0. Os acertos de cache têm um custo por operação muito menor do que as leituras do banco de dados de back-end.

As cargas de trabalho que se ajustam às seguintes características devem avaliar se o cache integrado ajuda a reduzir os custos:

• Cargas de trabalho de leitura pesada
• Muitas leituras pontuais repetidas em itens grandes
• Muitas consultas repetidas de alta RU
• Tecla de partição quente para leituras

O maior fator para a poupança esperada é o grau em que as leituras se repetem. Se sua carga de trabalho executa consistentemente as mesmas leituras ou consultas pontuais em um curto período de tempo, é um ótimo candidato para o cache integrado. Ao usar o cache integrado para leituras repetidas, você usa apenas RUs para a primeira leitura. As leituras subsequentes roteadas através do mesmo nó de gateway dedicado (dentro da MaxIntegratedCacheStaleness janela e se os dados não tiverem sido removidos) não usam a taxa de transferência.

Algumas cargas de trabalho não devem considerar o cache integrado, incluindo:

• Cargas de trabalho pesadas de gravação
• Raramente repetidas leituras pontuais ou consultas
• Cargas de trabalho lendo o feed de alterações

Cache de itens

O cache de itens é usado para leituras de pontos (pesquisas de chave/valor com base na ID do item e na chave de partição).

Preenchendo o cache de itens

• Novas gravações, atualizações e exclusões são preenchidas automaticamente no cache de itens do nó pelo qual a solicitação é roteada
• Os itens de solicitações de leitura pontual em que o item ainda não está no cache (perda de cache) do nó pelo qual a solicitação é roteada são adicionados ao cache de itens
• As solicitações de leitura para vários itens, como ReadMany, preenchem o cache de consulta como um conjunto em vez do cache de itens como itens individuais
• As solicitações que fazem parte de um lote transacional ou no modo em massa não preenchem o cache de itens

Invalidação e remoção do cache de itens

Como cada nó tem um cache independente, é possível que os itens sejam invalidados ou removidos no cache de um nó e não dos outros. Os itens no cache de um determinado nó são invalidados e removidos com base nos critérios abaixo:

• Atualizar ou excluir item
• Menos recentemente usado (LRU)
• Tempo de retenção de cache (em outras palavras, o MaxIntegratedCacheStaleness)

Cache de consultas

O cache de consultas é usado para armazenar consultas em cache. O cache de consulta transforma uma consulta em uma pesquisa de chave/valor, onde a chave é o texto da consulta e o valor são os resultados da consulta. O cache integrado não tem um mecanismo de consulta, ele apenas armazena a pesquisa de chave/valor para cada consulta. Os resultados da consulta são armazenados como um conjunto e o cache não controla itens individuais. Um determinado item pode ser armazenado no cache de consultas várias vezes se aparecer no conjunto de resultados de várias consultas. As atualizações dos itens subjacentes não são refletidas nos resultados da consulta, a menos que a obsolescência máxima do cache integrado para a consulta seja atingida e a consulta seja atendida a partir do banco de dados de back-end.

Preenchendo o cache de consulta

• Se o cache não tiver um resultado para essa consulta (falha de cache) no nó pelo qual foi roteado, a consulta será enviada para o back-end. Depois que a consulta for executada, o cache armazenará os resultados dessa consulta
• Consultas com a mesma forma, mas parâmetros diferentes ou opções de solicitação que afetam os resultados (ex. max contagem de itens) são armazenadas como seu próprio par chave/valor
• As solicitações de leitura para vários itens, como ReadMany, preenchem o cache de consulta. Os resultados ReadMany são armazenados como um conjunto, e as solicitações com entradas diferentes serão armazenadas como seu próprio par chave/valor

Remoção do cache de consulta

A remoção do cache de consulta é baseada no nó pelo qual a solicitação foi roteada. É possível que as consultas possam ser removidas ou atualizadas em um nó e não nos outros.

• Menos recentemente usado (LRU)
• Tempo de retenção de cache (em outras palavras, o MaxIntegratedCacheStaleness)

Trabalhando com o cache de consulta

Você não precisa de código especial ao trabalhar com o cache de consultas, mesmo que suas consultas tenham várias páginas de resultados. As práticas recomendadas e o código para paginação de consulta são os mesmos, independentemente de sua consulta atingir o cache integrado ou ser executada no mecanismo de consulta de back-end.

O cache de consultas armazena automaticamente em cache tokens de continuação de consulta quando aplicável. Se você tiver uma consulta com várias páginas de resultados, todas as páginas armazenadas no cache integrado terão uma cobrança de RU de 0. Se as páginas subsequentes dos resultados da consulta exigirem a execução de back-end, elas terão um token de continuação da página anterior para evitar a duplicação do trabalho anterior.

Consistência de cache integrada

O cache integrado suporta solicitações de leitura apenas com sessão e consistência eventual. Se uma leitura tiver prefixo consistente, obsoletismo delimitado ou consistência forte, ela ignorará o cache integrado e será servida a partir do back-end.

A maneira mais fácil de configurar a sessão ou a consistência eventual para todas as leituras é defini-la no nível da conta. No entanto, se você quiser que apenas algumas de suas leituras tenham uma consistência específica, você também pode configurar a consistência no nível da solicitação.

Consistência de sessão

A consistência de sessão é o nível de consistência mais usado para contas do Azure Cosmos DB distribuídas globalmente e de região única. Com consistência de sessão, sessões de cliente único podem ler suas próprias gravações. Qualquer leitura com consistência de sessão que não tenha um token de sessão correspondente incorrerá em cobranças de RU. Isso inclui a primeira solicitação para um determinado item ou consulta quando o aplicativo cliente é iniciado ou reiniciado, a menos que você passe explicitamente um token de sessão válido. Os clientes fora da sessão que executam gravações verão uma eventual consistência quando estiverem usando o cache integrado.

MaxIntegratedCacheStaleness

O MaxIntegratedCacheStaleness é o atraso máximo aceitável para leituras e consultas de pontos armazenados em cache, independentemente da consistência selecionada. O MaxIntegratedCacheStaleness é configurável no nível da solicitação. Por exemplo, se você definir um MaxIntegratedCacheStaleness de 2 horas, sua solicitação só retornará dados armazenados em cache se os dados tiverem menos de 2 horas. Para aumentar a probabilidade de leituras repetidas utilizando o cache integrado, você deve definir o MaxIntegratedCacheStaleness mais alto que seus requisitos de negócios permitam.

O MaxIntegratedCacheStaleness, quando configurado em uma solicitação que acaba preenchendo o cache, não afeta por quanto tempo essa solicitação fica armazenada em cache. MaxIntegratedCacheStaleness Impõe consistência quando você tenta ler dados armazenados em cache. Não há nenhuma configuração global de TTL ou retenção de cache, portanto, os dados só são removidos do cache se o cache integrado estiver cheio ou se uma nova leitura for executada com uma idade inferior MaxIntegratedCacheStaleness à da entrada em cache atual.

Esta é uma melhoria em relação à forma como a maioria dos caches funciona e permite as seguintes outras personalizações:

• Você pode definir diferentes requisitos de obsoletos para cada ponto lido ou consulta
• Clientes diferentes, mesmo que executem o mesmo ponto de leitura ou consulta, podem configurar valores diferentes MaxIntegratedCacheStaleness
• Se você quiser modificar a consistência de leitura para dados armazenados em cache, a alteração MaxIntegratedCacheStaleness terá um efeito imediato na consistência de leitura

Para entender melhor o MaxIntegratedCacheStaleness parâmetro, considere o seguinte exemplo:

Aprenda a configurar o MaxIntegratedCacheStaleness.

Ignorar o cache integrado

O cache integrado tem uma capacidade de armazenamento limitada determinada pelo SKU de gateway dedicado provisionado. Por padrão, todas as solicitações de clientes configurados com a cadeia de conexão de gateway dedicada passam pelo cache integrado e ocupam espaço de cache. Você pode controlar quais itens e consultas são armazenados em cache com a opção de solicitação de cache integrado ignorar. Essa opção de solicitação é útil para gravações de itens ou solicitações de leitura que não devem ser repetidas com frequência. Ignorar o cache integrado para itens com acesso pouco frequente economiza espaço em cache para itens com mais repetições, aumentando o potencial de economia de RU e reduzindo as remoções. As solicitações que ignoram o cache ainda são roteadas pelo gateway dedicado. Essas solicitações são atendidas a partir do back-end e custam RUs.

Aprenda a ignorar o cache integrado.

Métricas

É útil monitorar algumas chaves DedicatedGateway e IntegratedCache métricas para o cache integrado. Para saber mais sobre essas métricas, consulte Métricas suportadas para Microsoft.DocumentDB/DatabaseAccounts.

Todas as métricas existentes estão disponíveis, por padrão, em Métricas no portal do Azure (não Métricas clássicas):

As métricas são média, máxima ou soma em todos os nós de gateway dedicados. Por exemplo, se você provisionar um cluster de gateway dedicado com cinco nós, as métricas refletirão o valor agregado em todos os cinco nós. Não é possível determinar os valores métricos para cada nó individual.

Resolução de problemas comuns

Os exemplos abaixo mostram como depurar alguns cenários comuns:

Não consigo saber se meu aplicativo está usando o gateway dedicado

Verifique o DedicatedGatewayRequestsarquivo . Essa métrica inclui todas as solicitações que usam o gateway dedicado, independentemente de atingirem o cache integrado. Se seu aplicativo usa o gateway padrão ou o modo direto com sua cadeia de conexão original, você não verá uma mensagem de erro, mas o DedicatedGatewayRequests será zero. Se seu aplicativo usa o modo direto com sua cadeia de conexão de gateway dedicada, você ainda pode ver alguns DedicatedGatewayRequests.

Não consigo saber se minhas solicitações estão atingindo o cache integrado

Verifique o IntegratedCacheItemHitRate e IntegratedCacheQueryHitRate. Se ambos os valores forem zero, as solicitações não atingirão o cache integrado. Verifique se você está usando a cadeia de conexão de gateway dedicada, conectando-se com o modo de gateway e se está usando a consistência de sessão ou eventual.

Quero entender se meu gateway dedicado é muito pequeno

Verifique o IntegratedCacheItemHitRate e IntegratedCacheQueryHitRate. Valores altos (por exemplo, acima de 0,7-0,8) são um bom sinal de que o gateway dedicado é grande o suficiente.

Se o IntegratedCacheItemHitRate ou IntegratedCacheQueryHitRateestiver baixo, olhe para o IntegratedCacheEvictedEntriesSize. Se o for IntegratedCacheEvictedEntriesSize alto, isso pode significar que um tamanho de gateway dedicado maior seria benéfico. Você pode experimentar aumentando o tamanho do gateway dedicado e comparando o novo IntegratedCacheItemHitRate e IntegratedCacheQueryHitRateo . Se um gateway dedicado maior não melhorar o IntegratedCacheItemHitRate ou IntegratedCacheQueryHitRate, é possível que as leituras simplesmente não se repitam o suficiente para que o cache integrado seja impactante.

Quero entender se meu gateway dedicado é muito grande

É mais difícil medir se um gateway dedicado é muito grande do que medir se um gateway dedicado é muito pequeno. Em geral, você deve começar pequeno e aumentar lentamente o tamanho do gateway dedicado até que o IntegratedCacheItemHitRate e IntegratedCacheQueryHitRate parar de melhorar. Em alguns casos, apenas uma das duas métricas de acerto de cache será importante, não ambas. Por exemplo, se sua carga de trabalho for principalmente consultas, em vez de leituras pontuais, o IntegratedCacheQueryHitRate é muito mais importante do que o IntegratedCacheItemHitRate.

Se a maioria dos dados for removida do cache devido a exceder o , em vez de LRU, o cache poderá ser maior do que o MaxIntegratedCacheStalenessnecessário. Se IntegratedCacheItemExpirationCount e IntegratedCacheQueryExpirationCount combinado são quase tão grandes quanto IntegratedCacheEvictedEntriesSize, você pode experimentar com um tamanho de gateway dedicado menor e comparar o desempenho.

Quero entender se preciso adicionar mais nós de gateway dedicados

Em alguns casos, se a latência for inesperadamente alta, você pode precisar de mais nós de gateway dedicados em vez de nós maiores. Verifique o e DedicatedGatewayMemoryUsage para determinar se a adição de mais nós de gateway dedicados reduziria a DedicatedGatewayCPUUsage latência. É bom ter em mente que, como todas as instâncias do cache integrado são independentes umas das outras, adicionar mais nós de gateway dedicados não reduzirá o IntegratedCacheEvictedEntriesSize. No entanto, adicionar mais nós melhorará o volume de solicitações que seu cluster de gateway dedicado pode lidar.

Próximos passos

• Perguntas frequentes sobre cache integrado
• Configurar o cache integrado
• Gateway dedicado
• Tentando fazer o planejamento de capacidade para uma migração para o Azure Cosmos DB? Você pode usar informações sobre seu cluster de banco de dados existente para planejamento de capacidade.
  • Se tudo o que você sabe é o número de vCores e servidores em seu cluster de banco de dados existente, leia sobre como estimar unidades de solicitação usando vCores ou vCPUs
  • Se você souber as taxas de solicitação típicas para sua carga de trabalho de banco de dados atual, leia sobre como estimar unidades de solicitação usando o planejador de capacidade do Azure Cosmos DB