Estratégias de redução de latência multirregional

Distância física

A distância física é a principal causa de latência. A distância entre os usuários e seu aplicação, entre seu aplicação e seus dados e entre nós de cluster impacto a latência do sistema e o desempenho do aplicação .

Para reduzir a latência para operações de leitura, é crucial colocar seu aplicação e os dados geograficamente mais próximos dos usuários.

Configuração de replicação

Replicação é a cópia de dados do nó primário para nós secundários. Como você configura a replicação contribui para a latência. Considere os seguintes fatores:

• Níveis de write concern: Há uma troca entre a durabilidade da escrita e a latência da escrita. O nívelw: "majority" de preocupação de gravação que você configura (por exemplo,) define a replicação em vários centros de dados, potencialmente aumentando a latência para gravações mais duráveis. No entanto, isso garante que todos os dados estejam comprometidos com secundários e protege você contra a reversão das gravações em evento de failover.

• Prioridade das regiões: a ordem das regiões em sua configuração pode determinar a prioridade do local do nó primário, o que pode impacto a latência de gravação dependendo de onde seus usuários estão localizados. Por exemplo, se a maioria dos usuários estiver na Ásia, defina a maior prioridade para a região da Ásia para que ela seja eleita a principal.

• Leituras espelhadas: As leituras espelhadas reduzem o impacto das eleições primárias após uma interrupção ao pré-aquecer os caches nos nós secundários. Para obter mais informações, consulte Leituras espelhadas.

• Preferência de leitura: por padrão, os aplicativos enviam operações de leitura para o nó primário. No entanto, você pode configurar a preferência de leitura para enviar operações de leitura para nós secundários. Ao fazer isso, você garante que as leituras vão para o cluster geograficamente mais próximo. Para obter orientação sobre como implementar a melhor configuração para suas necessidades, entre em contato com a equipe de Serviços profissionais do MongoDB.

  Importante

  Lembre-se de que existe a possibilidade de um nó secundário retornar dados obsoletos devido ao atraso de replicação. Para obter mais informações sobre como configurar a consistência e o isolamento da leitura, consulte Read Concern.

• Distribuição dedados: distribuir dados entre regiões usando conjuntos de réplicas ou clusters fragmentados é uma abordagem eficaz quando seus dados são orientados geograficamente. Por exemplo, se você tiver dados que são lidos apenas da UE e outros dados que são lidos apenas na América do Norte, poderá criar clusters que distribuem esses dados adequadamente.

Configuração de rede

Você pode aumentar a segurança e potencialmente reduzir a latência usando endpoints privados. Os endpoints privados estabelecem conexões diretas e seguras entre a rede virtual do seu aplicativo e o seu Atlas cluster, potencialmente reduzindo os saltos de rede e melhorando a latência.

Monitoramento e teste da latência

O Atlas fornece o Real-Time Performance Panel (RTPP) para observar métricas de latência para diferentes regiões. Você também pode implementar o monitoramento em nível de aplicativo para acompanhar a latência de ponta a ponta de e para o aplicação. Antes da implantação na produção final, sugerimos realizar testes de desempenho nos vários cenários de multirregional para identificar e resolver os gargalos de latência.

Opções de configuração de conexão

Recomendamos que você use um método de conexão criado na versão do driver mais atual para a linguagem de programação do seu aplicativo sempre que possível. E embora a string de conexão padrão fornecida Atlas seja um bom ponto de partida, você pode querer ajustá-la para desempenho no contexto de seu aplicação específico e arquitetura de implantação.

Para sistemas de aplicação de nível empresarial, é especialmente importante ajustar as configurações do pool de conexões do aplicação para ajudá-lo a atender à demanda do usuário sem incorrer em latência operacional adicional. A abertura de conexões de cliente de banco de dados gera uma sobrecarga de rede significativa, portanto, é importante considerar como e quando a maioria das conexões de cliente de banco de dados deve ser aberta e definir as configurações do pool de conexões para que se alinham às suas preferências. Você pode usar a minPoolSize opção pool de conexões para especificar o número de conexões de cliente de banco de dados que são abertas na inicialização do aplicação . Após essas conexões iniciais, os pools de conexões abrem soquetes sob demanda para oferecer suporte a solicitações simultâneas ao MongoDB, até que o maxPoolSize número de conexões seja atendido.

Se os valores minPoolSize e maxPoolSize forem semelhantes, a maioria das conexões de cliente do banco de dados será aberta na inicialização do aplicação . Por exemplo, se o minPoolSize estiver definido como 10 e o maxPoolSize estiver definido como 12, 10 conexões de cliente serão abertas na inicialização do aplicação e somente mais 2 conexões poderão ser abertas durante o tempo de execução do aplicação . Isso incorre na maior parte do custo da rede na inicialização do aplicação , em vez de incorrer dinamicamente conforme a necessidade durante o tempo de execução do aplicação . A abertura de novos pools de conexões de banco de dados durante o tempo de execução do aplicação pode impacto potencialmente a latência operacional para os usuários finais se houver um pico inesperado nas solicitações que exija que um grande número de conexões adicionais seja aberto de uma só vez.

A arquitetura do aplicativo é fundamental para essa consideração. Se, por exemplo, você distribuir seu aplicação como microsserviços, considere quais serviços devem chamar o Atlas diretamente como um meio de controlar a expansão e contração dinâmicas do seu pool de conexões. Como alternativa, se o sistema do aplicação estiver aproveitando recursos de thread único, como o Amazon Web Services Lambda, seu aplicação só poderá abrir e usar uma conexão de cliente , portanto, seu minPoolSize e seu maxPoolSize devem ser definidos como 1.

Para saber mais sobre como e onde criar e usar um pool de conexões e onde especificar as configurações do pool de conexões , consulte Visão geral do pool de conexões.

Opções de latência de query

Você pode definir limites de tempo limite de query padrão globais e de nível de operação em seu sistema para reduzir o tempo que seu aplicação aguarda uma resposta antes de atingir o tempo limite.

Você também pode configurar read concerns globais em seu sistema para especificar o número de nós nos quais os dados devem ser replicados antes que uma operação de leitura seja relatada como bem-sucedida. O Atlas tem uma preocupação de leitura padrão de local, o que significa que, quando consultado, o Atlas recupera dados de apenas um nó em seu cluster para fornecer maior disponibilidade e menor latência sem garantir que os dados tenham sido gravados na maioria dos membros do conjunto de réplicas.

Distribuição de carga de trabalho fragmentada

A fragmentação permite que você escale seu cluster horizontalmente. Com o MongoDB, você pode fragmentar algumas collections e, ao mesmo tempo, permitir que outras collections no mesmo cluster permaneçam não fragmentadas. Quando você cria um novo banco de dados de dados, o fragmento no cluster com a menor quantidade de dados é escolhido como o fragmento primário desse banco de dados por padrão. Todas as collections não fragmentadas desse banco de dados de dados residem nesse fragmento primário por padrão. Isso pode causar um aumento no tráfego para o fragmento primário à medida que sua carga de trabalho cresce, especialmente se o crescimento do volume de trabalho se concentrar nas coleções não fragmentadas do fragmento primário.

Para distribuir melhor esse volume de trabalho, o MongoDB 8.0 permite mover uma coleção não fragmentada do fragmento primário para outros shards com o comando moveCollection . Isso permite que você coloque collections ativas e sobrecarregadas em shards com um uso menor de recursos. Com isso, você pode:

• Otimize o desempenho em volumes de trabalho maiores e complexos.

• Obtenha uma melhor utilização dos recursos.

• Distribua a data de forma mais uniforme entre os fragmentos.

Recomendamos isolar sua coleção nas seguintes circunstâncias:

• Se o seu fragmento primário tiver uma carga de trabalho significativa devido à presença de várias collections não fragmentadas de alta taxa de transferência.

• Você antecipa uma coleção não fragmentada para experimentar um crescimento futuro, o que pode se tornar um gargalo para outras coleções.

• Você está executando um design de implantação de uma collection por cluster e deseja isolar esses clientes com base em prioridade ou volumes de trabalho.

• Seus shards têm uma quantidade mais do que proporcional de dados devido ao número de collections não fragmentadas localizadas neles.

Para saber como mover uma collection não fragmentada com mongosh, consulte Mover uma collection.