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

nosql (3)

Estoy un poco avergonzado de admitirlo, pero estoy teniendo problemas para conceptualizar cómo diseñar datos en un mundo no 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 discuta cómo diseñaría, por ejemplo, un blog que usa CouchDB / Redis / MongoDB / Riak / etc.

Hay una serie de preguntas que creo que son importantes:

¿Qué bits de datos deberían ser desnormalizados (por ejemplo, las etiquetas probablemente vivan con el documento, pero qué pasa con los usuarios)?
¿Cómo se vinculan los documentos?
¿Cuál es la mejor manera de crear vistas agregadas, especialmente aquellas que requieren clasificación (como un índice de blog)?

En primer lugar, creo que le gustaría eliminar el redis de la lista, ya que es un almacén de clave-valor en lugar de un almacén 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, modelar una aplicación con la tienda de documentos es averiguar:

Qué datos almacenará en su propio documento y tendrá otro documento relacionado con él. 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 tienes varias instancias de Blog, un Blog y Artículo debe estar en su propio documento aunque un Artículo puede estar insertado dentro del documento de Blog.
- Otro ejemplo es User and Role. 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.
Qué datos desearía almacenar (incrustar) dentro de otro documento. Si ese documento solo pertenece a un documento, podría ser una buena opción almacenarlo dentro de otro documento.
- Los comentarios a veces tendrían más sentido para integrarse en otro documento
{ article : { comments : [{ content: ''yada yada'', timestamp: ''20/11/2010'' }] } }

Otra advertencia que debería considerar es cuán grande será el tamaño del documento incrustado porque en mongodb, el tamaño máximo del documento incrustado es de 5 MB.
¿Qué datos deberían ser una matriz simple? p.ej:
- Las etiquetas tendrían sentido para almacenarse como una matriz. { article: { tags: [''news'',''bar''] } }
- O si desea almacenar varios ID, es decir, usuario con múltiples roles { user: { role_ids: [1,2,3]}}

Esta es una breve descripción general sobre el modelado con la tienda de documentos. Buena suerte.

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

Decidir qué objetos deberían ser independientes y cuáles deberían integrarse como parte de otros objetos es principalmente una cuestión de equilibrar el rendimiento / esfuerzo de lectura / escritura. Si un objeto secundario es independiente, actualizarlo significa cambiar solo un documento, pero al leer el objeto principal 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.
La vinculación entre documentos no es muy diferente de SQL: almacena una ID que se usa 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.
Las capacidades de consulta varían mucho entre 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.