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

[Andrés Gattinoni]

2013/2/12 Martin Albisetti <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/
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: <http://listas.python.org.ar/pipermail/pyar/attachments/20130214/4142798d/attachment.html>