Práticas recomendadas para o SDK Java do Azure Cosmos DB

  • Artigo

APLICA-SE A: NoSQL

Este artigo apresenta as práticas recomendadas para usar o SDK Java do Azure Cosmos DB. Seguir essas práticas ajudará a melhorar sua latência, disponibilidade e aumentar o desempenho geral.

Lista de Verificação

Verificado Tópico Detalhes/Links
Versão do SDK Sempre usando a versão mais recente do SDK do Azure Cosmos DB disponível para um desempenho ideal.
Cliente Singleton Use uma única instância do durante o tempo de vida do CosmosClient seu aplicativo para obter um melhor desempenho.
Regiões Certifique-se de executar seu aplicativo na mesma região do Azure que sua conta do Azure Cosmos DB, sempre que possível para reduzir a latência. Habilite de 2 a 4 regiões e replique suas contas em várias regiões para obter a melhor disponibilidade. Para cargas de trabalho de produção, habilite o failover gerenciado por serviços. Na ausência dessa configuração, a conta sofrerá perda de disponibilidade de gravação durante toda a duração da interrupção da região de gravação, pois o failover manual não terá êxito devido à falta de conectividade da região. Para saber como adicionar várias regiões usando o Java SDK , visite aqui
Disponibilidade e failovers Defina as preferredRegions no SDK v4. Durante os failovers, as operações de gravação são enviadas para a região de gravação atual e todas as leituras são enviadas para a primeira região da sua lista de regiões preferidas. Para obter mais informações sobre a mecânica de failover regional, consulte o guia de solução de problemas de disponibilidade.
CPU Você pode ter problemas de conectividade/disponibilidade devido à falta de recursos na máquina cliente. Monitore a utilização da CPU em nós que executam o cliente do Azure Cosmos DB e aumente ou diminua a escala se o uso for muito alto.
Alojamento Para os casos mais comuns de cargas de trabalho de produção, é altamente recomendável usar pelo menos VMs de memória de 4 núcleos e 8 GB sempre que possível.
Modos de conectividade Use o modo Direto para obter o melhor desempenho. Para obter instruções sobre como fazer isso, consulte a documentação do SDK V4.
Rede Se estiver usando uma máquina virtual para executar seu aplicativo, habilite a Rede Acelerada em sua VM para ajudar com gargalos devido ao alto tráfego e reduzir a latência ou o desvio da CPU. Você também pode querer considerar o uso de uma máquina virtual mais avançada onde o uso máximo da CPU é inferior a 70%.
Exaustão Portuária Efémera Para conexões esparsas ou esporádicas, recomendamos definir o idleEndpointTimeout para um valor mais alto. A idleEndpointTimeout propriedade em DirectConnectionConfig ajuda que controlar o tempo que as conexões não utilizadas são fechadas. Isso reduzirá o número de conexões não utilizadas. Por padrão, as conexões ociosas com um ponto de extremidade são mantidas abertas por 1 hora. Se não houver solicitações para um ponto de extremidade específico para a duração do tempo limite do ponto de extremidade ocioso, o cliente direto fechará todas as conexões com esse ponto de extremidade para economizar recursos e custo de E/S.
Use o Agendador Apropriado (Evite roubar threads do Event loop IO Netty) Evite bloquear chamadas: .block(). Toda a pilha de chamadas é assíncrona para se beneficiar de padrões de API assíncronos e do uso de threading e agendadores apropriados
Tempos limite de ponta a ponta Para obter tempos limite de ponta a ponta, implemente a política de tempo limite de ponta a ponta no Java SDK. Para obter mais detalhes sobre tempos limite com o Azure Cosmos DB , visite aqui
Repetir a Lógica Um erro transitório é um erro que tem uma causa subjacente que logo se resolve. As aplicações que se ligam à base de dados devem ser criadas para esperar estes erros transitórios. Para manipulá-los, implemente a lógica de repetição em seu código em vez de apresentá-los aos usuários como erros de aplicativo. O SDK tem lógica interna para lidar com essas falhas transitórias em solicitações que podem ser repetidas, como operações de leitura ou consulta. O SDK não tentará novamente em gravações para falhas transitórias, pois as gravações não são idempotentes. O SDK permite que os usuários configurem a lógica de repetição para limitações. Para obter detalhes sobre quais erros repetir em visite aqui
Armazenamento em cache de nomes de banco de dados/coleção Recupere os nomes de seus bancos de dados e contêineres da configuração ou armazene-os em cache na inicialização. Chamadas como CosmosAsyncDatabase#read() ou CosmosAsyncContainer#read() resultarão em chamadas de metadados para o serviço, que consomem a partir do limite de RU reservado pelo sistema. createDatabaseIfNotExists() também só deve ser usado uma vez para configurar o banco de dados. De um modo geral, estas operações devem ser realizadas com pouca frequência.
Consultas paralelas O SDK do Azure Cosmos DB dá suporte à execução de consultas em paralelo para melhor latência e taxa de transferência em suas consultas. Recomendamos definir a maxDegreeOfParallelism propriedade dentro do CosmosQueryRequestsOptions para o número de partições que você tem. Se você não estiver ciente do número de partições, defina o valor para -1 que lhe dará a melhor latência. Além disso, defina o número esperado de resultados retornados para limitar o maxBufferedItemCount número de resultados pré-buscados.
Backoffs de testes de desempenho Ao executar testes em seu aplicativo, você deve implementar backoffs em RetryAfter intervalos. Respeitar o backoff ajuda a garantir que você gastará uma quantidade mínima de tempo esperando entre as tentativas.
Indexação A política de indexação do Azure Cosmos DB também permite especificar quais caminhos de documento devem ser incluídos ou excluídos da indexação usando caminhos IndexingPolicy#getIncludedPaths() de indexação e IndexingPolicy#getExcludedPaths(). Certifique-se de excluir caminhos não utilizados da indexação para gravações mais rápidas. Para obter um exemplo sobre como criar índices usando o SDK , visite aqui
Tamanho do documento A cobrança de solicitação de uma operação especificada está diretamente correlacionada ao tamanho do documento. Recomendamos reduzir o tamanho de seus documentos, pois as operações em documentos grandes custam mais do que as operações em documentos menores.
Tamanho da Página Por padrão, os resultados da consulta são retornados em blocos de 100 itens ou 4 MB, o limite atingido primeiro. Se uma consulta retornar mais de 100 itens, aumente o tamanho da página para reduzir o número de viagens de ida e volta necessárias. O consumo de memória aumentará à medida que o tamanho da página aumentar.
Habilitando métricas de consulta Para registro adicional de suas execuções de consulta de back-end, siga as instruções sobre como capturar métricas de consulta SQL usando o Java SDK
Registro em log do SDK Use o log do SDK para capturar informações adicionais de diagnóstico e solucionar problemas de latência. Registre o CosmosDiagnostics no Java SDK para obter informações de diagnóstico mais detalhadas do Azure Cosmos DB para a solicitação atual ao serviço. Como exemplo de caso de uso, capture Diagnósticos em qualquer exceção e em operações concluídas se o CosmosDiagnostics#getDuration() for maior que um valor limite designado (ou seja, se você tiver um SLA de 10 segundos, capture diagnósticos quando getDuration()> 10 segundos). É aconselhável usar esses diagnósticos apenas durante os testes de desempenho. Para obter mais informações, siga o diagnóstico de captura no Java SDK
Evite usar caracteres especiais em identificadores Alguns caracteres são restritos e não podem ser usados em alguns identificadores: '/', '\', '?', '#'. A recomendação geral é não usar caracteres especiais em identificadores como nome do banco de dados, nome da coleção, ID do item ou chave de partição para evitar qualquer comportamento inesperado.

Práticas recomendadas ao usar o modo Gateway

As solicitações do Azure Cosmos DB são feitas por HTTPS/REST quando você usa o modo Gateway. Eles estão sujeitos ao limite de conexão padrão por nome de host ou endereço IP. Talvez seja necessário ajustar maxConnectionPoolSize para um valor diferente (de 100 a 1.000) para que a biblioteca de cliente possa usar várias conexões simultâneas com o Azure Cosmos DB. No Java v4 SDK, o valor padrão para GatewayConnectionConfig#maxConnectionPoolSize é 1000. Para alterar o valor, você pode definir GatewayConnectionConfig#maxConnectionPoolSize como um valor diferente.

Práticas recomendadas para cargas de trabalho com muita gravação

Para cargas de trabalho com cargas úteis de criação pesadas, defina a CosmosClientBuilder#contentResponseOnWriteEnabled() opção de solicitação como false. O serviço não retornará mais o recurso criado ou atualizado para o SDK. Normalmente, como o aplicativo tem o objeto que está sendo criado, ele não precisa do serviço para retorná-lo. Os valores de cabeçalho ainda estão acessíveis, como uma cobrança de solicitação. Desabilitar a resposta de conteúdo pode ajudar a melhorar o desempenho, porque o SDK não precisa mais alocar memória ou serializar o corpo da resposta. Ele também reduz o uso da largura de banda da rede para ajudar ainda mais o desempenho.

Próximos passos

Para saber mais sobre dicas de desempenho para Java SDK, consulte Dicas de desempenho para o Azure Cosmos DB Java SDK v4.

Para saber mais sobre como projetar seu aplicativo para dimensionamento e alto desempenho, consulte Particionamento e dimensionamento no Azure Cosmos DB.

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.