MongoDB Sharding na máquina single linux

Question

Digamos que eu queira ter um servidor MongoDB com 5 shards em uma máquina e cada shard com réplicas de 3 servidores.

Isso aumentaria o desempenho? Quais são as desvantagens disso?

    

Answer 1

Os lados positivos:

• você poderia ter gravações simultâneas, desde que os dados estivessem com hash em diferentes shards. O MongoDB bloqueia todo o banco de dados nessa instância ao fazer uma gravação, de modo que até mesmo um conjunto de réplicas não particionado só pode escrever uma coisa por vez
• é uma boa maneira de aprender sharding / réplica de sets / admin, mas se você quiser fazer isso, poderá conseguir isso com menos instâncias
• a replicação seria muito rápida:)

As desvantagens:

• você precisaria de uma máquina poderosa (várias CPUs, mas também a maior quantidade de memória possível e discos rápidos) para realmente se beneficiar do desempenho - Mongo anseia por RAM! Para um desempenho ideal, o tamanho total do índice deve caber na RAM, o que significa que se você tiver 2 GB de índice por fragmento, precisará de 5 * 3 * 2 = 30 GB de memória RAM, além da memória do sistema operacional, etc.
• você pode não se beneficiar muito da opção de consulta slaveOK
• você não teria proteção contra falhas de hardware - se a caixa for exibida, todos os seus shards e conjuntos de réplicas serão

Answer 2

Pelo que entendi, você está perguntando se pode ter um servidor mestre, no qual você está executando cinco instâncias do mongod, cada uma delas identificada como um servidor separado para os mongos através do servidor de configuração e depois três -configured servidores como membros do conjunto de réplicas de cada fragmento. Minha resposta é baseada nesta interpretação.

Geralmente isso não é uma boa ideia. Se você estiver executando cinco processos de mongod separados (com cada um definido no servidor de configuração mongo), e cada um grava em um disco separado (eixos, não partições), isso pode ser aceitável e obter alguns benefícios na área do Disco I / O. No entanto, você não estará usando a memória do mestre com o melhor potencial e complicou desnecessariamente sua configuração (especialmente no tópico de backup / recuperação).

Normalmente, você só fragmenta quando está tendo atrasos devido a E / S nas gravações em disco. (Os atrasos de E / S nas leituras podem ser atenuados ativando a leitura de escravos no driver de idioma.) Isso é indicativo de ter a necessidade de expandir sua arquitetura. É importante ter isso em mente, porque significa que você deve comprar mais servidores. Manter um único mestre também torna a vida muito mais simples; o sharding aumenta sua complexidade.

Comece com um Replica Set e, se as operações de gravação forem um problema, , em seguida, você shard. É muito mais fácil adicionar sharding do que removê-lo.

(Isso tudo está ignorando o potencial de obter discos mais rápidos e mais memória. Os SSDs geralmente tornam o sharding desnecessário.)

O que você está fazendo é bom se estiver jogando com a configuração de Conjuntos de Fragmentos e Réplicas. (Você provavelmente deve evitar fazê-lo em Produção.) Honestamente, eu recomendaria fazê-lo de outra maneira; coloque um shard em cada host e gire os membros do conjunto de réplicas (mas evite ter os membros do replset no mesmo host que o primário), assim:

|Host1     | Host2     | Host3     | Host4     | 
|Shard1Pri | Shard2Pri | Shard3Pri | Shard4Pri |
|Shard2Sec | Shard3Sec | Shard4Sec | Shard1Sec | 
|Shard3Sec | Shard4Sec | Shard1Sec | Shard2Sec | 
|Shard4Sec | Shard1Sec | Shard2Sec | Shard3Sec |