[pyar] Django y CouchDB, ¿cómo pensarlo?

[Martin Albisetti]

2013/2/12 Andrés Gattinoni <andresgattinoni en gmail.com>:
> Hola listeros:
>
> Les cuento: estoy tratando de armar un sitio cuyo objetivo es gestionar una
> base de datos colaborativa de "recursos". En este caso, un "recurso" es un
> conjunto heterogéneo de datos, que varía según el tipo de recurso (puede ser
> información sobre una revista, en cuyo caso los datos serán unos, o de una
> biblioteca, en cuyo caso los datos serán otros) [0].
>
> Por la necesidad de flexibilidad, entonces, me pareció que sería una buena
> oportunidad para incursionar en las bases de datos No-SQL y,
> particularmente, en CouchDB.
>
> El tema es que estoy teniendo dificultades para pensar cómo diseñar mi
> aplicación de Django con los conceptos, nuevos para mí, de CouchDB. Estoy
> leyendo la guía de CouchDB [1], también empecé a experimentar con la
> extensión para Django de CouchDBKit [2], y leí algunas guías sobre cómo
> trabajar con Django y CouchDB [3], y todas estas cosas me sirvieron para
> entender más o menos qué es CouchDB y cómo hacer para hablar con el servidor
> de CouchDB desde Django. Pero me resuelven el problema conceptual de cómo
> plantear mi aplicación.
>
> Por ejemplo: ¿cómo me conviene manejar el tema de la gestión y autenticación
> de usuarios? ¿me conviene hacerlo a través de CouchDB (con su sistema de
> autenticación), codear un modelo de usuarios que labure con CouchDB como
> backend, o manejar los usuarios en una DB relacional con todas las cosas
> bonitas de Django?
>
> También tengo otras dudas más específicas sobre el tipo de app que quiero
> hacer yo, pero no quiero hacer el mail mucho más largo. Si alguno me puede
> tirar una punta sobre dónde leer, o cómo empezar a pensar mejor esto,
> estaría muy agradecido.

En Ubuntu One fuimos uno de los primeros en usar CouchDB a gran escala
y lo hicimos a traves de Django.
Lo primero para decirte es que fue un grave error haber empezado a usarlo  :)
Puedo entrar mas en detalle si te interesa, pero nuestra experiencia
en general es que a nivel operacional (mantener el servidor con
CouchDB vivo) es impredecible. Trabajamos muy de cerca con soporte
pago y aun asi no pudimos hacerlo andar confiablemente.
Mi sugerencia seria mirar otra alternativa NoSQL, que hay muchas, como
MongoDB o Cassandra.

Dicho todo eso, nosotros decidimos crear una base de datos por
usuario, para tener una separacion clara en disco de los documentos, y
para que los usuarios pudiesen replicar sus bases de datos localmente.
La autenticacion la haciamos en Apache, adelante de CouchDB, con un
patch al codigo de Couch para que eso funcione bien. Esta forma de
autenticar despues nos limito mucho en que otros frameworks y
herramientas podiamos usar, asi que salvo que necesites mucha garantia
que los documentos quedan separados, no hagas eso  :)
Separar todo en bases de datos tambien despues nos dejo shardear
facilmente, Apache mismo redirigia el request al servidor indicado
segun el user id (que sea todo http es fantastico).
Para hablar con Couch desde django escribimos nuestra propia capa (que
no es codigo libre, ni codigo usable!) para hacerlo, sobre todo para
manejar conflictos y ese tipo de cosas. Seguro que CouchKit te lo da
resuelto eso.
Volviendo al tema de la autenticacion, creo que la primer pregunta que
tenes que hacerte es como vas a distribuir las bases de datos. Va a
ser una gran base de datos con muchos documentos?  (cuidado! terminas
con un archivo de 720GB :))  Va a ser una base de datos por usuario?
(vas a tener que buscar una buena forma de autenticarlas)
Creo que si no vas a dar accceso externo a la gente para replicar sus
bases, yo no usaria el sistema de autenticacion de Couch. Hablaria
como admin desde Django y manejaria la autenticacion ahi mismo (quizas
con el user id como parte del nombre de la base de datos, o algo del
estilo).

Puedo entrar en mas detalle de cosas puntuales que quieras saber, si
es que no logre que eligieras otra base de datos mas... cuerda!


-- 
Martin