¿Es factible el enfoque de la base de datos por usuario de CouchDB para usuarios con muchos datos compartidos?

Question

Quiero implementar una aplicación web, una fuente que integra datos de varias fuentes y los muestra a los usuarios. Un usuario solo debería poder ver los elementos del feed que tiene permisos para leer (por ejemplo, porque pertenecen a un proyecto del que es miembro). Sin embargo, muchos usuarios podrían ver (y lo harán) un elemento de feed.

Realmente me gustaría usar CouchDB (principalmente debido a la alimentación _cambios geniales y las vistas de mapa/reducción). Estaba pensando en implementar la aplicación como couchapp pura, pero estoy teniendo problemas con el modelo de permisos. AFAIK, no hay permisos por documento en CouchDB y esto se implementa comúnmente utilizando bases de datos por usuario y replicación.

Pero cuando hay mucha superposición entre lo que ven los distintos usuarios, eso introduciría MUCHA sobrecarga ... las cosas se replicarían por todas partes y se duplicarían en muchas bases de datos. Me gusta la elegancia de este enfoque, pero la sobrecarga masiva solo se siente como un obstáculo ... (Digamos que tengo 50 usuarios y todos ven los mismos datos ...).

Alguna idea de cómo hacerlo, por favor? ¿Solución alternativa?

Answer 1

Puede aplicar los permisos de lectura como se describe en CouchDB Authorization on a Per-Database Basis.

Para permisos de escritura, puede usar funciones de validación como se describe en CouchDB The Definitive Guide - Security.

Puede crear una base de datos para cada proyecto y aplicar los permisos allí, luego todos los datos se comparten de manera eficiente entre los usuarios. Si un usuario comparte un feed él mismo y también necesita permisos, puede convertirlo en un "proyecto", por lo que la misma lógica se aplica en todas partes.

Al usar este diseño, puede autorizar a un usuario o grupo de usuarios (roles) para cada proyecto.

Answer 2

Aparte de (como ya ha sugerido victorsavu3) el manejo de su aut de lectura en un proxy entre su aplicación y el sofá, solo hay otras dos alternativas que se me ocurren.

Primero es simplemente no importa, el disco es barato y tener copias múltiples de los datos puede parecer una duplicación innecesaria, pero simplifica enormemente su arquitectura y obtiene algunos beneficios automáticos como escalar fácilmente para manejar la carga (simplemente moviendo algunos de los DB de los usuarios a otros servidores).

En segundo lugar, los datos compartidos se dividen en una base de datos diferente. Esto ocasionalmente limitará las cosas que puede hacer en las vistas (por ejemplo, no "Documentos enlazados"), pero esto no es un gran problema en muchas situaciones.