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 aumenta. O cache integrado é fácil de ser configurado, e você não precisa gastar tempo escrevendo um código personalizado para a invalidação de cache ou o gerenciamento da infraestrutura de back-end. O cache integrado usa o gateway dedicado na 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 na 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 no gateway dedicado. O cache integrado tem duas partes:

• Um cache de item para leituras de ponto
• Um cache de consulta para consultas

O cache integrado é um cache de leitura e gravação com uma política de remoção LRU (menos utilizado recentemente). O cache de item e os caches de consulta compartilham a capacidade no cache integrado, e a política de remoção LRU se aplica a ambos. Os dados são removidos do cache com base em quando foram usados pela primeira vez, independentemente de se tratar de um ponto de leitura ou consulta. Os dados armazenados em cache em cada nó dependem dos dados gravados ou lidos recentemente através desse nó específico. Em outras palavras, se um item ou uma consulta for armazenado em cache em um nó, ele não será necessariamente armazenado em cache nos outros.

Cargas de trabalho que se beneficiam do cache integrado

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

As leituras de pontos e consultas que atingem o cache integrado têm uma taxa de RU de 0. As ocorrências no 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 encaixam nas características a seguir devem avaliar se o cache integrado ajuda a reduzir os custos:

• Cargas de trabalho com uso intenso de leitura
• Excesso de leituras de ponto repetidas em itens grandes
• Excesso de consultas repetidas com RU alta
• Chave de partição quente para leituras

O maior fator na economia esperada é o grau em que as leituras se repetem. Se sua carga de trabalho executar consistentemente as mesmas leituras de ponto ou consultas em um curto período, ela será um excelente candidato para o cache integrado. Ao usá-lo para leituras repetidas, você só usa RUs na primeira leitura. As leituras subsequentes roteadas através do mesmo nó de gateway dedicado (dentro da janela MaxIntegratedCacheStaleness e se os dados não tiverem sido removidos) não usam taxa de transferência.

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

• Cargas de trabalho com uso intenso de gravação
• Leituras de ponto ou consultas raramente repetidas
• Cargas de trabalho lendo o feed de alterações

Cache de item

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

Preenchimento do cache de item

• As novas gravações, atualizações e exclusões são preenchidas automaticamente no cache do item do nó pelo qual a solicitação é roteada
• Itens de solicitações de leitura de ponto 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 do item
• Solicitações de leitura para vários itens, como ReadMany, preenchem o cache de consulta como um conjunto, em vez do cache de item como itens individuais
• As solicitações que fazem parte de um lote transacional ou modo em massa não preenchem o cache do item

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

Como cada nó tem um cache independente, é possível que os itens sejam invalidados ou removidos do 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:

• Atualização ou exclusão de item
• LRU (menos utilizado recentemente)
• Tempo de retenção de cache (em outras palavras, o MaxIntegratedCacheStaleness)

Cache de consulta

O cache de consultas é usado para armazenar consultas em cache. O cache da consulta transforma uma consulta em uma pesquisa de chave/valor em que 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, apenas armazena a pesquisa de chave/valor de cada consulta. Os resultados da consulta são armazenados como um conjunto e o cache não acompanha os itens individuais. Um determinado item pode ser armazenado várias vezes no cache de consulta se ele 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 desatualização máxima do cache integrado da consulta seja alcançada e a consulta seja atendida pelo banco de dados de back-end.

Preenchimento do cache de consulta

• Se o cache não tiver um resultado nessa consulta (perda 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 dela
• Consultas com a mesma forma, mas com parâmetros ou opções de solicitação diferentes que afetam os resultados (por exemplo, contagem máxima de itens) são armazenadas como seu próprio par chave/valor
• Solicitações de leitura para vários itens, como ReadMany, preenchem o cache de consulta. Os resultados do 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 se baseia no nó pelo qual a solicitação foi roteada. É possível que as consultas sejam removidas ou atualizadas em um nó e não nos outros.

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

Como trabalhar com o cache de consulta

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

O cache da consulta armazena automaticamente os tokens de continuação da 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 taxa de RU de 0. Se as páginas subsequentes dos resultados da consulta exigirem execução no back-end, elas terão um token de continuação da página anterior para que possam evitar a duplicação de trabalhos anteriores.

Consistência do cache integrado

O cache integrado dá suporte a solicitações de leitura apenas com consistência eventual e de sessão. Se uma leitura tiver um prefixo consistente, uma desatualização limitada ou uma consistência forte, ela ignorará o cache integrado e será fornecida a partir do back-end.

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

Coerência de sessão

Consistência da sessão é o nível de consistência mais amplamente utilizado nas contas do Azure Cosmos DB de região única e distribuídas globalmente. Com a consistência da sessão, as 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 encargos de RU. Isto 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

A MaxIntegratedCacheStaleness é a desatualização máxima aceitável para leituras e consultas de ponto em cache, independentemente da consistência selecionada. A MaxIntegratedCacheStaleness é configurável no nível da solicitação. Por exemplo, se você definir um MaxIntegratedCacheStaleness de 2 horas, sua solicitação retornará somente os dados armazenados em cache se os dados tiverem menos de 2 horas de idade. Para aumentar a probabilidade de leituras repetidas utilizando o cache integrado, você deve definir a MaxIntegratedCacheStaleness para o máximo possível de seus requisitos de negócios.

O MaxIntegratedCacheStaleness, quando configurado em uma solicitação que acaba preenchendo o cache, não afeta por quanto tempo essa solicitação é armazenada em cache. MaxIntegratedCacheStaleness impõe consistência quando você tenta ler dados armazenados em cache. Não há 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 um valor MaxIntegratedCacheStaleness menor do que a idade da entrada no cache atual.

Essa é uma melhoria em relação ao funcionamento da maioria dos caches e permite as seguintes outras personalizações:

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

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

Saiba como 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 configuradas com a cadeia de conexão de gateway dedicada passam pelo cache integrado e assumem o espaço em cache. Você pode controlar quais itens e consultas são armazenados em cache com a opção de solicitação de cache integrada de bypass. Essa opção de solicitação é útil para gravações de item 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 roteada por meio do gateway dedicado. Essas solicitações são atendidas nas RUs de back-end e de custo.

Aprenda a ignorar o cache integrado.

Métricas

É útil monitorar algumas métricas importantes DedicatedGateway e IntegratedCache com relação ao cache integrado. Para saber mais sobre essas métricas, consulte Métricas com suporte para Microsoft.DocumentDB/DatabaseAccounts.

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

As métricas são uma média, uma máxima ou a 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 de métrica de cada nó individual.

Solução de problemas comuns

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

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

Verifique a DedicatedGatewayRequests. Essa métrica inclui todas as solicitações que usam o gateway dedicado, independentemente de elas ocorrerem no cache integrado. Se o aplicativo usar o gateway padrão ou o modo direto com a cadeia de conexão original, você não observará uma mensagem de erro, mas as DedicatedGatewayRequests serão zero. Se o aplicativo usar o modo direto com a cadeia de conexão de gateway dedicada, talvez você ainda veja alguns DedicatedGatewayRequests.

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

Consulte a IntegratedCacheItemHitRate e IntegratedCacheQueryHitRate. Quando os dois valores são zero, isso significa que as solicitações não estão chegando ao cache integrado. Verifique se você está usando a cadeia de conexão do gateway dedicado, se está conectando-se ao modo de gateway e se está usando a consistência eventual ou de sessão.

Quero entender se meu gateway dedicado é muito pequeno

Consulte 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 IntegratedCacheQueryHitRate for baixo, examine o IntegratedCacheEvictedEntriesSize. Se o IntegratedCacheEvictedEntriesSize for alto, isso poderá significar que um tamanho maior de gateway dedicado será útil. Você pode experimentar aumentando o tamanho do gateway dedicado e comparando o novo IntegratedCacheItemHitRate e IntegratedCacheQueryHitRate. Se um gateway dedicado maior não melhorar o IntegratedCacheItemHitRate ou o 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 se ele é muito pequeno. Em geral, você deve começar com um gateway dedicado pequeno e lentamente aumentar o tamanho dele até que o IntegratedCacheItemHitRate e IntegratedCacheQueryHitRate pare de ser aprimorado. Em alguns casos, apenas uma das duas métricas de ocorrência de cache será importante, não as duas. Por exemplo, se sua carga de trabalho for principalmente consultas, em vez de leituras de ponto, o IntegratedCacheQueryHitRate será bem mais importante do que o IntegratedCacheItemHitRate.

Se a maioria dos dados for removida do cache devido a eles excederem o MaxIntegratedCacheStaleness, em vez do LRU, o cache poderá ser maior do que o necessário. Se IntegratedCacheItemExpirationCount e IntegratedCacheQueryExpirationCount combinados forem quase tão grandes quanto IntegratedCacheEvictedEntriesSize, você pode experimentar um tamanho de gateway dedicado menor e comparar o desempenho.

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

Em alguns casos, se a latência for inesperadamente alta, talvez você precise de mais nós de gateway dedicados em vez de nós maiores. Verifique o DedicatedGatewayCPUUsage e o DedicatedGatewayMemoryUsage para determinar se adicionar mais nós de gateway dedicados reduziria a latência. É bom lembrar 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. Porém, adicionar mais nós melhorará o volume de solicitação que o cluster de gateway dedicado pode manipular.

Próximas etapas

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