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

Thu Feb 18 11:37:41 GMT 2010

Había leido mal y pensaba que hablabas de mongodb. Si quieres mejorar
performance tengo entendido que mucho mucho mucho más rápido Mongo que
Couch. Los colegas de Xing (en la presentación de la conferencia rails) en
los benchmarks ponían a couch db bastante más lento que un mysql normal.
Mongo db estaba por el estilo. Pasar a una BD no relacional no creo que te
aporte ninguna mejora de performance, solo de escalabilidad pero... no creo
que tu problema ande por ahí.

En cualquier caso, el optimizar la tarea para que vaya más rápido no creo
que te ayude a que el tema sea escalable. Si ahora tarda 4mins con 15.000
usuarios, y lo optimizas a que tarde 1min, cuando llegues a los 60.000 ,
estarás igual. Eso si es que el tiempo crece lineal y no exponencialmente.
El tema sería hacer cálculos distribuidos, o simplemente intentar eliminar
el tema de cálculos periódicos, o tener algo en plan "ir calculando
constantemente al ritmo que pueda".

Una ida de olla que supongo que no hará falta es calcular los valores
dinámicamente. Guardar un campo DateTime y el valor que tenía en ese punto
concreto, y a la hora de usarlo calcular su valor "actual" como el valor +/-
lo que tendría que haber aumentado desde entonces. Con esto puedes
actualizar el valor periódicamente, pero no es crítico.

Vamos, solo una idea.
Ánimo Albert!
--
{ :name => "Albert Llop" }

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
> 
> 
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.simplelogica.net/pipermail/ror-es/attachments/20100218/e24c94e4/attachment.htm 