tutorial - MongoDB: Millones de documentos en una colección.
mongodb modificar documento (2)
Es difícil decir cuál es el inserto a granel óptimo: esto depende en parte del tamaño de los objetos que está insertando y otros factores inconmensurables. Puedes probar algunos rangos y ver qué te da 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 de los documentos es de 16 MB . Hay mucha gente con miles de millones de documentos en MongoDB y hay muchas discusiones al respecto en el Grupo de Usuarios de Google de MongoDB . Aquí hay un document sobre 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 quiere.
Aquí hay una presentation de Craigslist sobre la inserción de miles de millones de documentos en MongoDB y el blogpost del chico.
Parece que sharding sería una buena solución para usted, pero típicamente sharding se usa para escalar a través de múltiples servidores y mucha gente lo hace porque quieren escalar sus escrituras o no pueden mantener su conjunto de trabajo (datos e índices) en la memoria RAM. Es perfectamente razonable comenzar con un solo servidor y luego pasar a un conjunto de fragmentos o réplicas a medida que sus datos aumentan o necesita redundancia y resistencia 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 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 forma bastante aleatoria), debería ver mejoras (con fragmentación en un solo servidor). Como FYI, hay potencial para la memoria y la contención de IO. Dado que 2.2 ha mejorado la concurrency con el bloqueo de db , sospecho que habrá una razón mucho menor para tal implementación.
Debe planificar su traslado a la fragmentación correctamente, es decir, piense detenidamente en elegir la clave de su fragmento. Si va por este camino, es mejor dividir previamente y apagar el equilibrador. Será contraproducente mover los datos para mantener el equilibrio, lo que significa que tendrá que 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 la fragmentación o como clave principal.
Aquí hay algunos buenos enlaces -
Necesito cargar 6.6 mil millones de bigramas en una colección, pero no puedo encontrar ninguna información sobre la mejor manera de hacerlo.
Cargar tantos documentos en un solo índice de clave principal llevaría una eternidad, pero hasta donde sé, ¿mongo no admite el equivalente a la partición?
¿Ayudaría sharding? ¿Debo intentar dividir el conjunto de datos en muchas colecciones y construir esa lógica en mi aplicación?
Usted puede absolutamente compartir datos en MongoDB (las particiones en los servidores N en la clave del fragmento ). De hecho, esa es una de sus fortalezas centrales. No hay necesidad de hacer eso en su aplicación.
Para la mayoría de los casos de uso, recomendaría encarecidamente hacerlo para 6.6 mil millones de documentos. En mi experiencia, MongoDB se desempeña mejor con varios servidores de rango medio en lugar de uno grande.