¿Cómo se registran las relaciones en NoSQL?

Estoy tratando de averiguar el equivalente de claves e índices externos en NoSQL KVP o bases de datos de documentos. Dado que no hay tablas pivotales (para agregar claves que marcan una relación entre dos objetos), estoy realmente perplejo en cuanto a cómo podría recuperar datos de una manera que sería útil para páginas web normales.

Digamos que tengo un usuario, y este usuario deja muchos comentarios en todo el sitio. La única forma que se me ocurre para realizar un seguimiento de los comentarios de los usuarios es

1. Incrustarlos en el objeto de usuario (que parece bastante inútil)
2. Cree y mantenga un user_id:commentsvalor que contenga una lista de la clave de cada comentario [comentario: 34, comentario: 197, etc.] para que pueda recuperarlos según sea necesario.

Sin embargo, tomando el segundo ejemplo, pronto se encontrará con una pared de ladrillos cuando lo use para rastrear otras cosas, como una clave llamada "active_comments", que puede contener 30 millones de identificadores, por lo que cuesta una TONELADA consultar cada página solo para conocer algunos datos recientes. comentarios activos. También sería muy propenso a las condiciones de carrera, ya que muchas páginas podrían intentar actualizarlo al mismo tiempo.

¿Cómo puedo rastrear relaciones como las siguientes en una base de datos NoSQL?

• Todos los comentarios de un usuario
• Todos los comentarios activos
• Todas las publicaciones etiquetadas con [palabra clave]
• Todos los estudiantes en un club, o todos los clubes en los que está un estudiante

¿O estoy pensando en esto incorrectamente?

Todas las respuestas sobre cómo almacenar asociaciones de varios a varios en la "forma NoSQL" se reducen a lo mismo: almacenar datos de forma redundante.

En NoSQL, no diseña su base de datos en función de las relaciones entre las entidades de datos. Usted diseña su base de datos basándose en las consultas que ejecutará contra ella. Use los mismos criterios que usaría para desnormalizar una base de datos relacional: si es más importante que los datos tengan cohesión (piense en valores en una lista separada por comas en lugar de en una tabla normalizada), hágalo de esa manera.

Pero esto inevitablemente se optimiza para un tipo de consulta (por ejemplo, comentarios de cualquier usuario para un artículo determinado) a expensas de otros tipos de consultas (comentarios de cualquier artículo de un usuario determinado). Si su aplicación necesita que ambos tipos de consultas estén igualmente optimizadas, no debe desnormalizar. Y del mismo modo, no debe utilizar una solución NoSQL si necesita utilizar los datos de forma relacional.

Con la desnormalización y la redundancia existe el riesgo de que los conjuntos de datos redundantes no estén sincronizados entre sí. Esto se llama anomalía . Cuando usa una base de datos relacional normalizada, el RDBMS puede prevenir anomalías. En una base de datos desnormalizada o en NoSQL, es su responsabilidad escribir el código de la aplicación para evitar anomalías.

Uno podría pensar que sería genial que una base de datos NoSQL hiciera el trabajo duro de prevenir anomalías por usted. Hay un paradigma que puede hacer esto: el paradigma relacional.

El enfoque de couchDB sugiere emitir las clases adecuadas de material en la fase de mapa y resumirlo en reducción. De modo que podría asignar todos los comentarios y emitir 1para el usuario dado y luego imprimir solo algunos. Sin embargo, requeriría mucho almacenamiento en disco para crear vistas persistentes de todos los datos rastreables en couchDB. por cierto, también tienen esta página wiki sobre relaciones: http://wiki.apache.org/couchdb/EntityRelationship .

Riak, por otro lado, tiene una herramienta para construir relaciones. Es un enlace. Puede ingresar la dirección de un documento vinculado (aquí comentario) al documento 'raíz' (aquí documento de usuario). Tiene un truco. Si se distribuye, puede modificarse de una vez en muchas ubicaciones. Causará conflictos y, como resultado, un enorme árbol de reloj vectorial: / ..no tan malo, no tan bueno.

Riak también tiene otro 'mecanismo'. Tiene un espacio de nombre de clave de 2 capas, llamado cubo y clave. Entonces, por ejemplo de estudiante, si tenemos el club A, B y C y el estudiante StudentX, StudentY, podría mantener la siguiente convención:

{ Key = {ClubA, StudentX}, Value = true }, 
{ Key = {ClubB, StudentX}, Value = true }, 
{ Key = {ClubA, StudentY}, Value = true }

y para leer la relación, simplemente enumere las claves en los depósitos dados. ¿Qué está mal con eso? Es muy lento. La lista de depósitos nunca fue una prioridad para riak. Sin embargo, se está poniendo cada vez mejor. por cierto. no desperdicia memoria porque este ejemplo {true}se puede vincular a un solo perfil completo de StudentX o Y (aquí los conflictos no son posibles).

Como lo ve NoSQL! = NoSQL. Debe observar la implementación específica y probarla usted mismo.

Mencionado antes, las tiendas de columnas parecen buenas para las relaciones ... pero todo depende de sus necesidades A, C y P;) Si no necesita A y tiene menos de Peta bytes, déjelo, continúe con MySql o Postgres.

buena suerte

1. user: userid: comments es un enfoque razonable; considérelo el equivalente de un índice de columna en SQL, con el requisito adicional de que no puede consultar en columnas no indexadas.

2. Aquí es donde debe pensar en sus requisitos. Una lista con 30 millones de elementos no es descabellada porque sea lenta, sino porque no es práctico hacer nada con ella. Si su requisito real es mostrar algunos comentarios recientes, es mejor que mantenga una lista muy corta que se actualice cada vez que se agrega un comentario; recuerde que NoSQL no tiene ningún requisito de normalización. Las condiciones de carrera son un problema con las listas en un almacén básico de valores clave, pero en general, o su plataforma admite listas correctamente, puede hacer algo con bloqueos o, en realidad, no le importan las actualizaciones fallidas.

3. Lo mismo que para los comentarios de los usuarios: cree una palabra clave de índice: publicaciones

4. Más de lo mismo: probablemente una lista de clubes como propiedad de los estudiantes y un índice en ese campo para obtener todos los miembros de un club.

Tienes

"user": {
    "userid": "unique value",
    "category": "student",
    "metainfo": "yada yada yada",
    "clubs": ["archery", "kendo"]
}

"comments": {
    "commentid": "unique value",
    "pageid": "unique value",
    "post-time": "ISO Date",
    "userid": "OP id -> THIS IS IMPORTANT"
}

"page": {
    "pageid": "unique value",
    "post-time": "ISO Date",
    "op-id": "user id",
    "tag": ["abc", "zxcv", "qwer"]
}

Bueno, en una base de datos relacional, lo normal sería normalizar los datos en una relación de uno a muchos. Eso es lo mismo que haría en una base de datos NoSQL. Simplemente indexe los campos con los que obtendrá la información.

Por ejemplo, los índices importantes para usted son

• Comment.UserID
• Comment.PageID
• Comment.PostTime
• Page.Tag []

Si está utilizando NosDB (una base de datos NoSQL basada en .NET con soporte SQL) sus consultas serán como

 SELECT * FROM Comments WHERE userid = ‘That user’;

 SELECT * FROM Comments WHERE pageid = ‘That user’;

 SELECT * FROM Comments WHERE post-time > DateTime('2016, 1, 1');

 SELECT * FROM Page WHERE tag = 'kendo'

Verifique todos los tipos de consulta admitidos en su hoja de trucos o documentación de SQL .