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

[Santiago Basulto]

Victor. Los motores que estaban discutiendo son orientados a documento
(el modelo de datos) y se dicen "schemaless", es decir que no los
datos adentro pueden ser heterogeneos. Podés guardar una persona con
atributos "nombre" y "apellido" y otra con "nombre" y "dni". No tiene
restricciones de ese tipo. Andrés va a lidiar con ese tipo de
problemas.

Ahora sí, para responderle a Andrés. Como dice Juán, yo usaría lo
standar para la autenticación y todo el resto. Usaría un No-SQL para
el caso en particular, así también es más fácil la administración
(migrarlo, escalarlo, backups, etc). No es lo mismo replicar un
datastore que maneja documentos simples que uno que maneja sesiones,
por ejemplo. En cuanto a la elección, todo depende de la escala. Usé
CouchDB hace mucho tiempo, tuve buenas experiencias pero a muy pequeña
escala. Creo que lo que comenta Martín es determinante. Ellos lo
usaron a gran escala.

La otra opción obvia es MongoDB. Mongo lo usé más, y siempre tuve
buenas experiencias. Aunque también tiene sus cosas raras y hay mucha
gente que lo odia. Acá hay un post muy bueno:
http://blog.engineering.kiip.me/post/20988881092/a-year-with-mongodb

Cassandra no me parece una buena elección. Si bien hace mucho que no
lo uso, el modelo de datos es más complicado y la administración
también. Se que hicieron todo más fácil desde la última vez que lo
usé, pero no creo que sea tan simple como MongoDB.

En fin. Tirate y probá. Como recomendación, no confíes en ninguno de
estos motores NoSQL.

2013/2/13 Ariel Camino <arielcamino en gmail.com>:
> El 12/02/13 20:56, Martin Albisetti escribió:
>> 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!
>>
>>
>
> Muy interesante tu experiencia Martin, aprovecho para hacerte dos consultas:
>
> 1- ¿Qué versión de couchdb estaban usando aprox?
> 2- Crees que el hecho de que Damien Katz, el creador de couchdb
> abandonara el proyecto y diga que "El futuro es couchbase" [0] influyó
> negativamente al proyecto?
>
> Saludos!
> --
> Ariel Camino
>
> [0] http://damienkatz.net/2012/01/the_future_of_couchdb.html
> _______________________________________________
> pyar mailing list pyar en python.org.ar
> http://listas.python.org.ar/listinfo/pyar
>
> PyAr - Python Argentina - Sitio web: http://www.python.org.ar/
>
> La lista de PyAr esta Hosteada en USLA - Usuarios de Software Libre de Argentina - http://www.usla.org.ar



--
Santiago Basulto.-