MongoDB: Billetes de documentos en una colección

Question

Necesito cargar 6,6 mil millones de bigrams en una colección, pero no puedo encontrar ninguna información sobre la mejor manera de hacerlo.

Cargar tantos documentos en un único índice de clave principal llevaría una eternidad, pero, por lo que sé, mongo no es compatible con el equivalente de la creación de particiones.

¿Ayudaría sharding? ¿Debo intentar dividir el conjunto de datos en muchas colecciones y construir esa lógica en mi aplicación?

Answer 1

Es difícil decir cuál es la inserción óptima de volumen, esto depende en parte del tamaño de los objetos que está insertando y otros factores inconmensurables. Podrías probar algunos rangos y ver qué te ofrece 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 la misma colección, pero recuerde que el maximum document size is 16mb. Hay mucha gente con miles de millones de documentos en MongoDB y hay muchas discusiones al respecto en el MongoDB Google User Group. 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 múltiples colecciones en su lugar. Cuantas más colecciones tenga, más índices tendrá también, que probablemente no sea lo que desea.

Aquí está un presentation de Craigslist en la inserción de miles de millones de documentos en MongoDB y el tipo blogpost.

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

Sin embargo, hay otros usuarios que usan varios mongods para evitar 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 (bastante distribuidos aleatoriamente), debería ver una mejora (con fragmentación en un solo servidor). Como un FYI, hay potencial para la memoria y la contención de IO. Con 2.2 habiendo mejorado concurrency con db locking, sospecho que habrá una razón mucho menor para tal despliegue.

Debe planear su movimiento para fragmentar correctamente, es decir, piense detenidamente acerca de cómo elegir la clave de fragmento. Si sigue así, es mejor dividir previamente y apagar el equilibrador. Será contraproducente mover datos para mantener el equilibrio, lo que significa que tendrá que decidir de antemano cómo dividirlo. Además, a veces es importante diseñar sus documentos con la idea de que algún campo será útil para fragmentación en, o como una clave principal.

Aquí hay algunos buenos enlaces -

• Choosing a Shard Key
• Blog post on shard keys
• Overview presentation on sharding
• Presentation on Sharding Best Practices

Answer 2

Puede absolutamente shard data in MongoDB (que particiones en N servidores en el shard key). 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, recomiendo encarecidamente hacerlo para 6.6 billones de documentos. En mi experiencia, MongoDB funciona mejor con varios servidores de rango medio en lugar de uno grande.