Ideas de Storm en Node.js

[Angel Java Lopez]

Hola gente!

Les escribo desde Buenos Aires, Argentina. Siempre resulta interesante leerlos, para aprender de este gran tema.

He estado escribiendo mis primeras versiones de mi "pet project":

https://github.com/ajlopez/SimpleStorm

donde trato de reimplementar ideas de Storm, en Node.js.

Tengo:

- Un simple topology builder, con shuffleGrouping

- La capacidad de ejecutar localmente una topologia

- La capacidad de ejecutar varios procesos, una misma topologia (sin deploy, el codigo esta en cada maquina/proceso ya instalado)

- Puedo comunicar topologias iguales entre procesos, usando un servidor central para intercambiar sus direcciones

Un ejemplo de web crawler local

https://github.com/ajlopez/SimpleStorm/tree/master/samples/WebCrawler

Un ejemplo de web crawler distribuido:

https://github.com/ajlopez/SimpleStorm/tree/master/samples/Workers

Claro que Storm se tiene que implementar de forma diferente en Node.js (donde no hay concepto de multithreading para el JavaScript que se escribe).

Preferi no tener prepare en los bolt/stouts, sino mas bien enviar un contexto (un objeto auxiliar) en cada llamada, ademas del mensaje.

El mensaje es un simple objeto capaz de serializarse a Json, asi que no hay que declaran tuplas, campos, etc...

Espero haber entendido el concepto. Criticas, sugerencias, preguntas, bienvenidas!

Proximos pasos:

- Deploy (podria ser un "paso nulo" porque hay proyectos en Node.js que se encargan de eso)

- Mas ejemplos

- Anchoring, etc..

Nos leemos!

Angel "Java" Lopez

@ajlopez

gh:ajlopez

[Iván de Praadoo]

Interesante Angel!

No se casi nada de Node.js, así que no puedo aportar mucho.

Gracias por compartir!

Iván

2013/1/27 Angel Java Lopez <ajlop...@gmail.com>

[Pere Ferrera]

Hola Angel,

Muy interesante. ¿Te has planteado algún tipo de fail-over? En Storm, cada Tupla lleva un identificador y se puede dar "luz verde" (ack()) o roja expresamente. También hay un timeout para que si ha pasado algo se vuelva a reintentar esa Tupla en otro lado. Todo eso se puede hacer porque hay un sistema de coordinación central: ZooKeeper. 

Para mi es de lo más interesante que tiene Storm, entonces me pregunto si en tu proyecto también habías pensado implementar algo así.

Un saludo,

2013/1/27 Angel Java Lopez <ajlop...@gmail.com>

Hola gente!

[Angel Java Lopez]

Hola gente!

Gracias por los comentarios y el interes.

Si, Pere, tengo pensado el:

- ack

- y transaction

pero primero queria explorar casos de uso "light-weight". Por ejemplo, pude poner el web crawler con una cantidad dinamica de workers (en mi jerga, no necesariamente la de Storm, es un proceso Node.js ejecutando la topologia). Asi, una tarea de web-crawling puede tener mas workers a la noche, cuando hay mas maquinas libres, digamos, y luego retirarse en algun momento. En la implementacion actual, los mensajes que una maquina que se retira esta procesando, se pierden. Pero es lindo ver como el web crawler sigue trabajando, aun cuando retire o sume algun proceso en caliente.

Una cosa que me di cuenta: para implementar web crawler distribuido, ejecute varias topologias locales, es decir, que no se comunican entre si ni conocen de otros workers. Solo me basto tener en una maquina dos colas: los enlaces pendientes de procesar, y los nuevos enlaces descubiertos por los workers. 

Primer paso para mejorar en ese caso:

- El mensaje de nuevo enlace no se retira de la cola central, si no se termina de procesar en la topologia local

- Ahi podria poner el primer caso de ack

Luego de ese caso "local" (cada topologia ejecutando no conoce de las demas instancias) pero "distribuido" (al final, comparten colas para resolver el trabajo), puse lo de: una topologia local podria recibir y enviar mensajes a otros workers. Por lo que entendi, Storm tiene un shuffle de los mensajes entre las distintas tasks, aun cuando esten en distintos workers/maquinas. Tambien vi que tiene una variante (no recuerdo como se llama), local y algo mas, donde se prefiere enviar el mensaje a una task local antes de a otra en otro proceso. Bueno, algo asi hago ahora: mi implementacion prefiere enviar el mensaje a una task local antes que a otra remota.

Ahi tendria que pensar un ack distribuido, veremos! ;-)

Por ahora, el proyecto es bastante liviano: se puede ejecutar multiplataforma (puedo usar maquinas con Windows, mezcladas con Linux, OS/X, pero no hice una prueba concreta, deberia revisar si no me equivoque en el nombre de algun host, otro ejemplo en otro proyecto, que tambien usa mensajes distribuidos, lo di en un curso y los asistentes lo ejecutaron sin problema en las tres plataformas), y es facil de instalar (Node viene con un instalador de paquetes, NPM, que es una preciosura ;-)

Nos leemos!

Angel "Java" Lopez

@ajlopez

2013/1/28 Pere Ferrera <ferrera...@gmail.com>