Quando e como devemos fragmentar o MongoDB quando estamos ligados a máquinas físicas?

Question

Mantemos um serviço de pesquisa que veicula dados do MongoDB. Nossa instância de produção do Mongo é organizada em um conjunto de réplicas de quatro nós em quatro servidores físicos.

O banco de dados é composto por várias coleções pequenas e uma grande coleção. A grande coleção tem as seguintes características:

• número de documentos: 35 milhões
• tamanho médio do documento: ~ 4,2 kB
• tamanho da coleção: 151 GB
• storageSize: 157 GB

No próximo ano, prevemos que o número de documentos nesta coleção dobrará para ~ 70 milhões e uma duplicação no tamanho da coleção.

Estou ciente de que a seção "Sharding Existing Collection Data Size" do documento Limites de referência do Mongo , é especificado que " Para coleções existentes que armazenam documentos, o MongoDB suporta habilitação de sharding em qualquer coleção que contenha menos de 256 gigabytes de dados. O MongoDB pode ser capaz de fragmentar coleções com até 400 gigabytes dependendo da distribuição dos tamanhos dos documentos. ". Conseqüentemente, gostaríamos de compartilhar bem antes de atingirmos os 256 gigabytes de dados.

Temos algumas restrições sobre recursos e não estamos (ainda) em posição de virtualizar. No entanto, estamos em uma posição em que posso comprar dois novos servidores, elevando o total para seis máquinas de produção.

Minha pergunta é: é possível dividir o Mongo em dois shards, onde cada um é um conjunto de réplicas de 3 servidores com apenas seis servidores físicos? Estou ciente de que, além dos conjuntos de réplicas, exigimos três config servidores e um mongos servidor?

Devemos até mesmo estar sharding? Nosso uso atual de RAM e o número de conexões estão atualmente dentro de níveis aceitáveis. Existem outras estratégias que podemos adotar para permitir o crescimento de nosso banco de dados que não envolva sharding?

    

Answer 1

1) Por que você precisa de 4 nós para o conjunto de réplicas? usando um número par de nós em um conjunto de réplicas pode ser muito problemático, uma vez que quando um failover acontece, há uma eleição entre os nós para decidir qual será o principal, leia este - > link

3 nós são mais do que suficientes, 2 nós de db reais e 1 arbitragem pequena que apenas ajuda na eleição

2) em relação ao cluster de fragmentos - > o número mínimo de servidores físicos para um cluster com 2 shards com o conjunto mínimo de réplicas por shard é 9 (!), a divisão é a seguinte: shard 1 (conjunto de réplicas): 2 nós de dados + 1 arbitar (pode ser micro instância) shard 2 (conjunto de réplicas): 2 nós de dados + 1 arbitar (pode ser micro instância) 3 servidores de configuração (MUST !!) - estes podem ser máquinas bastante pequenas - usamos a instância t1.micro na amazon AWS.

Cada shard que você deseja adicionar ao cluster irá custar mais 3 nós físicos conforme acima.

mongos - > estas são instâncias do cliente com as quais o driver mongo do applcation deve interagir. Você pode implantá-los como parte de qualquer servidor da Web, para que você não precise de uma máquina separada.

veja isto para mais informações - link