[Ror-es] Pasar una tabla en concreto a un sistema tipo CouchDB

Thu Feb 18 11:34:15 GMT 2010

Me viene de perlas la mención a MongoDB para enviar este artículo de hace
unas semanas, pero que creo que no se había compartido en la lista (aunque
supongo que siendo de Nunemaker muchos lo habréis leido ya)

http://railstips.org/blog/archives/2009/12/18/why-i-think-mongo-is-to-databases-what-rails-was-to-frameworks/

El otro día Diego Fernández nos hizo una presentación interna sobre MongoDB
y MongoMapper y tenemos ganas de probarlo en un proyecto real


2010/2/18 Marcelino Llano 

> echadle un vistazo a mongodb[1]
> mejor documentado, integrado y creo que en general mejor solución
> yo probé CouchDB hace unos meses y me pareció por terminar
> no sé ahora
>
> [1] http://www.mongodb.org/display/DOCS/Home
>
> El 18/02/2010, a las 10:42, Borja Martín escribió:
>
> Buenas,
> tengo mis dudas de que vayas a ganar excesiva velocidad en los
> updates/inserts ya que donde realmente creo que podrías ganarla sería a la
> hora de recuperar los datos ya que couchdb usa internamente un árbol-b para
> guardar los documentos de las vistas, por lo que a la hora de crearlos
> deberá seguir manteniendo el árbol balanceado, pero vamos, sería cuestión de
> que te hagas tus propios benchmarks
> si son procesos tan pesados, a lo mejor lo que interesaría sería
> realizarlos de manera distribuida entre varias máquinas y así te tardarían
> menos aunque el 'esfuerzo' computacional sea el mismo, pero yo con estos
> temas ya me pierdo un poco
>
> Saludos
>
> 2010/2/18 Albert Callarisa 
>
>> Hola,
>>
>> Tengo una tabla en mi aplicación que relaciona cualquier cosa
>> (polimórfica) con productos y añade un atributo asociativo 'amount'.
>> La tabla tiene los siguientes campos: owner_id, owner_type, owner_field,
>> product_id y amount
>> el owner_field es porque un mismo owner (por ejemplo Construction) puede
>> tener varios conjuntos de productos (por ejemplo los que necesita para
>> construir y los que genera)
>>
>> En la aplicación tengo dos procesos periódicos que usan muchísimo esta
>> tabla, haciendo unos 30 inserts o updates por cada usuario y ésto puede
>> aumentar en función de los productos que tenga el usuario. He probado con
>> 15000 usuarios y el proceso pequeño me tarda 4 minutos. Lo quería lanzar
>> cada 5 minutos así que no es viable.
>>
>> Total, me he planteado pasar solamente esta tabla a couchdb porque me
>> parece que irá mucho más rápido el manejo de tantos cambios pero no estoy
>> del todo seguro. El cambió hará que no pueda hacer joins con esa tabla en el
>> SQL pero puedo hacerme una capa de código que trabaje con la tabla en el
>> couchdb. Tampoco soy ningún experto en couchdb, solo que tengo la impresión
>> de que iría mucho más rápido para hacer tantos inserts/updates
>>
>> Qué me recomendáis?
>>
>> Gracias.
>>
>> --
>> Albert Callarisa Roca
>> http://www.acroca.com
>>
>> _______________________________________________
>> Proudly free of Ruby Forum crossposting since 01/07/2009
>> Ror-es mailing list
>> 
>> 
>>
>>
>
>
> --
> def dagi3d(me)
>  case me
>    when :web then  "http://dagi3d.net"
>    when :twitter then "
>  end
> end
> _______________________________________________
> Proudly free of Ruby Forum crossposting since 01/07/2009
> Ror-es mailing list
> 
> 
>
>
>
>
> Marcelino Llano
> 
>
> Por favor, no imprimas este email o sus adjuntos si no es necesario.
> Please, do not print this email or its attachments if it is not necessary.
>
>
> _______________________________________________
> Proudly free of Ruby Forum crossposting since 01/07/2009
> Ror-es mailing list
> 
> 
>
>


-- 
Manuel,
https://simplelogica.net + http://www.logicola.net/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.simplelogica.net/pipermail/ror-es/attachments/20100218/d70011d7/attachment-0001.htm