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

[Ybarra Victor J.]

Gracias Santiago, me haria falta conocer mas sobre bases de datos y sus
diferencias (entr SQL, monoDB, cassandra, etc) ... algun link interesante
para leer al respecto ?


2013/2/13 Santiago Basulto <santiago.basulto en gmail.com>

> 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.-
> _______________________________________________
> 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
>
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: <http://listas.python.org.ar/pipermail/pyar/attachments/20130213/1bc5ccf6/attachment.html>