¿Cómo podría diseñar un blog utilizando una tienda de documentos (como CouchDB, Redis, MongoDB, Riak, etc.)

Question

Me da un poco de vergüenza admitirlo, pero tengo problemas para conceptualizar cómo se pueden generar datos de forma no científica. mundo relacional. Especialmente dado que la mayoría de las tiendas de documentos/KV tienen características ligeramente diferentes.

Me gustaría aprender de un ejemplo concreto, pero no he podido encontrar a nadie que debata cómo se podría diseñar, por ejemplo, un blog que utiliza CouchDB/Redis/MongoDB/Riak/etc.

Hay una serie de preguntas que creo que son importantes:

1. qué bits de datos deben ser desnormalizar (por ejemplo, etiquetas, probablemente viven con el documento, pero ¿qué pasa con los usuarios)
2. ¿Cómo enlazar entre los documentos?
3. ¿Cuál es la mejor manera de crear vistas globales, especialmente los que requieren la clasificación (como un índice de blogs)

Answer 1

Ryan Bates hizo un screencast hace un par de semanas sobre MongoId y utiliza el ejemplo de un blog aplicación: http://railscasts.com/episodes/238-mongoid este podría ser un buen lugar para comenzar.

Answer 2

En primer lugar, creo que le gustaría eliminar los redis de la lista, ya que es una tienda de valores-clave en lugar de una tienda de documentos. Riak también es una tienda de valores clave, pero puede ser una tienda de documentos con una biblioteca como Ripple.

En resumen, para modelar una aplicación con almacén de documentos es averiguar:

1. ¿Qué datos en que almacena en su propio documento y tener otro documento se refieren a la misma. Si ese documento va a ser utilizado por muchos otros documentos, entonces tendría sentido modelarlo en su propio documento. También debe considerar la posibilidad de consultar los documentos. Si va a consultarlo con frecuencia, puede ser una buena idea almacenarlo en su propio documento, ya que le resultaría difícil consultarlo sobre un documento incrustado.
   • Por ejemplo, suponiendo que tiene varias instancias de Blog, un Blog y Artículo debe estar en su propio documento aunque un Artículo puede estar incrustado dentro del documento de Blog.
   • Otro ejemplo es Usuario y Rol. Tiene sentido tener un documento separado para estos. En mi caso, a menudo consulto sobre el usuario y sería más fácil si estuviera separado como su propio documento.

2. ¿Qué datos que se desea almacenar (embed) dentro de otro documento. Si ese documento solo pertenece a un documento, podría ser una buena opción almacenarlo dentro de otro documento.

   • Comentarios veces tendría más sentido para ser integrado dentro de otro documento

   { article : { comments : [{ content: 'yada yada', timestamp: '20/11/2010' }] } }

   Otra advertencia que le gustaría tener en cuenta es cuán grande es el tamaño del documento incrustado será porque en mongodb , el tamaño máximo del documento incrustado es de 5 MB.

3. Qué datos deben ser una matriz simple. mi.g:
   • Las etiquetas tienen sentido para almacenarse como una matriz. { article: { tags: ['news','bar'] } }
   • O si lo desea almacenar varios ID de usuario, es decir, con múltiples funciones { user: { role_ids: [1,2,3]}}

Esta es una breve visión general sobre el modelado con almacén de documentos. Buena suerte.

Answer 3

1. La decisión sobre qué objetos deben ser independientes y que debe ser incorporado como parte de otros objetos es sobre todo una cuestión de equilibrar/escritura rendimiento/esfuerzo de leer - Si un objeto secundario es independiente, actualizándolo significa cambiar un solo documento pero cuando lee el objeto padre, solo tiene identificadores y necesita consultas adicionales para obtener los datos. Si el objeto secundario está incrustado, todos los datos están allí cuando lee el documento principal, pero realizar un cambio requiere encontrar todos los documentos que usan ese objeto.

2. La vinculación entre documentos no es muy diferente de SQL: usted almacena una identificación que se utiliza para encontrar el registro apropiado. La diferencia clave es que en lugar de filtrar la tabla secundaria para buscar registros por ID padre, tiene una lista de identificadores secundarios en el documento principal. Para muchas relaciones tendrías una lista de identificadores en ambos lados en lugar de una tabla en el medio.

3. Las capacidades de consulta varían mucho entre las plataformas, por lo que no hay una respuesta clara sobre cómo abordar esto. Sin embargo, como regla general, generalmente se configurará vistas/índices cuando se escriba el documento en lugar de simplemente almacenar el documento y ejecutar consultas ad-hoc más tarde como lo haría con SQL.