Me he estado preguntando sobre la estructura de documento ideal para la máxima eficiencia de consulta para diversas situaciones y hay una sobre la que quiero preguntar. Debo realmente confirmar que realmente no sé cómo se comporta MongoDB en la memoria en este tipo de caso específico. Déjame darte un escenario hipotético.¿Qué es una buena estructura de documentos MongoDB para la consulta más eficiente de seguidores de usuarios/followees?
Imagine un sistema al estilo Twitter de seguidores y seguidores. Después de una mirada superficial es cierto, las principales opciones parecen ser:
En cada documento de usuario, una matriz de "seguidores" que contiene referencias a todos los documentos de otros usuarios que siguen. Los seguidores se encuentran al encontrar nuestro usuario actual en la matriz "user.followers" de otros usuarios. La desventaja principal parece ser la posible sobrecarga de consultas de la búsqueda de seguidores. Además, para una consulta específica para los contenidos de "usuario.seguidores", ¿accede MongoDB al campo requerido en los documentos de los usuarios, o se encuentra el documento de usuario completo y luego se buscan los valores de campo requeridos desde allí y se almacena en caché/almacenado de tal manera que una consulta en una gran base de usuarios requeriría significativamente más memoria?
En cada documento de usuario, almacena "seguidores" y "seguidores" para un acceso más rápido a cada uno. Obviamente, esto tiene la desventaja de los datos duplicados en el sentido de que existe una entrada para el usuario A que sigue al usuario B en ambos documentos del usuario en el campo respectivo, y su eliminación requiere una eliminación correspondiente en el otro. Técnicamente, esto podría estar considerando doblar el número de puntos de falla potencial para una eliminación simple. ¿Y MongoDB aún sufre de lo que he oído describir como "suizo en queso" de sus datos almacenados en la memoria cuando se producen eliminaciones, y por lo tanto, las eliminaciones de los 2 campos en lugar de 1 duplican el efecto de ese agujero en la memoria?
Colección separada para almacenar seguidores de los usuarios, consultada de manera similar a los documentos del usuario en 1, excepto que obviamente los únicos datos a los que se accede son Seguidores, de modo que si los documentos del usuario contienen bastantes otros datos relevantes cada usuario, evitamos el acceso a esa información. Esto parece tener algo de una base de datos relacional y aunque sé que no siempre es un enfoque terrible solo por principio, obviamente si uno de los otros enfoques mencionados (o uno que no he considerado) es mejor bajo la arquitectura de Mongo ¡me encantaría aprender!
Si alguien tiene alguna idea sobre esto, o me quiere decir que he perdido una página muy relevante y documentos y evidente en alguna parte, o incluso me quiere decir que sólo estoy siendo estúpida (que se cree con una explicación de por qué, por favor;)) ¡Me encantaría saber de usted!
¿Qué lenguaje de programación usará? Dependiendo de eso, hay ciertas características que el controlador subyacente puede o no admitir. En particular, estoy hablando de DBRefs. http://docs.mongodb.org/manual/applications/database-references/ –
Ese es un buen punto, gracias. Podríamos terminar usando cualquier cosa, pero actualmente una mezcla de PHP y Node.js. – tdous