cambio de sistema de baja latencia

[rafael valenzuela moraleda]

Hola a todos;
Tengo una duda y la quería consultar con mas gente para tener otras
ideas. Bien estamos/queremos pasar nuestro sistema de mongoDB a
cassandra + hadoop , no se si alguien lo ha hecho ya si es así algún
consejo o advertencia?.
Por otro lado una de las condiciones nuevas es que tenga baja latencia
de respuesta? he pensado en meterle strom o algo parecido ¿Que
opináis?
a ver si me podéis dar algun nuevo consejo.
Saludos y gracias

[Marc de Palol]

Bueno, es un señor cambio :)

Qué quieres decir con que tenga baja latencia? que puedas consultar los valores desde una web por ejemplo ? Cassandra debería bastarte para esto. 

Entiendo que el caso sería: una vez al día (o X veces cada día) con Hadoop calculais lo que tengáis que calcular, lo guardais en Cassandra y desde una web hacéis las consultas real-time en cassandra. Es esto? no debería haber ningún problema. 

Storm sería más para "sustituir" el cálculo de Hadoop, así en vez de calcular los datos una vez al día (o x veces al día) con storm tendríais siempre los datos actualizados al momento, luego lo podéis actualizar constantemente en Cassandra. 

Espero no haberte liado más :) 

2013/2/12 rafael valenzuela moraleda <rav...@gmail.com>

--
Has recibido este mensaje porque estás suscrito al grupo "spain-scalability-users" de Grupos de Google.
Para anular la suscripción a este grupo y dejar de recibir sus correos electrónicos, envía un correo electrónico a spain-scalability...@googlegroups.com.
Para obtener más opciones, visita https://groups.google.com/groups/opt_out.

[Angel Java Lopez]

Hola gente!

Soy newbie en este grupo, pero me parece que no es posible esbozar una respuesta a:

Bien estamos/queremos pasar nuestro sistema de mongoDB a
cassandra + hadoop , no se si alguien lo ha hecho ya si es así algún
consejo o advertencia?.

sin saber que es "nuestro sistema"

Yo veo que Hadoop es muy orientado a Map/Reduce. Si el problema a resolver por "nuestro sistema" no tiene nada que ver con Map/Reduce, no veo el sentido de poner Hadoop en la ecuacion.

Cual es "nuestro sistema"?

Nos leemos!

Angel "Java" Lopez

@ajlopez

2013/2/12 rafael valenzuela moraleda <rav...@gmail.com>

Hola a todos;

[Iván de Praadoo]

Estoy con Angel, además también estaría bien saber por qué queréis abandonar MongoDB... ¿No os está dando el rendimiento deseado? ¿No escala bien? ¿No permite analítica batch?

Un saludo!

Iván

2013/2/12 Angel Java Lopez <ajlop...@gmail.com>

[Pere Ferrera]

Respecto a Hadoop + Cassandra, yo había hecho un proyecto así hace años (antes del producto de DataStax) y la forma en que lo resolví fue:

- Hacer un Job Hadoop que actualiza el Cassandra, así se paraleliza al máximo (supongo que hoy en día hay alternativas menos caseras...).

- El mismo Job Hadoop calculaba las Keys que había que actualizar, porque si algunas no habían cambiado no hacía falta hacer el update en Cassandra (así había menos requests a Cassandra).

Por otro lado, es una obviedad, pero los inserts/update de Cassandra han de ser "at-least-once" (y no "only-once"), o sea que si has de repetir el export no se joda nada por actualizar varias veces la misma key.

2013/2/12 Iván de Praadoo <ivan....@gmail.com>

[rafael valenzuela moraleda]

Hola a todos,
Os contesto y siento ser tan genérico.
A lo del "nuestro sistema"?" ahora mismo tenemos toda la información
en MongoDB y estamos llegando a los 12 nodos y lanzamos la
información con Node.js para conseguir lo mas parecido a "real-time" o
eso a lo que aspiran. Pero queremos tener un sistema que se pueda
escalar con cierta facilidad, modular y no tener el limite de 12
nodos. Para que te hagas una idea según mis cálculos vamos a pasar a
empezar a procesar 10 petabyte por día no creo que MongoDB pueda
alcanzar ese nivel de procesamiento. En principio no queremos analiza
en batch. ¿Necesitas alguna información más?.
Saludos

On 12 feb, 20:21, Pere Ferrera <ferrerabert...@gmail.com> wrote:
> Respecto a Hadoop + Cassandra, yo había hecho un proyecto así hace años
> (antes del producto de DataStax) y la forma en que lo resolví fue:
> - Hacer un Job Hadoop que actualiza el Cassandra, así se paraleliza al
> máximo (supongo que hoy en día hay alternativas menos caseras...).
> - El mismo Job Hadoop calculaba las Keys que había que actualizar, porque
> si algunas no habían cambiado no hacía falta hacer el update en Cassandra
> (así había menos requests a Cassandra).
>
> Por otro lado, es una obviedad, pero los inserts/update de Cassandra han de
> ser "at-least-once" (y no "only-once"), o sea que si has de repetir el
> export no se joda nada por actualizar varias veces la misma key.
>

> 2013/2/12 Iván de Praadoo <ivan.pr...@gmail.com>

>
>
>
>
>
>
>
> > Estoy con Angel, además también estaría bien saber por qué queréis
> > abandonar MongoDB... ¿No os está dando el rendimiento deseado? ¿No escala
> > bien? ¿No permite analítica batch?
>
> > Un saludo!
> >  Iván
>

> > 2013/2/12 Angel Java Lopez <ajlopez2...@gmail.com>

[Iván de Praadoo]

Hola Rafael, 

10 petabytes :O . Buen reto :-) .  Si no vais a procesar en Batch... ¿qué papel le reservas a Hadoop en tu arquitectura? No parece hacerte falta. 

Iván

[Samuel García Martínez]

Buenos días Rafael, si según tus cálculos vais a pasar a 10 Petabytes (1024*1024 Gb, recordemos) diarios, ¿qué volumen de datos tenéis actualmente en MongoDB? Es que ese volumen (aunque sea cercano) en MongoDB es bastante inasumible. 

¿Qué arquitectura de MongoDB tenéis actualmente? ¿Cuántos shards tenéis?

Te preguntarás a qué viene estas preguntas; pues si pasas por la wiki de MongoDB verás que comentan que su protocolo comienza a tocar techo cuando llegas a 1000 shards en un cluster. Asumiendo que el cambio se vea motivado por una carencia de MongoDB (12 es el límite para los ReplicaSets, pero puedes escalar con shards) y que el volumen de datos puede ser 1/10 del volumen previsto  (asumiendo una tasa de crecimiento desmadrada) y que ese número "12" que comentas sean shards, la distribución de los datos que me salen es:

* Volumen actual: 1Pb 

* 10 shard de Mongo (dices que os acercáis)

* distribución de los datos: 102,4 Tb por nodo

Lo cual es una autentica barbaridad. 

Así, a bote pronto, con los datos que tenemos y asumiendo que el volumen actual se aproxime al que yo me "invento", os harían falta unos 300 o 400 shards de MongoDB con RAM decente, sin entrar al número de índices y cardinalidad de cada uno. (MongoDB trabaja usando memory-mapped files por lo que si el documento no está en RAM, vas a incrementar algo la latencia, pero si es que si la página a consultar de los índices no está en RAM, la latencia se dispara).

¿Podrías arrojar algunos datos más?

2013/2/13 Iván de Praadoo <ivan....@gmail.com>

--
Un saludo,

Samuel García.

[Pere Ferrera]

Supongo que 10PetaBytes es el futuro, que no es lo que tienen ahora... Por otro lado me sumo a la curiosidad: queremos saber más! Menudo buen problema de Big Data!

Procesar 10 PetaBytes en tiempo real, sin procesar en batch, es algo que se escapa de mi experiencia y conocimiento... Por lo que leí con CouchDB en sharding (usando Lounge) se podría llegar a tener 256 PetaBytes con latencias mínimas (>=) de 300ms, usando árboles de proxies. Pero como las queries atacan a todos los shards, para escalar en throughput has de añadir réplicas y el coste en hardware supongo que se dispararía...

2013/2/13 Samuel García Martínez <samuelg...@gmail.com>

[Iván de Praadoo]

Si, también se escapa de la mía. Así que ves contándonos que nos tienes interesadísimos. :-)

Iván

2013/2/13 Pere Ferrera <ferrera...@gmail.com>

[Marc de Palol]

Para añadir un poco más a la conversación, ten en cuenta que cassandra y hadoop replican los datos, siempre lo puedes cambiar, pero no es recomendable, asi que como mínimo el cluster deberá tener capacidad para 30 Pb (10 x 3) esto, sólo para guardar los datos. Así que nos vamos a 60 Pb para un clúster operacional. 

A mi me parece mucho, teniendo en cuenta que los discos duros ahora mismo son de 1 Tb (los standard) estamos hablando de muchos discod duros... y muchas máquinas. Es necesario mantener todos estos datos o habrá una agregacíon?

2013/2/13 Pere Ferrera <ferrera...@gmail.com>

[rafael valenzuela moraleda]

Hola a todos,
Siento el retraso, parece que mi pregunta ha gustado, quiero contestar
por partes a ver si lo consigo en un solo correo y sin que quede muy
confuso.

>>10 petabytes :O . Buen reto :-) . Si no vais a procesar en Batch... ¿qué
>>papel le reservas a Hadoop en tu arquitectura? No parece hacerte falta.

La idea es no procesar en Batch, pero esa es la idea inicial luego la
realidad nos marcara un poco donde podemos llegar, necesitamos hadoop
para manipular los datos básicamente con lo que hadoop es parte
importante.
>> Respuesta del correo de Samuel García.
Los 10 Pb es lo que vamos a alcanzar en cuanto los clientes de USA
empiecen a usar la plataforma, nos basamos en un estudio de
volumétrica muy básico viendo lo que nos produce un usuario mas un
factor de corrección y usando unas ecuaciones de Langevin, hemos
obtenido eso (con un cierto factor de corrección como te he
comentado), ahora mismo no tenemos esa cantidad de información por eso
usamos Mongo (y por ahora nos va bien ) y es cierto Mongo no lo
soporta esa cantidad de datos como demuestran tus datos, además hemos
hablado con la gente de 10gen con lo que no creo que sea una solución
a la larga.
>>Marc de Palol
Sobre el tema de maquinas estamos usando Amazon y estamos valorando
todo (no me han dicho restricción ) de todas maneras mi intención
personal es agregar intentar pasar a un Data Warehouse básicamente
DataVault con un nivel de agregación alto, pero por ahora tengo que
decidir con los datos que me han dado.

Mi objetivo lo he dividido en dos fases
1.- Poder pasar a una arquitectura que se pueda escalar con facilidad
y que soporte mas datos que MongoDB (por ahora excluyo el problema de
10 Pb por simplificar la cuestión, que se queda ahí esperando en la
esquina, pero mi intención es pasar lo que hay a otra posible
arquitectura antes de meterme en eso)
2.- Una vez montada la arquitectura, que se pueda escalar, intentar
tener la menor latencia posible.
¿Opiniones para el punto 1?

Saludos
PD:en el BBVA manejan mas información y se están enfrentado a el
mismo problema.

On 13 feb, 13:13, Marc de Palol <phleg...@gmail.com> wrote:
> Para añadir un poco más a la conversación, ten en cuenta que cassandra y
> hadoop replican los datos, siempre lo puedes cambiar, pero no es
> recomendable, asi que como mínimo el cluster deberá tener capacidad para 30
> Pb (10 x 3) esto, sólo para guardar los datos. Así que nos vamos a 60 Pb
> para un clúster operacional.
>
> A mi me parece mucho, teniendo en cuenta que los discos duros ahora mismo
> son de 1 Tb (los standard) estamos hablando de muchos discod duros... y
> muchas máquinas. Es necesario mantener todos estos datos o habrá una
> agregacíon?
>

> 2013/2/13 Pere Ferrera <ferrerabert...@gmail.com>

>
>
>
>
>
>
>
> > Supongo que 10PetaBytes es el futuro, que no es lo que tienen ahora... Por
> > otro lado me sumo a la curiosidad: queremos saber más! Menudo buen problema
> > de Big Data!
>
> > Procesar 10 PetaBytes en tiempo real, sin procesar en batch, es algo que
> > se escapa de mi experiencia y conocimiento... Por lo que leí con CouchDB en

> > sharding (usando Lounge <http://tilgovi.github.com/couchdb-lounge/>) se

> > podría llegar a tener 256 PetaBytes con latencias mínimas (>=) de 300ms,
> > usando árboles de proxies. Pero como las queries atacan a todos los shards,
> > para escalar en throughput has de añadir réplicas y el coste en hardware
> > supongo que se dispararía...
>

> > 2013/2/13 Samuel García Martínez <samuelgmarti...@gmail.com>

> >> 2013/2/13 Iván de Praadoo <ivan.pr...@gmail.com>

[Angel Java Lopez]

Hola gente!

Rafael, gracias por los detalles.

Hay una parte que "no me cae ficha" como diriamos aca en Argentina ;-), es decir, no entiendo bien:

>>10 petabytes :O . Buen reto :-) .  Si no vais a procesar en Batch... ¿qué
>>papel le reservas a Hadoop en tu arquitectura? No parece hacerte falta.

La idea es no procesar en Batch, pero esa es la idea inicial luego la
realidad nos marcara un poco donde podemos llegar, necesitamos hadoop
para manipular los datos básicamente con lo  que hadoop es parte
importante.

Bien, pero cuando trabaja Hadoop? sobre que datos? todos? los nuevos? los de la ultima semana?

Me imagino:

- Trabaja siempre (aunque no veo como, el reduce deberia terminar en algun momento) alimentandos de cada dato nuevo que entra

- Lo lanzamos una vez por dia y procesamos todos los datos

- Hay usuarios que lanzan queries, pedidos, y Hadoop es la parte que termina trabajando para conseguir eso. Esos queries vienen una vez cada tanto, o son 1000 por segundo. Esos trabajos lanzados de Hadoop no procesan todos los datos, sino solamente algunos

Es decir, no me queda claro el caso de uso de Hadoop. O el caso de uso final

Me imagino que conociendo el caso de uso (aunque sea aproximado) se podra contestar mejor tu punto 1. 

Bueno, contesta lo que puedas, tal vez no puedas comentar todo en detalle.

Nos leemos!

Angel "Java" Lopez

@ajlopez

2013/2/13 rafael valenzuela moraleda <rav...@gmail.com>

[rafael valenzuela moraleda]

Hola,
No puedo dar mucha información, lo que estamos construyendo  es un sistema de recomendación con basado en geo-posicionamiento , tenemos que usar hadoop por que hay que procesar muchos datos y la única manera de hacerlo y con un buen resultado es hadoop.

básicamente he desarrollado unas ETL's, cuando hay un numero x de nuevos datos inserta los datos nuevos en hadoop y lanza los map/reduce correspondientes por el país.Las ETL las he creado con kettel.
Saludos

@ajlopez

> >>>> > >>> spain-scalability-users+unsub...@googlegroups.com.

> >>>> > >>> Para obtener más opciones, visita
> >>>> > >>>https://groups.google.com/groups/opt_out.
>
> >>>> > >>  --
> >>>> > >> Has recibido este mensaje porque estás suscrito al grupo
> >>>> > >> "spain-scalability-users" de Grupos de Google.
> >>>> > >> Para anular la suscripción a este grupo y dejar de recibir sus
> >>>> correos
> >>>> > >> electrónicos, envía un correo electrónico a

> >>>> > >> spain-scalability-users+unsub...@googlegroups.com.

> >>>> > >> Para obtener más opciones, visita
> >>>> > >>https://groups.google.com/groups/opt_out.
>
> >>>> > >  --
> >>>> > > Has recibido este mensaje porque estás suscrito al grupo
> >>>> > > "spain-scalability-users" de Grupos de Google.
> >>>> > > Para anular la suscripción a este grupo y dejar de recibir sus
> >>>> correos
> >>>> > > electrónicos, envía un correo electrónico a

> >>>> > > spain-scalability-users+unsub...@googlegroups.com.

> >>>> > > Para obtener más opciones, visitahttps://
> >>>> groups.google.com/groups/opt_out
> >>>> > > .
>
> >>>> --
> >>>> Has recibido este mensaje porque estás suscrito al grupo
> >>>> "spain-scalability-users" de Grupos de Google.
> >>>> Para anular la suscripción a este grupo y dejar de recibir sus correos
> >>>> electrónicos, envía un correo electrónico a

> >>>> spain-scalability-users+unsub...@googlegroups.com.

> >>>> Para obtener más opciones, visita
> >>>>https://groups.google.com/groups/opt_out.
>
> >>>  --
> >>> Has recibido este mensaje porque estás suscrito al grupo
> >>> "spain-scalability-users" de Grupos de Google.
> >>> Para anular la suscripción a este grupo y dejar de recibir sus correos
> >>> electrónicos, envía un correo electrónico a

> >>> spain-scalability-users+unsub...@googlegroups.com.

> >>> Para obtener más opciones, visita
> >>>https://groups.google.com/groups/opt_out.
>
> >> --
> >> Un saludo,
> >> Samuel García.
>
> >> --
> >> Has recibido este mensaje porque estás suscrito al grupo
> >> "spain-scalability-users" de Grupos de Google.
> >> Para anular la suscripción a este grupo y dejar de recibir sus correos
> >> electrónicos, envía un correo electrónico a

> >> spain-scalability-users+unsub...@googlegroups.com.

> >> Para obtener más opciones, visita
> >>https://groups.google.com/groups/opt_out.
>
> >  --
> > Has recibido este mensaje porque estás suscrito al grupo
> > "spain-scalability-users" de Grupos de Google.
> > Para anular la suscripción a este grupo y dejar de recibir sus correos
> > electrónicos, envía un correo electrónico a

> > spain-scalability-users+unsub...@googlegroups.com.

> > Para obtener más opciones, visitahttps://groups.google.com/groups/opt_out
> > .

--
Has recibido este mensaje porque estás suscrito al grupo "spain-scalability-users" de Grupos de Google.

Para anular la suscripción a este grupo y dejar de recibir sus correos electrónicos, envía un correo electrónico a spain-scalability-users+unsub...@googlegroups.com.

[Angel Java Lopez]

Ah! Bien, ahora voy entendiendo.

Ese dato: Hadoop opera sobre datos NUEVOS, aunque muchos, era algo que no tenia. Bien, supongo que eso influira en las respuestas que se daran a tu punto 1.

Ahora los dejo a Uds. los profesionales, 

pero lo que entendi es:

- Hay muchos datos nuevos

- Pero hay MUCHOS datos procesados y acumulados de antes (resultados de anteriores Map/Reduce)

- Datos Nuevos + Hadoop => terminan agregados o consolidades en los datos ya procesados

- Separaria el tema guardar los datos nuevos hasta que se procesen via Hadoop, del tema guardar los datos ya procesados

- El resultado del sistema (las recomendaciones) se basan en los datos ya procesados (no se, me lo imagino yo esto)

- De ahi, que se necesite alguna forma de recuperarlos (supongo alguna consulta parametrica, deme las recomendaciones del tipo X (X=Restaurante) en la zona Y (Y=Barcelona))

Nos leemos!

Angel "Java" Lopez

@ajlopez

gh:github

2013/2/14 rafael valenzuela moraleda <rav...@gmail.com>

Para anular la suscripción a este grupo y dejar de recibir sus correos electrónicos, envía un correo electrónico a spain-scalability...@googlegroups.com.

[Manuel A. Rubio "Bombadil"]

Hola,

bueno, intentando no meterte miedo, Cassandra lo probé solo en un
proyecto y ha sido el peor proyecto de mi historia :-D ... lo montamos
sobre máquinas virtuales y en cluster de dos nodos. El cálculo para
poder levantar cada nodo es un poco raro... pero lo peor fue cuando
tuvimos problemas en uno de los nodos, que si la consistencia
configurada era 2 o ALL, creaba una latencia enorme entre los nodos
mientras uno de ellos estuviese out.

Yo al final he terminando odiándolo, por lo que no creo que pueda ser
una buena referencia para ti :-P ... pero bueno, ahí queda mi
experiencia.

La verdad es que me gustó más MongoDB por su versatilidad y Riak por su
escalabilidad. Este último incluso permite hacer los map/reduce en
JavaScript inyectado, te paso un artículo que escribí hace tiempo por si
te pica la curiosidad :-)

http://bosqueviejo.net/2012/04/24/riak-revisando-y-practicando/

Un saludo.
Manuel Rubio.

[Marc de Palol]

Buenas, 

Es interesante leer opiniones sobre estos sistemas. Yo con Cassandra he trabajado bastante últimamente y la verdad no tengo una opinión muy fuerte pero en general es buena. Unos comentarios y preguntas sobre lo que has dicho entre lineas: 

bueno, intentando no meterte miedo, Cassandra lo probé solo en un proyecto y ha sido el peor proyecto de mi historia :-D ... lo montamos sobre máquinas virtuales y en cluster de dos nodos. El cálculo para poder levantar cada nodo es un poco raro... pero lo peor fue cuando tuvimos problemas en uno de los nodos, que si la consistencia configurada era 2 o ALL, creaba una latencia enorme entre los nodos mientras uno de ellos estuviese out.

Supongo que dependerá de como son las máquinas virtuales, Cassandra y Hadoop ( y cia ) requieren bastante memoria y CPU. Si miras las recomendaciones de hardware para estos sistemas normalmente son maquinotes, con mucha RAM y demás. 

Luego no entiendo mucho como formasteis el cluster. Si hay dos nodos y un nodo falla es normal que si la consistencia es 2 o ALL vaya lenta, porque básicamente no se puede cumplir. 2 (o ALL) significa que Cassandra debe escribir en los 2 nodos antes de confirmar la escritura, si uno de los dos falla no puede hacerlo. Estoy equivocado o he entendido algo mal?

La verdad es que me gustó más MongoDB por su versatilidad y Riak por su escalabilidad. Este último incluso permite hacer los map/reduce en JavaScript inyectado, te paso un artículo que escribí hace tiempo por si te pica la curiosidad :-)

http://bosqueviejo.net/2012/04/24/riak-revisando-y-practicando/

Perfecto! voy a leer los posts sobre riak cuando tenga un momento hoy, siempre he tenido mucha curiosidad!

un saludo!

[Angel Java Lopez]

Hola gente!

Interesante lo que aportan sobre su experiencia en NoSql.

En estos dias, en la lista Python Argentina, aparecio el tema de experiencias que tuvieron con NoSql. Comienza el hilo en:

http://listas.python.org.ar/pipermail/pyar/2013-February/023055.html

Es un poco largo, y no he encontrado forma de mostrar todo el dia. Pero ahi encontraran diversas experiencias por estos lares de CouchDb, MongoDb, Cassandra.

En uno de los emails finales, @ralsina creo, menciono algo que yo tenia en el radar, porque tiene una linda sintaxis de query (mentada en algun comentario por @rauchg, y coincido):

http://www.rethinkdb.com/

No creo que sirva para el problema original de Rafael, pero lo menciono porque creo que no aparecio por esta lista.

Hmmm... hasta podria hacer un code kata, implementarla directamente en Node.js, en memoria local, al menos ;-)

Nos leemos!

Angel "Java" Lopez
@ajlopez

gh:ajlopez

2013/2/15 Marc de Palol <phle...@gmail.com>

--

[Rafael Valenzuela]

Hola Marc:

Yo con cassandra he tenido un sentimiento agri-dulce por que de las veces que lo he usado, solo me fue bien cuando la gente de cassandra estaba detrás , sino tuvimos ciertos problemas.

Como ya comente en el otro correo por ahora me quiero centrar en pasar de mongo a X  y una vez que tengamos eso , miraremos el tema de latencias por que creo que es mejor ir paso a paso , por que creo que es critico tener una buena base donde asentarnos.

Yo con mongo estoy contento pero creo que cuando se pasan ciertos limites en cuestión de datos se que queda algo corta. Si tuvieras que elegir  entre cassandra y riak para mover gran cantidad de datos , ¿te quedarías con Riak? (Yo nunca la he usado).

También se esta valorando  Voldemot,Tokyo , un compañero ha comentado Neo4j (pero no alcanzo a verlo) e  Hypertable, como se puede ver estamos viendo y tocando todo (de hecho creo que hay mas palos de ciego que otra cosa) por que el crecimiento de los datos va a ser una pasada.

Saludos y gracias 

Gracias

--

Has recibido este mensaje porque estás suscrito al grupo "spain-scalability-users" de Grupos de Google.
Para anular la suscripción a este grupo y dejar de recibir sus correos electrónicos, envía un correo electrónico a spain-scalability...@googlegroups.com.
Para obtener más opciones, visita https://groups.google.com/groups/opt_out.
 
 

--
Mit forever
My Blog
My Faborite Web
http://www.technologyreview.com/

[Iván de Praadoo]

Con Voldemort tenemos experiencia. La usamos para generar los datos en Hadoop y luego hacer deployments en producción de los nuevos datos... va bastante bien para ese caso de uso, pero no parece que sea lo que queréis vosotros... 

Iván

2013/2/15 Rafael Valenzuela <rav...@gmail.com>

[rafael valenzuela moraleda]

Hola a todos,

Entonces alguna cosa mas ... lo de Voldemort me ha parecido interesante 

Saludos  

On Friday, February 15, 2013 7:20:03 PM UTC+1, Iván de Prado wrote:

Con Voldemort tenemos experiencia. La usamos para generar los datos en Hadoop y luego hacer deployments en producción de los nuevos datos... va bastante bien para ese caso de uso, pero no parece que sea lo que queréis vosotros... 

Iván

2013/2/15 Rafael Valenzuela <rav...@gmail.com>

Hola Marc:

Yo con cassandra he tenido un sentimiento agri-dulce por que de las veces que lo he usado, solo me fue bien cuando la gente de cassandra estaba detrás , sino tuvimos ciertos problemas.

Como ya comente en el otro correo por ahora me quiero centrar en pasar de mongo a X  y una vez que tengamos eso , miraremos el tema de latencias por que creo que es mejor ir paso a paso , por que creo que es critico tener una buena base donde asentarnos.

Yo con mongo estoy contento pero creo que cuando se pasan ciertos limites en cuestión de datos se que queda algo corta. Si tuvieras que elegir  entre cassandra y riak para mover gran cantidad de datos , ¿te quedarías con Riak? (Yo nunca la he usado).

También se esta valorando  Voldemot,Tokyo , un compañero ha comentado Neo4j (pero no alcanzo a verlo) e  Hypertable, como se puede ver estamos viendo y tocando todo (de hecho creo que hay mas palos de ciego que otra cosa) por que el crecimiento de los datos va a ser una pasada.

Saludos y gracias 

Gracias

El 15 de febrero de 2013 10:20, Marc de Palol <phle...@gmail.com> escribió:

Buenas, 

Es interesante leer opiniones sobre estos sistemas. Yo con Cassandra he trabajado bastante últimamente y la verdad no tengo una opinión muy fuerte pero en general es buena. Unos comentarios y preguntas sobre lo que has dicho entre lineas: 

bueno, intentando no meterte miedo, Cassandra lo probé solo en un proyecto y ha sido el peor proyecto de mi historia :-D ... lo montamos sobre máquinas virtuales y en cluster de dos nodos. El cálculo para poder levantar cada nodo es un poco raro... pero lo peor fue cuando tuvimos problemas en uno de los nodos, que si la consistencia configurada era 2 o ALL, creaba una latencia enorme entre los nodos mientras uno de ellos estuviese out.

Supongo que dependerá de como son las máquinas virtuales, Cassandra y Hadoop ( y cia ) requieren bastante memoria y CPU. Si miras las recomendaciones de hardware para estos sistemas normalmente son maquinotes, con mucha RAM y demás. 

Luego no entiendo mucho como formasteis el cluster. Si hay dos nodos y un nodo falla es normal que si la consistencia es 2 o ALL vaya lenta, porque básicamente no se puede cumplir. 2 (o ALL) significa que Cassandra debe escribir en los 2 nodos antes de confirmar la escritura, si uno de los dos falla no puede hacerlo. Estoy equivocado o he entendido algo mal?

La verdad es que me gustó más MongoDB por su versatilidad y Riak por su escalabilidad. Este último incluso permite hacer los map/reduce en JavaScript inyectado, te paso un artículo que escribí hace tiempo por si te pica la curiosidad :-)

http://bosqueviejo.net/2012/04/24/riak-revisando-y-practicando/

Perfecto! voy a leer los posts sobre riak cuando tenga un momento hoy, siempre he tenido mucha curiosidad!

un saludo!

--
Has recibido este mensaje porque estás suscrito al grupo "spain-scalability-users" de Grupos de Google.

Para anular la suscripción a este grupo y dejar de recibir sus correos electrónicos, envía un correo electrónico a spain-scalability-users+unsub...@googlegroups.com.

Para obtener más opciones, visita https://groups.google.com/groups/opt_out.
 
 

--
Mit forever
My Blog
My Faborite Web
http://www.technologyreview.com/

--
Has recibido este mensaje porque estás suscrito al grupo "spain-scalability-users" de Grupos de Google.

Para anular la suscripción a este grupo y dejar de recibir sus correos electrónicos, envía un correo electrónico a spain-scalability-users+unsub...@googlegroups.com.

[Angel Java Lopez]

Ah! hoy mencionaron en la lista de Storm algo asi

https://groups.google.com/group/storm-user/browse_thread/thread/4426ad919c1eb3bd

y ahi me volvio al radar, algo que tenia en mis enlaces
http://nathanmarz.com/blog/how-to-beat-the-cap-theorem.html

Creo que el problema de Rafael era distinto, pero los enlaces de
arriba pueden dar mas contexto para otros proyectos: "precompilar"los
resultados de hasta hace unas horas y dias, usando Hadoop, y agregar
lo "real-time" desde entonces usando Storm


2013/2/12 Marc de Palol <phle...@gmail.com>:

[Iván de Praadoo]

Buen punto, Angel. Nosotros implementamos este tipo de sistemas. Nathan (el gran gurú) llama a estas arquitecturas "lambda architecture". De hecho, desarrollamos Splout SQL (http://sploutsql.com/) con el objetivo de que sirviese para la "batch view" de una arquitectura lambda. Básicamente, sería algo más potente que el "Elephant DB" descrito en ese blog post. 

Un saludo!

Iván

2013/3/5 Angel Java Lopez <ajlop...@gmail.com>

[Angel Java Lopez]

Ah! Interesante!

Veo que ahi aplicaron Pangool.... yo estoy leyendo el paper de Uds., para hacer una implementacion de prueba del algoritmo en JavaScript y/o C#. Tengo algunas preguntas, pero ya las ordenare, y pondre en otro hilo

2013/3/6 Iván de Praadoo <ivan....@gmail.com>

[Iván de Praadoo]

Cualquier pregunta estamos encantados :-)

Iván

2013/3/6 Angel Java Lopez <ajlop...@gmail.com>