Partilhar 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 na memória que é incorporado ao Azure Cosmos DB. Este artigo responde a perguntas frequentes sobre o cache integrado do Azure Cosmos DB.

Perguntas mais frequentes

Por que o cache integrado requer 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 (sua taxa de transferência e 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, uma vez que os recursos de computação consumidos por cada cliente individual são mínimos. Como o cache integrado é específico para sua conta do Azure Cosmos DB e requer CPU e memória significativas, ele requer 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 dados em uma conta do Azure Cosmos DB. Quando você se conecta ao ponto de extremidade do gateway dedicado usando o modo de gateway, seu aplicativo envia uma solicitação para o gateway dedicado, que então roteia a solicitação para diferentes partições de back-end. O uso do modo direto com o gateway dedicado é suportado, 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 roteadas pelo gateway dedicado terão uma latência um pouco menor e mais consistente do que as solicitações roteadas pelo gateway padrão. 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, em vez de no back-end.

Para leituras de pontos armazenados em cache, você deve esperar uma latência mediana de 2 a 4 ms. Para consultas em cache, a latência depende da consulta. O cache de consultas funciona armazenando em cache a resposta do mecanismo de consulta para uma consulta específica. Essa resposta é então enviada de volta do lado do cliente para o SDK para processamento. Para consultas simples, é necessário um trabalho mínimo no SDK e latências medianas de 2 a 4 ms são típicas. 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ê estava se conectando anteriormente ao Azure Cosmos DB com o modo direto e alternava para se conectar com o gateway dedicado, poderá observar um ligeiro aumento de latência para algumas solicitações. Usar o modo de gateway requer que uma solicitação seja enviada para o gateway (neste caso, o gateway dedicado) e, em seguida, roteada adequadamente para o back-end. O modo direto, como o nome sugere, permite que o cliente se comunique diretamente com o backend, removendo um salto extra. Não há SLA de latência para solicitações que usam o gateway dedicado.

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

  • Latência de leitura pontual para itens grandes (> 16 KB)
  • RU alto ou consultas complexas

Se seu aplicativo usou anteriormente o modo de gateway com o gateway padrão, o cache integrado oferecerá 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 para serem cobertos pelo SLA de disponibilidade do Azure Cosmos DB, você deve provisionar pelo menos 3 nós de gateway dedicados. Por exemplo, se um nó de gateway dedicado for necessário na produção, você deverá provisionar dois nós de gateway dedicados adicionais para levar em conta possíveis períodos de inatividade, interrupções e atualizações. Se apenas um nó de gateway dedicado for provisionado, você perderá temporariamente a disponibilidade nesses cenários. Além disso, certifique-se de que seu gateway dedicado tenha nós suficientes para atender à sua carga de trabalho.

O cache integrado só está disponível para API para NoSQL no momento. Você está planejando lançá-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 está além do escopo inicial do cache integrado.

Que consistência é suportada pelo cache integrado?

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

Próximos passos