Manera eficiente de crear relaciones con la base de datos NoSQL

Question

Actualmente estoy tratando de implementar las interacciones del usuario tipo Tumblr como reblogs, seguidores, seguidores, comentarios, entradas de blog de personas que sigo actualmente, etc. También hay un requisito para mostrar actividad para cada publicación de blog.

Estoy atascado con la creación de un esquema adecuado para la base de datos. Hay varias maneras de lograr este tipo de funcionalidad (definir estructuras de datos integradas como publicaciones de blog y comentarios, crear un documento de actividad para cada acción, etc.) pero actualmente no podía decidir cuál es la mejor en términos de rendimiento y escalabilidad.

Por ejemplo, veamos la implementación de las personas que sigo. Aquí hay un documento de usuario de muestra.

User = { id: Integer, 
     username: String, 
     following: Array of Users, 
     followers: Array of Users, 
     } 

Esto parece trivial. Puedo administrar el siguiente campo por acción del usuario (seguir/dejar de seguir), pero ¿qué sucede si un usuario que actualmente sigo se elimina? ¿Es efectivo actualizar todos los registros de usuarios que siguen al usuario eliminado?

Otro problema es crear una vista de publicación de blog de las personas a las que sigo.

Post = { id: Integer, 
      author: User, 
      body: Text, 
     } 

Entonces, ¿es efectiva la consulta últimas publicaciones como;

db.posts.find({ author: { $in : me.followers} }) 

Answer 1

Un enfoque que funciona se llama "Star Schema". Si busca en la web o wikipedia, encontrará mucha información.

Answer 2

Parece (a mí) que está tratando de utilizar un único almacén de datos (en este caso, una base de datos NoSQL orientada a documentos) para cumplir (al menos) dos requisitos diferentes. Lo primero que parece que intenta hacer es almacenar datos en una tienda orientada a documentos. Voy a suponer que tienes razones legítimas para hacer esto.

Lo segundo que parece que intenta hacer es establecer relación (es) entre los documentos que está almacenando. Su ejemplo muestra una relación SIGUIENTE. Recomendaría tratar esto como un requisito diferente de almacenar datos en una base de datos NoSQL orientada a documentos y tratar de almacenar las relaciones en una base de datos NoSQL orientada a gráficos como Neo4j. De esta forma, sus entidades se pueden almacenar en la tienda de documentos y las relaciones en el almacén de gráficos utilizando solo los ID de documento.

Mi experiencia ha sido que será difícil (si no imposible) obtener una sola base de datos NoSQL para satisfacer todas las necesidades funcionales y no funcionales de una aplicación de tamaño mediano a grande. Por ejemplo, la última aplicación en la que estoy trabajando usa MongoDB, Redis y Neo4j además de un RDBMS. Pasé mucho tiempo experimentando con tecnologías y establecí esta combinación. Me he comprometido a usar Spring 3, junto con el proyecto Spring Data y hasta ahora mi experiencia ha sido excelente.