mysql - faster - ¿Está bien consultar un MongoDB varias veces por solicitud?

sql vs nosql

Question

Con un historial en RDBMS, siempre tuve la impresión de que "haga todo lo posible por usar una consulta, suponiendo que sea eficiente", lo que significa que es costoso para cada solicitud que realice a la base de datos. Cuando se trata de MongoDB, parece que esto podría no ser posible porque no puedes unir tablas.

Entiendo que no se supone que sea relacional, pero también lo están impulsando para fines como blogs, foros y cosas con las que me parece más fácil abordar un RDBMS.

Hay algunos cuelgues que he tenido tratando de entender la eficiencia de MongoDB o NoSQL en general. Si quisiera obtener todos los "mensajes" relacionados con ciertos usuarios (como si estuvieran agrupados) ... usando MySQL probablemente haría algunas uniones y obtendría eso con eso.

En MongoDB, suponiendo que necesito las colecciones por separado, ¿sería eficiente usar un gran $ in: [''usuario1'', ''usuario2'', ''usuario3'', ''usuario4'', ...]?

¿Ese método se vuelve lento después de un tiempo? Si incluyo 1000 usuarios? Y si tuviera que obtener esa lista de publicaciones relacionadas con los usuarios X, Y, Z, ¿sería eficiente y / o rápido usar MongoDB para hacerlo?

• Obtener matriz de usuarios
• Obtener publicaciones en la matriz de usuarios

2 consultas para una solicitud. ¿Es esa mala práctica en NoSQL?

Answer 1

Para responder la Q sobre $ en ....

Hice algunas pruebas de rendimiento con el siguiente escenario:

~ 24 millones de documentos en una colección
Busque 1 millón de esos documentos basados ​​en una clave (indexada)
Usando el controlador CSharp desde .NET

Resultados:
Consultando 1 a la vez, solo hilo: 109s
Consultando 1 a la vez, multiproceso: 48s
Consultar 100K a la vez usando $ in, single threaded = 20s
Consultar 100K a la vez usando $ in, multi threaded = 9s

Por lo tanto, un rendimiento notablemente mejor con un $ in grande (restringido al tamaño máximo de consulta).

Actualización: Siguiendo con los comentarios a continuación sobre cómo $ in se desempeña con diferentes tamaños de trozos (consultas de subprocesos múltiples):

Consultando 10 a la vez (100000 lotes) = 8.8s
Consultando 100 a la vez (10000 lotes) = 4.32s
Consultando 1000 a la vez (1000 lotes) = 4.31s
Consultando 10000 a la vez (100 lotes) = 8.4s
Consultando 100000 a la vez (10 lotes) = 9s (según los resultados originales anteriores)

Por lo tanto, parece que hay un punto dulce en la cantidad de valores para agrupar en una cláusula $ en comparación con la cantidad de viajes de ida y vuelta.