Equívocos
Velocidade
Mesmo quando não estamos falando de um índice multi-chave, aqui está o que acontece. Há uma varredura massiva de mesa acontecendo. Então o mongoDB itera sobre os documentos, tenta encontrar o campo a ser indexado, avalia esse campo (para
null se não existir no documento atual) e grava suas descobertas em nada menos que 6 arquivos, pois estamos falando de 6 índices. Fazendo as contas:200.000.000 / 86400 * 5 nos diz que o mongoDB faz isso para aproximadamente 460 documentos por segundo ou precisa apenas de 2,2 milissegundos por documento . Eu não chamaria isso de lento. Pode demorar, mas não é lento. {background:true}
Usar este parâmetro não bloquear você fora dos bancos de dados. Muito pelo contrário, que é claramente declarado nos documentos, tanto no Seção de criação de índice e na seção sobre a criação de índices em segundo plano . No entanto, há uma frase que pode ser facilmente mal interpretada:
O que isso significa é que você não pode fazer operações que se aplicam a todos os bancos de dados e requerem um bloqueio de leitura ou gravação.
Maneiras de melhorar (no futuro)
Cluster fragmentado
Use um cluster compartilhado com fragmentos do conjunto de réplicas. É fácil de configurar e tem várias vantagens, além de melhor desempenho. Um deles é a escalabilidade fácil adicionar um shard (e, assim, adicionar espaço e poder de computação a um cluster) é muito fácil. Os backups têm menos impacto no aplicativo. Não há mais um único ponto de falha (quando bem feito, isso se aplica até mesmo a interrupções na escala de um datacenter inteiro).
Use um sistema de arquivos diferente
Desculpe, executar um aplicativo dependente de desempenho de disco io em um Windows Server não faz sentido para mim - de jeito nenhum. ExtFS4 ou XFS são entre 25% e 40% mais rápidos que NTFS ou ReFS, dependendo da otimização. Isso torna um real diferença em aplicativos que são tão dependentes de E/S de disco como seu caso de uso. Estamos falando de uma questão de dias (sem levar em conta o mapeamento de memória mais eficiente e o consumo reduzido de memória do SO em sistemas Linux).
{background:true}
Embora isso realmente não melhore o desempenho (na verdade, a criação de índices em segundo plano leva mais tempo do que em primeiro plano por motivos óbvios), seu aplicativo permanece disponível durante o tempo em que o índice é compilado. Portanto, dependendo de suas necessidades, esta pode ser uma opção viável.
Nota lateral :É uma Má Ideia™ , para dimensionar verticalmente ao usar o mongoDB, pois foi explicitamente projetado para ser dimensionado horizontalmente. Isso se aplica especialmente a grandes coleções como a sua, pois o processamento paralelo melhoraria muito o desempenho do seu aplicativo.
