MongoDB:miles de millones de documentos en una colección

Es difícil decir cuál es la inserción masiva óptima; esto depende en parte del tamaño de los objetos que está insertando y otros factores inconmensurables. Puede probar algunos rangos y ver cuál le brinda el mejor rendimiento. Como alternativa, a algunas personas les gusta usar mongoimport, que es bastante rápido, pero sus datos de importación deben ser json o csv. Obviamente, hay mongodrestore, si los datos están en formato BSON.

Mongo puede manejar fácilmente miles de millones de documentos y puede tener miles de millones de documentos en una colección, pero recuerde que el tamaño máximo del documento es de 16mb . Hay muchas personas con miles de millones de documentos en MongoDB y hay muchas discusiones al respecto en Grupo de usuarios de Google MongoDB . Aquí hay un documento en el uso de una gran cantidad de colecciones que le gustaría leer, si cambia de opinión y desea tener varias colecciones en su lugar. Cuantas más colecciones tenga, más índices tendrá también, lo que probablemente no sea lo que desea.

Aquí hay una presentación de Craigslist sobre la inserción de miles de millones de documentos en MongoDB y el tipo entrada de blog .

Parece que la fragmentación sería una buena solución para usted, pero normalmente la fragmentación se usa para escalar en varios servidores y muchas personas lo hacen porque quieren escalar sus escrituras o no pueden mantener su conjunto de trabajo (datos e índices) en RAM. Es perfectamente razonable comenzar con un solo servidor y luego pasar a un fragmento o conjunto de réplicas a medida que crecen sus datos o necesita redundancia y resiliencia adicionales.

Sin embargo, hay otros usuarios que usan múltiples mongods para sortear los límites de bloqueo de un solo mongod con muchas escrituras. Es obvio, pero aún así vale la pena decirlo, pero una configuración multi-mongod es más compleja de administrar que un solo servidor. Si su IO o CPU no está al máximo aquí, su conjunto de trabajo es más pequeño que la RAM y sus datos son fáciles de mantener equilibrados (distribuidos de manera bastante aleatoria), debería ver una mejora (con fragmentación en un solo servidor). Como FYI, existe potencial para la memoria y la contención de IO. Con 2.2 habiendo mejorado concurrencia con db bloqueo , sospecho que habrá muchas menos razones para tal despliegue.

Debe planificar su paso a la fragmentación correctamente, es decir, pensar detenidamente antes de elegir su clave de fragmentación. Si opta por este camino, lo mejor es dividir previamente y apagar el balanceador. Será contraproducente mover datos para mantener las cosas equilibradas, lo que significa que deberá decidir por adelantado cómo dividirlos. Además, a veces es importante diseñar sus documentos con la idea de que algún campo será útil para fragmentar o como clave principal.

Aquí hay algunos buenos enlaces -