Compartilhar via

Dicas de desempenho para o SDK do Python do Azure Cosmos DB

  • Artigo

APLICA-SE A: NoSQL

Importante

As dicas de desempenho neste artigo são apenas para o SDK do Python do Azure Cosmos DB. Consulte o Azure Cosmos DB Python SDK Leiame Notas de versão, Pacote (PyPI), Pacote (Conda) e guia de solução de problemas para obter mais informações.

O Azure Cosmos DB é um banco de dados distribuído rápido e flexível que pode ser dimensionado perfeitamente com garantia de latência e produtividade. Você não precisa fazer alterações importantes de arquitetura nem escrever um código complexo para dimensionar seu banco de dados com o Azure Cosmos DB. Aumentar e reduzir é tão fácil quanto fazer uma única chamada à API ou uma chamada ao método do SDK. No entanto, como o Azure Cosmos DB é acessado por meio de chamadas de rede, há otimizações do lado do cliente que podem ser feitas para obter o máximo desempenho ao usar o SDK do Python do Azure Cosmos DB.

Assim, se você estiver se perguntando "Como posso melhorar o desempenho do meu banco de dados?", considere as seguintes opções:

Rede

  • Coloque os clientes na mesma região do Azure para aumentar o desempenho

Quando possível, coloque aplicativos que chamam o Azure Cosmos DB na mesma região do banco de dados do Azure Cosmos DB. Para obter uma comparação aproximada, as chamadas para o Azure Cosmos DB na mesma região são concluídas de 1 a 2 ms, mas a latência entre a Costa Leste e a Oeste dos EUA é maior que >50 ms. Provavelmente, essa latência pode variar entre as solicitações dependendo da rota seguida pela solicitação conforme ela passa do cliente para o limite de datacenter do Azure. A menor latência possível é alcançada garantindo que o aplicativo de chamada está localizado na mesma região do Azure do ponto de extremidade do Azure Cosmos DB provisionado. Para obter uma lista de regiões disponíveis, consulte Regiões do Azure.

Ilustração da política de conexão do Azure Cosmos DB.

Um aplicativo que interage com uma conta do Azure Cosmos DB de várias regiões precisa configurar locais preferenciais para garantir que as solicitações sejam feitas para uma região posicionada.

Habilitar a rede acelerada para reduzir a latência e a tremulação da CPU

É recomendável que você siga as instruções para habilitar a Rede Acelerada na VM do Azure do Windows (selecione para obter instruções) ou Linux (selecione para obter instruções) para maximizar o desempenho (reduzir a latência e a variação da CPU).

Sem a rede acelerada, a E/S que transita entre a VM do Azure e outros recursos do Azure pode ser desnecessariamente encaminhada por meio de um host e um comutador virtual situados entre a VM e sua placa de rede. Ter o host e o comutador virtual embutidos no caminho de dados não apenas aumenta a latência e a tremulação no canal de comunicação, ele também rouba ciclos de CPU da VM. Com a rede acelerada, a VM interage diretamente com a NIC sem intermediários; todos os detalhes da diretiva de rede que estavam sendo manipulados pelo host e pelo comutador virtual agora são manipulados no hardware na NIC; o host e o comutador virtual são ignorados. Geralmente, você pode esperar uma latência mais baixa e uma taxa de transferência mais alta, bem como uma latência mais consistente e menor utilização da CPU quando você habilita a rede acelerada.

Limitações: a rede acelerada deve ter suporte no sistema operacional da VM e só pode ser habilitada quando a VM é interrompida e desalocada. A VM não pode ser implantada com o Azure Resource Manager. O Serviço de Aplicativo não tem a rede acelerada habilitada.

Confira as instruções do Windows e do Linux para obter mais detalhes.

Uso do SDK

  • Instalar o SDK mais recente

Os SDKs do Azure Cosmos DB estão constantemente sendo aprimorados para fornecer o melhor desempenho. Consulte as Notas sobre a versão do SDK do Azure Cosmos DB para determinar o SDK mais recente e analisar os aprimoramentos.

  • Use um cliente do Azure Cosmos DB singleton para obter o tempo de vida do aplicativo

Cada instância do cliente do Azure Cosmos DB tem um thread-safe e realiza um gerenciamento de conexão eficiente e o cache de endereço. Para permitir um gerenciamento eficiente da conexão e um melhor desempenho do cliente do Azure Cosmos DB, é recomendável usar uma única instância do cliente do Azure Cosmos DB durante todo o tempo de vida do aplicativo.

  • Ajuste as configurações de tempo limite e de repetição

As configurações de tempo limite e as políticas de repetição podem ser personalizadas com base nas necessidades do aplicativo. Consulte o documento configurações de tempo limite e de repetição para obter uma lista completa das configurações que podem ser personalizadas.

  • Use o nível de consistência mais baixo necessário para seu aplicativo

Quando você cria um CosmosClient, a consistência no nível da conta é usada se nenhuma for especificada na criação do cliente. Para obter mais informações sobre níveis de consistência, consulte o documento níveis de consistência.

  • Escalar horizontalmente sua carga de trabalho do cliente

Se você estiver testando em altos níveis da taxa de transferência, o aplicativo cliente poderá tornar-se o gargalo devido à limitação do computador na utilização da CPU ou da rede. Se você chegar a este ponto, poderá continuar aumentando a conta do Azure Cosmos DB ainda mais distribuindo seus aplicativos cliente entre vários servidores.

Uma boa regra geral é não exceder >50% de utilização de CPU em qualquer servidor para manter a latência baixa.

  • Limite de recursos de arquivos abertos do SO

Alguns sistemas Linux (como Red Hat) têm um limite superior no número de arquivos abertos e, portanto no número total de conexões. Execute o seguinte para exibir os limites atuais:

ulimit -a

O número de arquivos abertos (nofile) deve ser grande o suficiente para ter espaço para o tamanho do pool de conexão configurado e outros arquivos abertos pelo SO. Isso pode ser modificado para permitir um maior tamanho de pool de conexão.

Abra o arquivo limits.conf:

vim /etc/security/limits.conf

Adicione/modifique as linhas a seguir:

* - nofile 100000

Operações de consulta

Para operações de consulta, consulte as dicas de desempenho para consultas.

Política de indexação

  • Excluir caminhos não utilizados da indexação para ter gravações mais rápidas

A política de indexação do Azure Cosmos DB permite que você especifique quais caminhos de documento serão incluídos ou excluídos da indexação, aproveitando os Caminhos de Indexação (setIncludedPaths e setExcludedPaths). O uso dos caminhos de indexação pode oferecer um melhor desempenho de gravação e menor armazenamento de índices para os cenários nos quais os padrões da consulta são conhecidos com antecedência, pois os custos da indexação estão correlacionados diretamente com o número de caminhos exclusivos indexados. Por exemplo, o código a seguir mostra como incluir e excluir seções inteiras dos documentos (também conhecida como subárvore) da indexação usando o curinga "*".

container_id = "excluded_path_container"
indexing_policy = {
        "includedPaths" : [ {'path' : "/*"} ],
        "excludedPaths" : [ {'path' : "/non_indexed_content/*"} ]
        }
db.create_container(
    id=container_id,
    indexing_policy=indexing_policy,
    partition_key=PartitionKey(path="/pk"))

Para obter mais informações, consulte Políticas de indexação do Azure Cosmos DB.

Produtividade

  • Medir e ajustar para o uso mais baixo de unidades/segundo da solicitação

O Azure Cosmos DB oferece um conjunto avançado de operações do banco de dados, incluindo consultas relacionais e hierárquicas com UDFs, procedimentos armazenados e gatilhos – todos operando nos documentos em uma coleção de banco de dados. O custo associado a cada uma dessas operações varia com base na CPU, E/S e memória necessárias para concluir a operação. Em vez de pensar em e gerenciar recursos de hardware, você pode pensar em uma RU (unidade de solicitação) como uma medida única para os recursos necessários para realizar várias operações de bancos de dados e atender a uma solicitação do aplicativo.

A taxa de transferência é provisionada com base no número de unidades de solicitação definidas para cada contêiner. O consumo da unidade de solicitação é avaliado em termos de taxa por segundo. Os aplicativos que excedem a taxa das unidades de solicitação provisionada para seu contêiner serão limitados até que a taxa fique abaixo do nível reservado para o contêiner. Caso o aplicativo exija um nível mais alto de taxa de transferência, é possível aumentar a taxa de transferência provisionando unidades de solicitação adicionais.

A complexidade de uma consulta afeta a quantidade de unidades de solicitação consumida para uma operação. O número de predicados, natureza dos predicados, número de UDFs e tamanho do conjunto de dados de origem influenciam o custo das operações de consulta.

Para medir a sobrecarga de qualquer operação (criar, atualizar ou excluir), examine o cabeçalho x-ms-request-charge para medir o número de unidades de solicitação consumidas por essas operações.

document_definition = {
    'id': 'document',
    'key': 'value',
    'pk': 'pk'
}
document = container.create_item(
    body=document_definition,
)
print("Request charge is : ", container.client_connection.last_response_headers['x-ms-request-charge'])

A carga de solicitação retornada nesse cabeçalho é uma fração de sua taxa de transferência provisionada. Por exemplo, se você tem 2000 RUs/s provisionados e se a consulta anterior retornar 1000 documentos de 1 KB, o custo da operação será 1000. Assim, em um segundo, o servidor mantém apenas duas dessas solicitações antes de limitar as solicitações subsequentes. Para saber mais, consulte Unidades de solicitação e a calculadora das unidades de solicitação.

  • Lidar com uma limitação da taxa/taxa de solicitação muito grande

Quando um cliente tentar exceder a taxa de transferência reservada para uma conta, não haverá nenhuma degradação de desempenho no servidor e nenhum uso da capacidade da taxa além do nível reservado. O servidor encerrará antecipadamente a solicitação com RequestRateTooLarge (código de status HTTP 429) e retornará o cabeçalho x-ms-retry-after-ms indicando a quantidade de tempo, em milissegundos, que o usuário deve aguardar antes de tentar novamente a solicitação.

HTTP Status 429,
Status Line: RequestRateTooLarge
x-ms-retry-after-ms :100

Os SDKs irão capturar implicitamente essa resposta, respeitarão o cabeçalho server-specified retry-after e repetirão a solicitação. A menos que sua conta esteja sendo acessada simultaneamente por vários clientes, a próxima tentativa será bem-sucedida.

Se você tiver mais de um cliente operando cumulativamente acima da taxa de solicitação, a contagem padrão de tentativas atualmente definida como 9 internamente pelo cliente pode não ser suficiente; nesse caso, o cliente lança um CosmosHttpResponseError com código de status 429 para o aplicativo. A contagem padrão de tentativas pode ser alterada passando a configuração retry_total para o cliente. Por padrão, o CosmosHttpResponseError com código de status 429 é retornado após um tempo de espera cumulativo de 30 segundos se a solicitação continuar a operar acima da taxa de solicitação. Isso ocorre mesmo quando a contagem de repetição atual é menor que a contagem de repetição máxima, seja o padrão 9 seja um valor definido pelo usuário.

Embora o comportamento de repetição automática ajude a melhorar a resiliência e a utilidade da maioria dos aplicativos, ela pode entrar em conflito ao fazer comparações de desempenho, especialmente ao medir a latência. A latência observada pelo cliente terá um pico se o teste atingir a limitação do servidor e fizer com que o SDK do cliente repita silenciosamente. Para evitar picos de latência durante os testes de desempenho, meça o custo retornado por cada operação e verifique se as solicitações estão operando abaixo da taxa de solicitação reservada. Para saber mais, consulte Unidades de solicitação.

  • Design de documentos menores para uma maior taxa de transferência

O custo da solicitação (o custo de processamento da solicitação) de uma determinada operação está correlacionado diretamente com o tamanho do documento. As operações em documentos grandes custam mais que as operações de documentos pequenos. O ideal é arquitetar seu aplicativo e os fluxos de trabalho para que o tamanho do item seja aproximadamente 1 KB ou uma ordem de magnitude semelhante. Para aplicativos com detecção de latência, itens grandes devem ser evitados: documentos com vários MB tornarão o seu aplicativo mais lento.

Próximas etapas

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

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.