Compartilhar via

Perguntas frequentes sobre o cache integrado do Azure Cosmos DB

  • Artigo

APLICA-SE A: NoSQL

O cache integrado do Azure Cosmos DB é um cache em memória integrado ao Azure Cosmos DB. Este artigo responde a perguntas frequentes sobre o cache integrado do Azure Cosmos DB.

Perguntas frequentes

Por que o cache integrado exige um gateway dedicado?

Se você se conectou ao Azure Cosmos DB usando o modo de gateway, usou o gateway padrão. Embora o back-end do Azure Cosmos DB (a produtividade e o armazenamento provisionados) tenha capacidade dedicada por contêiner, o gateway padrão é compartilhado entre muitos clientes. É prático para muitos clientes compartilhar um gateway padrão, pois os recursos de computação consumidos por cliente individual são mínimos. Como o cache integrado é específico da sua conta do Azure Cosmos DB e exige CPU e memória significativas, ele exige nós de gateway dedicados.

O que é um gateway dedicado?

Um gateway dedicado é a computação do lado do servidor que é um front-end para os dados em uma conta do Azure Cosmos DB. Quando você conecta ao ponto de extremidade de gateway dedicado usando o modo gateway, o aplicativo envia uma solicitação para o gateway dedicado, que, em seguida, encaminha a solicitação para diferentes partições de back-end. Há suporte para o uso do modo direto com o gateway dedicado, mas essas solicitações não usarão o cache integrado.

O uso do gateway dedicado oferece outros benefícios de desempenho em relação ao uso do gateway padrão?

Em geral, as solicitações encaminhadas pelo gateway dedicado terão uma latência ligeiramente menor e mais consistente do que as solicitações encaminhadas pelo gateway padrão. Até mesmo as solicitações que não usam o cache integrado ainda terão uma latência um pouco menor do que o gateway padrão.

Que tipo de latência devo esperar do cache integrado?

Uma solicitação atendida pelo cache integrado é rápida porque os dados armazenados em cache são armazenados na memória no gateway dedicado, não no back-end.

Para leituras de ponto armazenado em cache, espera-se uma latência média de 2 a 4 ms. Para consultas armazenadas em cache, a latência depende da consulta. O cache de consulta funciona armazenando em cache a resposta do mecanismo de consulta de uma consulta específica. Em seguida, essa resposta é enviada novamente ao lado do cliente para o SDK para processamento. Para consultas simples, o mínimo de trabalho no SDK é necessário, e as latências de 2 a 4 ms são típicas. No entanto, consultas mais complexas com GROUP BY ou DISTINCT exigem mais processamento no SDK. Portanto, a latência pode ser maior, mesmo com o cache de consulta.

Se você se conectava ao Azure Cosmos DB com o modo direto e alternava para a conexão com o gateway dedicado, talvez observe um pequeno aumento de latência em algumas solicitações. O uso do modo de gateway exige que uma solicitação seja enviada ao gateway (nesse caso, o gateway dedicado) e roteada adequadamente para o back-end. O modo direto, como o nome sugere, permite que o cliente se comunique diretamente com o back-end, removendo um salto extra. Não há nenhum SLA de latência para solicitações que usam o gateway dedicado.

Se o seu aplicativo usava o modo direto, as vantagens de latência do cache integrado são significativas apenas nos seguintes cenários:

  • Latência de leitura de ponto para itens grandes (> acima de 16 KB)
  • RU alta ou consultas complexas

Se o seu aplicativo usava o modo de gateway com o gateway padrão, o cache integrado oferece reduções na latência em quase todos os cenários.

O SLA de disponibilidade do Azure Cosmos DB se estende ao gateway dedicado e ao cache integrado?

Para cenários que exigem alta disponibilidade e devem estar cobertos pelo SLA de disponibilidade do Azure Cosmos DB, você deve provisionar pelo menos três nós de gateway dedicados. Por exemplo, se um nó de gateway dedicado for necessário em produção, você deverá provisionar dois nós de gateway dedicado adicionais para considerar o tempo de inatividade ou as interrupções possíveis. Se apenas um nó de gateway dedicado for provisionado, você perderá temporariamente a disponibilidade nesses cenários. Além disso, verifique se o gateway dedicado tem nós suficientes para atender à carga de trabalho.

No momento, o cache integrado só está disponível para a API para NoSQL. Vocês pretendem liberá-lo para outras APIs também?

A expansão do cache integrado além da API para NoSQL está planejada no roteiro de longo prazo, mas não está no escopo inicial do cache integrado.

A qual consistência o cache integrado dá suporte?

O cache integrado dá suporte a consistência eventual e a de sessão. Você também pode configurar o opcional MaxIntegratedCacheStaleness, que coloca um limite superior em dados armazenados em cache.

Próximas etapas