Suas experiências de latência são um pouco preocupantes. Em meus próprios testes em minha rede local e rápida, notei algumas diferenças entre Mongo & MySQL quando se trata de latência:
- O tempo de ida e volta do pedido do MySQL é frequentemente inferior a 5 ms para itens pequenos. Às vezes tão baixo quanto 2.
- Solicitação do MongoDB O RTT é cerca de 3 vezes mais lento, cerca de 15 ms.
Parte do tempo do MongoDB foi devido ao tempo de configuração da conexão TCP, onde o MySQL estava usando uma conexão pré-existente (em pool). Em ambos os casos, o banco de dados não foi replicado ou particionado, portanto, eles podem ser considerados os melhores casos (para minha rede).
Os conjuntos de réplicas do Mongo podem ajudá-lo aqui, mas somente se o aplicativo puder tolerar a convergência flexível 1 . Para obter velocidade máxima, você terá que configurar suas gravações do mongo para retornar somente quando o servidor mongodb relatar que recebeu a gravação e configurar seus servidores de aplicativos para usar apenas a instância local do Mongo AZ. As leituras precisarão usar o SlaveOK para que possam ler a partir dessa réplica local AZ, isso mostrará as gravações locais, bem como as gravações replicadas dos outros nós que foram convergidos até o momento. Isso significa que cada AZ terá uma visão ligeiramente diferente de todo o banco de dados; os últimos X minutos só terão mudanças locais, mas a história profunda será convergida.
Esta configuração fornecerá baixa latência (mesmo AZ) entre o servidor de aplicativos e o servidor de banco de dados. No entanto, a exibição de dados dos servidores de aplicativos será diferente, dependendo do AZ sendo atingido pelos seus consumidores de aplicativos. Se essa arquitetura é tolerável ou não para o seu aplicativo, isso só pode ser decidido por você.
No entanto, há um grande problema com isso: O MongoDB não suporta replicação multi-master 2 , todas as gravações devem ir para o mestre único. p>
Atualmente (v2.2) não é possível configurar o MongoDB para permitir gravações em escravos, portanto, todas as gravações em seu aplicativo "write pesado" terão que ir para o único mestre do conjunto de réplicas. Você não menciona se a latência de leitura é um problema, mas se for, então SlaveOK lê vai pegar o membro de réplica local do Mongo; mas diferentemente do acima, ele pode não ter recebido todas as atualizações do mestre, então definitivamente haverá um atraso entre o write-submit e quando ele aparecer no slave local.
Existem alguns tipos de escrita diferentes para o Mongo. O padrão retorna OK assim que o servidor do Mongo recebeu totalmente a gravação. O próximo passo é o modo em que só retorna OK quando foi gravada a gravação no Journal. E o mais paranóico (e, portanto, mais lento em um mongo com réplicas) só retorna OK quando um número especificado de réplicas reporta que a gravação está em seus diários . O modo padrão é mais rápido, mas o último modo garante que as réplicas locais tenham a gravação (consistência estrita).
Se esse mestre não estiver no mesmo AZ que os servidores de aplicativos, a latência pode muito bem ser impraticável para você, mesmo com o estilo de gravação padrão. Se este for o caso, o mongo não funcionará para você como seu aplicativo existe agora . você terá que pensar muito sobre como alterar seu aplicativo para ficar menos sensível à latência em gravações ou usar um banco de dados que não seja do Mongo e que possa fazer vários mestres com convergência flexível.
O Mongo mais próximo de uma configuração multi-master é através de sharding. Se os seus servidores de aplicativos estiverem cientes de sua localização geográfica, você poderá incluir os dados geográficos na chave de fragmento do Mongo. Então, quando você se conecta ao MongoS para escrever, todas as gravações vão para o conjunto de réplicas do fragmento local. As leituras podem pesquisar o banco de dados inteiro (e serão lentas de maneira lenta ao desenhar a partir dos fragmentos não locais), portanto, isso manterá a consistência. No entanto, isso depende inteiramente da localização ser sua chave de fragmento.
1: Loose Convergence , o tempo para um banco de dados distribuído ou replicado chegar a um estado uniforme é o tempo de convergência. Convergência solta é um longo intervalo. A convergência apertada é um intervalo curto.
2: Multi-master , Um banco de dados no qual mais de uma réplica pode aceitar gravações. Exemplos de bancos de dados que podem fazer isso são o Active Directory, o OpenLDAP e algumas configurações do MySQL.