MongoDB:bilhões de documentos em uma coleção

É difícil dizer qual é a inserção em massa ideal - isso depende em parte do tamanho dos objetos que você está inserindo e de outros fatores imensuráveis. Você pode experimentar alguns intervalos e ver o que oferece o melhor desempenho. Como alternativa, algumas pessoas gostam de usar mongoimport, que é bem rápido, mas seus dados de importação precisam ser json ou csv. Obviamente, há mongodrestore, se os dados estiverem no formato BSON.

O Mongo pode lidar facilmente com bilhões de documentos e pode ter bilhões de documentos em uma coleção, mas lembre-se de que o o tamanho máximo do documento é 16 MB . Existem muitas pessoas com bilhões de documentos no MongoDB e há muitas discussões sobre isso no Grupo de usuários do MongoDB Google . Aqui está um documento em usar um grande número de coleções que você pode gostar de ler, se você mudar de ideia e quiser ter várias coleções em vez disso. Quanto mais coleções você tiver, mais índices também terá, o que provavelmente não é o que você deseja.

Aqui está uma apresentação do Craigslist sobre a inserção de bilhões de documentos no MongoDB e o post do blog .

Parece que o sharding seria uma boa solução para você, mas normalmente o sharding é usado para dimensionar vários servidores e muitas pessoas fazem isso porque desejam dimensionar suas gravações ou não conseguem manter seu conjunto de trabalho (dados e índices) em RAM. É perfeitamente razoável começar com um único servidor e depois passar para um shard ou conjunto de réplicas à medida que seus dados crescem ou você precisa de redundância e resiliência extras.

No entanto, existem outros usuários que usam vários mongods para contornar os limites de bloqueio de um único mongod com muitas gravações. É óbvio, mas ainda vale a pena dizer, mas uma configuração multi-mongod é mais complexa de gerenciar do que um único servidor. Se o seu IO ou cpu não estiver no máximo aqui, seu conjunto de trabalho for menor que a RAM e seus dados forem fáceis de manter equilibrados (distribuídos de forma bastante aleatória), você deverá ver melhorias (com fragmentação em um único servidor). Como um FYI, há potencial para contenção de memória e IO. Com 2.2 tendo melhorado a simultaneidade com db bloqueio , suspeito que haverá muito menos motivos para tal implantação.

Você precisa planejar sua mudança para o sharding corretamente, ou seja, pense com cuidado ao escolher sua chave de fragmentação. Se você seguir esse caminho, é melhor pré-dividir e desligar o balanceador. Será contraproducente mover dados para manter as coisas equilibradas, o que significa que você precisará decidir antecipadamente como dividi-los. Além disso, às vezes é importante projetar seus documentos com a ideia de que algum campo será útil para fragmentação ou como chave primária.

Aqui estão alguns bons links -