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

[Esteban Feldman]

Mariano Guerra wrote:
>
> 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!
> _______________________________________________
> 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


@Martin Albisetti

Nunca evaluaron MongoDB? O si lo hicieron, por que la descartaron?

Saludos.

Eka
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: <http://listas.python.org.ar/pipermail/pyar/attachments/20130214/146ba964/attachment.html>