mongoDB - ¿Qué es mejor? ¿Más consultas o una más pesada?

 
Vista:

¿Qué es mejor? ¿Más consultas o una más pesada?

Publicado por Suarsan (2 intervenciones) el 27/02/2016 18:42:15
Estoy diseñando una base de datos para un proyecto que crecerá bastante rápido en contenido, y me surgen dudas ya que estoy empezando con bbdd no relacionales. Si tuviese una gran cantidad de "eventos" con sus atributos asociados a cada usuario, ¿cómo me recomendaríais diseñar la bbdd?


1. ¿Es mejor separar todo y realizar más consultas (los tipicos join de las bbdd relacionales)?

Pros: La informacion estaria mas organizada
Contras: Se incrementarian las peticiones, y ademas serian repetitivas.


2. ¿Es mejor diseñar un solo modelo en el que se incluya toda la informacion mediante "embebers" y "embebers"?

Pros: Se reducirian mucho las consultas necesarias
Contras: Las consultas serian más pesadas, estaría toda la informacion más aglomerada.

En lineas generales, que se penaliza más en bbdd MongoDB, realizar más peticiones pero ligeras, o realizar menos pero más pesadas.
Valora esta pregunta
Me gusta: Está pregunta es útil y esta claraNo me gusta: Está pregunta no esta clara o no es útil
0
Responder
Imágen de perfil de xve
Val: 38
Ha disminuido 1 puesto en mongoDB (en relación al último mes)
Gráfica de mongoDB

¿Qué es mejor? ¿Más consultas o una más pesada?

Publicado por xve (44 intervenciones) el 28/02/2016 13:23:11
Hola Suarsan, la primera opción olvídate... para ello, sigue con SQL...

La segunda opción es la correcta, pero no son mas pesada, ya que devuelves únicamente los datos que necesites del documento.... y si esos datos están en el índice es impresionante-mente rápido.
Valora esta respuesta
Me gusta: Está respuesta es útil y esta claraNo me gusta: Está respuesta no esta clara o no es útil
0
Comentar

Respuesta

Publicado por Suarsan (2 intervenciones) el 28/02/2016 17:23:54
Hola xve! Ante todo gracias por tu respuesta.

Eso pensé desde un principio pero, a la hora de diseñar la bbdd me apoyé en la informacion oficial de MongoDB en la que se explica como diseñar relaciones "1 a muchos" y "muchos a muchos" y lo hace de una manera similar a la de las bases de datos relacionales. El sistema de "embeber" datos lo usa solo en casos de realciones "1 a 1".

¿Debería contradecir la documentación oficial proporcionada?

Decir también que aún usando tablas diferentes sigo teniendo ventajas con respecto a SQL ya que, por ejemplo, me permite agregar datos sin una estructura definida de antemano..

Saludos y espero su respuesta!
Valora esta respuesta
Me gusta: Está respuesta es útil y esta claraNo me gusta: Está respuesta no esta clara o no es útil
0
Comentar
Imágen de perfil de xve
Val: 38
Ha disminuido 1 puesto en mongoDB (en relación al último mes)
Gráfica de mongoDB

Respuesta

Publicado por xve (44 intervenciones) el 28/02/2016 21:04:32
No, no, por favor, no contradigas la documentación... sin duda ello saben mas que yo sin ninguna duda...

En mi experiencia, que estamos moviendo una colección con mas de 1000 millones de registros en varios PC's, teniendo toda la información en el mismo documento, nos ha facilitado mucho la vida y la velocidad...

Cabe decir, que no se que tipo de información vas a guardar... si vas a llegar a los 14Mb por documento, seguramente te sea importante separar en varias colecciones.... por ejemplo, si estamos hablando de facturas y productos, sin ninguna duda, los productos tienen que estar en otra colección, pero si hablamos de países, no es necesario dispones de una segunda colección que contenga únicamente los países.

De que tipo de información estamos hablando?
Valora esta respuesta
Me gusta: Está respuesta es útil y esta claraNo me gusta: Está respuesta no esta clara o no es útil
0
Comentar