Se o MongoDB tem um calcanhar de Aquiles, é o fato de que ele suporta apenas gravações single-threaded e map-reduces single-thread.

Como sempre, há trocas aqui. As gravações de thread único são a maneira mais simples de evitar problemas de bloqueio e minimizar a sobrecarga. Da mesma forma, as reduções de mapa multi-threaded são uma ótima maneira de bloquear seus dados. Portanto, map-reduces de thread único em um sistema de produção são provavelmente mais fáceis e seguros.

No entanto, você não está sem ferramentas aqui. O MongoDB fornecerá um thread de gravação para cada instância. Portanto, se você fragmentar o MongoDB, obterá um thread de gravação para cada fragmento.

Se você quiser vários índices em 2 bilhões de linhas, você desejará analisar a fragmentação de qualquer maneira. Algumas contas rápidas aqui:MongoID é de 12 bytes. O índice no MongoID será 2B * 12 bytes =22GB+. Se agora você deseja adicionar mais dois índices (mesmo que apenas dois inteiros de 4 bytes), estamos falando de 7,5 GB para cada um.

Então, em 2B linhas, você está falando sobre ter mais de 37GBs em índices (mínimo ). Na maioria dos servidores de 8 núcleos, isso significa que você nem poderá manter seus índices na memória, muito menos qualquer um dos dados.

Portanto, se você deseja um desempenho sério aqui, comece a analisar o sharding. Apenas com base nos números gerais. FWIW, o MySQL não seria mais adepto de lidar com documentos 2B. Com tantos dados, você realmente vai querer vários servidores para acompanhar a carga.