Problemas de latência ao inserir conteúdo na China [fechado]

4

Plano de fundo

Temos um aplicativo que gravará em um banco de dados postgres hospedado no datacenter de Frankfurt. O aplicativo está instalado em cada um dos 8 sites que temos em todo o mundo, da China, Coréia, Índia, Alemanha, França e México.

Ao conectar na Europa, ao banco de dados de Frankfurt, os tempos de resposta são bons. No entanto, ao se conectar da parte norte da China, o tempo de resposta é lento. O grande firewall da China está atrasando o tempo de resposta e, além disso, a distância é um fator decisivo.

Decidimos configurar um segundo banco de dados na Coreia para nossos sites asiáticos. O aplicativo no site coreano e chinês estaria alimentando o banco de dados coreano. Reduziu as latências dramaticamente e funcionou como um encanto.

O problema é que não há como copiar os dados entre o banco de dados coreano e o alemão, pois a replicação bidirecional não é permitida.

Estamos agora de volta à estaca zero, pois não temos certeza sobre os passos a seguir, pois precisamos apenas de um único banco de dados, mas queremos um tempo de resposta decente. Não queremos reescrever o aplicativo.

Perguntas:

  • Queremos uma solução em que possamos hospedar um banco de dados e onde haja um tempo de resposta decente para todos os sites ao redor do mundo. Que outras soluções além do RDS podemos analisar?
  • Se continuarmos com o RDS, existe um datacenter que possa gerenciar uma resposta decente no tempo em todo o mundo?

Não tenho certeza se esse é o lugar certo para fazer essa pergunta. Se não, por favor deixe um comentário e eu vou deletar a pergunta.

    
por Andy K 22.06.2017 / 11:19

1 resposta

1

Tanto a distância quanto a intermediária adicionam latência, não há como evitar isso.

Pode haver outros locais para hospedar o banco de dados com um comprometimento de latência aceitável. Essa latência vai prejudicar os tempos de resposta. Continue testando.

Eu entendo que existem soluções de replicação multimestre para o PostgreSQL. Isso não estaria em seu software atual e provavelmente não será incluído em uma oferta na nuvem. Ele se beneficiaria de um DBA experiente, sendo mais complicado e mais arriscado do que uma instância.

Ou mova o cliente para mais perto. Host via desktop remoto ou VDI local para o banco de dados. Possivelmente, a interface sendo lenta é tolerável quando os tempos de carregamento das consultas são muito melhores.

Por fim, altere o aplicativo, apesar de ser pouco atraente. Pelo menos, defina o perfil do número de consultas para que a quantidade de tempo de rede seja conhecida. Reduzir estes poderia ter vitórias. Mais difícil seria repensar o design, talvez ler as consultas da réplica, mas as gravações vão para a primária.

    
por 23.06.2017 / 06:28