Um conjunto de réplicas significa que você possui várias instâncias do MongoDB, cada uma espelhando todos os dados uma da outra. Um conjunto de réplicas consiste em um mestre (também chamado de "primário") e um ou mais escravos (também conhecido como secundário). As operações de leitura podem ser atendidas por qualquer escravo, para que você possa aumentar o desempenho da leitura adicionando mais escravos ao conjunto de réplicas (desde que seu aplicativo cliente seja capaz de realmente usar diferentes membros do conjunto). Porém, as operações de gravação sempre ocorrem no mestre do conjunto de réplicas e são propagadas para os escravos, para que as gravações não fiquem mais rápidas quando você adicionar mais escravos.
Conjuntos de réplicas também oferecem tolerância a falhas. Quando um dos membros do conjunto de réplicas cai, os outros assumem o controle. Quando o mestre cair, os escravos elegerão um novo mestre. Por esse motivo , é sugerido que a implantação produtiva sempre use o MongoDB como um conjunto de réplicas de pelo menos três servidores, dois deles contendo dados (o terceiro é um "árbitro" sem dados, necessário para determinar um novo mestre quando um dos escravos cai).
Um cluster sharded significa que cada shard do cluster (que também pode ser um conjunto de réplicas) cuida de uma parte dos dados. Cada solicitação, tanto de leitura quanto de gravação, é atendida pelo cluster em que os dados residem. Isso significa que o desempenho de leitura e gravação pode ser aumentado adicionando mais shards a um cluster. Qual documento reside em qual fragmento é determinado pela chave de fragmento de cada coleção. Ele deve ser escolhido de forma que os dados possam ser distribuídos uniformemente em todos os clusters e para que fique claro para as consultas mais comuns em que a chave de fragmento reside (exemplo: quando você consulta frequentemente user_name, sua chave de fragmento deve incluir o campo user_namepara que cada consulta possa ser delegada apenas ao fragmento que possui esse documento).
A desvantagem é que a tolerância a falhas sofre. Quando um fragmento do cluster fica inoperante, qualquer dado nele fica inacessível. Por esse motivo, cada membro do cluster também deve ser um conjunto de réplicas. Isso não é necessário. Quando você não se importa com alta disponibilidade, um shard também pode ser uma instância única do mongod sem replicação . Mas para uso em produção, você sempre deve usar replicação .
Então, o que isso significa para o seu exemplo?
Sharded Cluster
/ | \
Shard A Shard B Shard C
/ \ / \ / \
+-------+ +---------+ +-------+ +---------+ +-------+ +---------+
|Primary| |Secondary| |Primary| |Secondary| |Primary| |Secondary|
| 25GB |=| 25GB | | 25 GB |=| 25 GB | | 25GB |=| 25GB |
+-------+ +---------+ +-------+ +---------+ +-------+ +---------+
Quando você deseja dividir seus dados de 75 GB em 3 shards de 25 GB cada, precisa de pelo menos 6 servidores de banco de dados organizados em três conjuntos de réplicas. Cada conjunto de réplicas consiste em dois servidores que possuem os mesmos 25 GB de dados.
Você também precisa de servidores para os árbitros dos três conjuntos de réplicas, bem como do roteador mongos e do servidor de configuração do cluster. Os árbitros são muito leves e são necessários apenas quando um membro do conjunto de réplicas é desativado, para que eles possam compartilhar o mesmo hardware com outra coisa. Mas o roteador Mongos e o servidor de configuração devem ser redundantes e em seus próprios servidores.