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

[Mariano Guerra]

Quoting Andrés Gattinoni (2013-02-14 15:55:32)
> 2013/2/12 Martin Albisetti <argentina en gmail.com>
> 
>      En Ubuntu One fuimos uno de los primeros en usar CouchDB a gran
>      escala
> 
> 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]?

personalmente yo he usado couchdb para dos proyectos en serio y varios prototipos
y siempre me sirvio, de hecho hace un anio que esta corriendo en produccion en
un lugar y lo unico que me causo problemas fue no haber habilitado la compactacion
automatica de las vistas que hizo que se llenara el disco de un server.

para full text search yo use couchdb-lucene y me funciono muy bien:

http://guide.couchdb.org/draft/
http://wiki.apache.org/couchdb/Full_text_search

esto es medio viejo pero quizas te sirve:

http://marianoguerra.blogspot.de/2009/10/mapeo-de-busquedas-de-couchdb-lucene-en.html
http://marianoguerra.blogspot.de/2009/10/haciendo-andar-couchdb-lucene-04-en.html

uno de los proyectos era un gestor de documentos y anduvo bien.

lo que te puedo decir de contra es:

* tenes que tener bien definidas las queries que le vas a hacer ya que no se
  pueden hacer muchas queries ad-hoc, eso limita un poco o te lleva a hacer la
  mitad de la logica en el server y no en couchdb, digamos, map/reduce no es muy
  flexible pero si sirve para tu caso termina siendo muy util y simple.

  esto te puede dar una idea de lo que se puede hacer si venis de sql:
  http://guide.couchdb.org/draft/cookbook.html

* siempre configura compactacion automatica de bases de datos *Y* de vistas,
  desde 1.2 es mucho mas facil ya que lo podes configurar desde couchdb.

  https://wiki.apache.org/couchdb/Compaction#Automatic_Compaction

  que esto sea periodico y en un horario donde no haya mucha actividad asi no te
  afecta

* tene un disco grande, couchdb usa bastante el disco durante cualquier tipo
  de actividad (insert, update, delete), el espacio no se reclama hasta que
  compactes y mientras compacta necesitas al menos el tamanio de la bd que estas
  compactando (como peor caso) como espacio libre en disco, esto puede ser un problema
  cuando te estas quedando sin disco y no tenes espacio libre para liberar espacio...

  lo que podes hacer es copiar la bd a otra maquina, compactar alla y traer
  la version compactada, siempre teniendo en cuenta de usar la misma version
  de couchbd para no tener problemas.

no es que te diga que couchdb es perfecta, pero anda bastante bien para los
casos que la he usado.

por lo que he leido no te recomendaria mongodb, hay mucha gente que se quemo con mongo, algunos ejemplos

* diegobasch.com/ill-give-mongodb-another-try-in-ten-years
* http://hackingdistributed.com/2013/01/29/mongo-ft/
* https://gist.github.com/mapopa/3619146

la que me gustaria probar de las nosql pero no tengo tiempo/excusa es riak,
quizas te sirve, quizas no, el tema es que se recomienda correr en un cluster
de al menos 3 nodos por lo que no es muy amistoso para cosas chicas.

una que tiene pinta pero es demasiado nueva es rethinkdb http://www.rethinkdb.com/

espero que sirva de algo,

saludos!