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

Ariel Camino arielcamino en gmail.com
Jue Feb 14 12:07:06 ART 2013


El 14/02/13 11:55, Andrés Gattinoni escribió:
> 2013/2/12 Martin Albisetti <argentina en gmail.com
> <mailto:argentina en gmail.com>>
> 
> 
>     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!
> 
> 
> Muchas gracias por este, y por los demás comentarios de todos! Me han
> dado mucho para pensar!
> 
> Definitivamente no estoy casado con CouchDB, fue una primera opción
> porque me resultaba cómodo el tema de almacenar todo en JSON. Pero voy a
> explorar otros motores a ver si alguno me convence más.
> 
> De todas formas, el escenario que estoy pensando no va a necesitar
> escalar mucho. Incluso haciéndolo con MySQL, seguramente funcionaría sin
> dramas, pero ya que tengo la oportunidad y que por el tipo de
> información parece adecuado, tengo ganas de salir un poco de mi comfort
> zone y probar algo nuevo :)
> 
> Me viene muy bien lo que decís, Martín, sobre el tema de las bases de
> datos y los archivos. En mi caso no me serviría tener una DB por
> usuario, porque la idea es que haya una única DB igual para todos, a la
> que todos puedan contribuir y es probable que unos pocos usuarios creen
> los recursos y la mayoría sólo los consulte. Pero capaz puedo pensar
> algún otro criterio para fragmentar la información.
> 
> Rescato también la opinión de varios de que para manejar los usuarios,
> autenticación, etc. me conviene utilizar una DB relacional.
> 
> Otra cosa que todavía no he tenido oportunidad de investigar, y que me
> podría hacer reconsiderar el motor de base de datos, es qué pasa con
> estas DBs No-SQL y las búsquedas. En lo que vengo leyendo, veo que
> Couch, por ejemplo, me serviría muy bien para tener los recursos
> taggeados y hacer un map reduce de los tags, etc. Pero qué pasa si
> necesito hacer búsquedas full text en varios campos de los recursos? Me
> serviría? Y funcionaría mejor que, digamos, una DB MySQL con índices
> fulltext o que un motor como Sphinx [0]?
> 
> Saludos,
> 
> A
> 
> [0] http://sphinxsearch.com/
> 

Para las búsquedas te recomiendo que veas haystack, podes usar un engine
fácil de configurar como whoosh para arrancar y luego pasar a algo más
potente (o incluso usar varios engines al mismo tiempo):
http://haystacksearch.org/

Saludos!
-- 
Ariel Camino



More information about the pyar mailing list