español - sharding mongodb tutorial

120 colecciones mongodb versus colección única: ¿cuál es más eficiente? (2)

Colección Single Sharded

La versión editada de la pregunta aclara el requisito real: tiene una colección que potencialmente puede crecer mucho y desea un enfoque para particionar los datos. El límite de recolección artificial es su propio esquema de partición planificado.

En ese caso, creo que sería mejor utilizar una única recopilación y aprovechar la auto-sharding para distribuir los datos y la carga de trabajo a varios servidores según sea necesario. Múltiples colecciones sigue siendo un enfoque válido, pero complica innecesariamente el código y la implementación de su aplicación en lugar de aprovechar las funciones principales de MongoDB. Suponiendo que elija una buena clave de fragmento , sus datos se equilibrarán automáticamente en sus fragmentos.

Usted no puede tener que fragmentar inmediatamente; puede aplazar la decisión hasta que vea que su carga de trabajo realmente requiere más escala de escritura (pero saber que la opción está ahí cuando la necesita). También tiene otras opciones antes de decidir compartir, como la actualización de sus servidores (discos y memoria en particular) para soportar mejor su carga de trabajo. Por el contrario, no desea esperar hasta que su sistema sea aplastado por la carga de trabajo antes de la fragmentación, por lo que definitivamente necesita monitorear el crecimiento. Sugeriría utilizar el servicio gratuito de monitoreo de MongoDB (MMS) proporcionado por 10gen.

En otro sitio web alguien sugirió usar muchas bases de datos en lugar de muchas colecciones. Pero esto significa gastos generales y luego tendría que usar / administrar muchas conexiones diferentes.

Múltiples bases de datos agregarán significativamente más gastos administrativos, y probablemente serían excesivos y posiblemente perjudiciales para su caso de uso. El almacenamiento se asigna a nivel de la base de datos, por lo que 120 bases de datos consumirían mucho más espacio que una sola base de datos con 120 colecciones.

Número fijo de colecciones (respuesta original)

Si puede planificar un número fijo de colecciones (120 según la descripción de su pregunta original), creo que tiene más sentido adoptar este enfoque en lugar de utilizar una colección monolítica.

NOTA : las siguientes consideraciones de diseño aún se aplican, pero dado que la pregunta se actualizó para aclarar que varias colecciones son un intento de esquema de partición, fragmentar una sola colección sería un enfoque mucho más directo.

Las motivaciones para usar colecciones separadas serían:

Es probable que sus documentos para una colección grande tengan que incluir alguna indicación del subtipo de colección, que puede ser necesario agregar a múltiples índices y podría aumentar significativamente el tamaño de los índices. Con colecciones separadas, el subtipo ya está implícito en el espacio de nombres de la colección.
Sharding está habilitado en el nivel de colección. Una sola colección grande solo le brinda un enfoque de "todo o nada", mientras que las colecciones individuales le permiten controlar qué subconjunto (s) de datos deben ser fragmentados y elegir claves de fragmento más apropiadas.
Puede utilizar el comando compact para desfragmentar colecciones individuales. Nota: compact es una operación de bloqueo, por lo que la recomendación normal para un entorno de producción de alta disponibilidad sería implementar un conjunto de réplicas y usar el mantenimiento continuo (es decir, compactar primero los secundarios, luego bajar y compactar el primario).
MongoDB 2.4 (y 2.2) actualmente tiene granularidad de bloqueo de escritura a nivel de base de datos. En la práctica, esto no ha demostrado ser un problema para la gran mayoría de los casos de uso, sin embargo, múltiples colecciones le permitirían mover colecciones de alta actividad a bases de datos separadas si fuera necesario.
Más allá del punto anterior ... si tiene sus datos en colecciones separadas, estos podrán aprovechar futuras mejoras en el bloqueo a nivel de colección (consulte SERVER-1240 en el rastreador de problemas Jira de MongoDB).

Soy nuevo en mongodb y me enfrento a un dilema relacionado con el diseño de mi esquema de DB:

Debería crear una sola colección o poner mis datos en varias colecciones (podríamos llamar a estas categorías, supongo).

Ahora sé que se han formulado muchas de estas preguntas, pero creo que mi caso es diferente por 2 razones:

Si voy por muchas colecciones, tendré que crear alrededor de 120 y eso es todo. Esto no crecerá en el futuro.
Sé que nunca necesitaré consultar o insertar en varias colecciones. Siempre tendré que consultar solo uno, ya que un documento de la colección X no está relacionado con ningún documento almacenado en las otras colecciones. Sin embargo, los documentos pueden contener referencias a otras partes de la base de datos (como userId, etc.).

Entonces mi pregunta es: ¿podrían las 120 colecciones mejorar el rendimiento de las consultas? ¿Es esta una optimización útil en mi caso?

¿O debería simplemente ir por una sola colección + fragmentación?

Se espera que cada colección contenga millones de documentos. Si usa solo uno, almacenará miles de millones de documentos.

¡Gracias por adelantado!

------- Edición:

Gracias por las buenas respuestas.

De hecho, las 120 colecciones son solo un límite hecho por sí mismo, no es realmente óptimo:

Los datos en las colecciones están relacionados con los editores web. Podría haber millones de estos (cualquier sitio web puede unirse).

Supongo que la situación ideal sería si pudiera crear una colección para cada editor (solo para mantener sus datos). Pero obviamente, esto no es posible debido a las limitaciones del mongo.

Así que se me ocurrió la idea de un número fijo de colecciones para al menos distribuir los datos de alguna manera. Me gusta: la colección "A_XX" tendría datos de la XX Plataforma para editores cuyos nombres comienzan con "A" ... etc. Solo admitiremos algunas de estas plataformas, por lo que 120 colecciones deberían ser más que suficientes.

En otro sitio web alguien sugirió usar muchas bases de datos en lugar de muchas colecciones. Pero esto significa gastos generales y luego tendría que usar / administrar muchas conexiones diferentes.

¿Qué piensas sobre esto? ¿Hay una solución mejor?

Lo siento por no ser lo suficientemente específico en mi pregunta original.

Gracias por adelantado

El principal problema aquí es que obtendrá muy poco rendimiento en las versiones actuales de MongoDB si separa las colecciones en la misma base de datos. Para obtener cualquier tipo de rendimiento adicional en una configuración de colección única, tendría que mover las colecciones a bases de datos separadas, entonces tendrá una sobrecarga operativa para juzgar qué base de datos debe consultar, etc.

Así que sí, podría ir a 120 colecciones fácilmente, sin embargo, en realidad no ganará nada debido a: SERVER-1240 no se está implementando (en cualquier momento pronto).

Alojar miles de millones de documentos en una sola colección no es tan malo. Supongo que incluso si tuviera que alojar esto en colecciones separadas, probablemente tampoco estaría en un solo servidor, como si se tratara de una sola colección, por lo que cualquier reducción de velocidad debida a la configuración de varios servidores tampoco será importante en este caso.

En mi opinión personal, usar una sola colección es más fácil en todo.