[pyar] Caché para clusters?

QliX=D! [aka EHB] qlixed en gmail.com
Vie Mayo 10 18:59:12 ART 2013


Y si a eso le agregas una notificacion de dirty? Asi P1 al cambiar los
datos vos le avisas a todos los Pn que esa haskey esta modificada...
Asi durante el tiempo t que tarda en serializar un memcache de un equipo al
otro los Pn ya saben que tienen que esperar, o que le tienen que pedir a P1
la vopua de hashkey...
El may 10, 2013 3:48 PM, "Claudio Freire" <klaussfreire en gmail.com> escribió:

> 2013/5/10 Angel Java Lopez <ajlopez2000 en gmail.com>:
> > La unica interpretacion que se me ocurre es:
> >
> > - En proceso, cache en memoria, primer nivel, de objetos, datos, lo que
> sea,
> > cada uno con un Id, digamos A1, A2, en la maquina A
> > - Lo mismo, en proceso, cache en memoria, primer nivel, de objetos,
> datos,
> > lo que sea, cada uno un Id, digamos B1, B2, en la maquina B
> > - Y asi
> > - A su vez, la maquina/proceso B sabe que existen A1, A2, ... en A, pero
> no
> > tiene los datos, evitando la serializacion innecesaria
> > - Lo mismo, la maquina/proceso A sabe que existen B1, B2, ... en B, pero
> no
> > tiene los datos, evitando la serializacion innecesaria
> > - Cuando un cliente le pide a B, que trabaje o haga algo con B1, B ya lo
> > tiene, en memoria
> > - Cuando un cliente le pide a B, que trabaje o haga algo con A1, B se lo
> > pide a A, porque sabe que lo tiene A, y que el mismo B no lo tiene, ahi
> va
> > la serializacion
> > - Cuando un cliente le pide a B que trabaje o haga algo con A1, B dice:
> "Ah,
> > ya lo tengo", y usa el de su propio proceso
> > - Cuando algo cambia en A1, A le avisa a todas las maquinas: "che, A1
> tiene
> > una nueva version".
> > - B, al enterarse de eso, y para aliviar memoria local, libera su copia
> de
> > A1, que esta "obsoleta".
> > - Un cliente le pide algo a B, que involucra trabajar con A1. B le pide
> la
> > copia a A, y asi...
> >
> > y asi...
> >
> > Es eso lo que se necesita?
>
> Sisi, eso quería decir, exacticamente. Disculpen la latencia, estoy a mil
> ;-)
>
> Una manera bastante directa de lograr esto, pero sin garantías de
> coherencia o duplicación de trabajo, es:
>
> - Primera capa, en memoria del proceso P1 .. Pn
> - Segunda capa, en memcaches M1 .. Mk
> - Cuando P1 no encuentra en su propio cache, mira en memcache Mj (j =
> hash(key))
> - Cuando Pn no encuentra en su propio cache, mira en memcache Mj (j =
> hash(key))
> - Cuando P1 computa algo, lo mete en su caché, y en memcache
> asincrónicamente (en background, serializa).
> - Cuando P2 busca lo que computó P1, no lo encuentra en su caché, pero
> sí en memcache. Lo copia a su cache (deserializa).
> - De ahora en más, cuando P1 o P2 necesitan ese dato, lo tienen
> localmente, no necesitan serializar/deserializar.
>
> Esto ya lo tengo implementado[0]. Sólo necesito inspirarme un poco
> para un protocolo de coherencia eficiente. Pensaba, si existía ya
> algo, capaz aprender de lo ya hecho en vez de reinventar ruedas.
>
> 2013/5/10 Luis I. Facciolo <lifacciolo en gmail.com>:
> > Lo que te podría decir al respecto de este tipo de cosas, es que te
> fijes la
> > implementacion de MPI para python (http://mpi4py.scipy.org/) y veas como
> > maneja la interaccion de datos entre los miembros del cluster, a ver si
> eso
> > te da una mano con esto.
>
> Estoy viendo algo parecido pero más copado, ZMQ[0]. Para los que
> pregunten, consideré AMQP, pero como necesita un broker medio que
> rompe mi idea de decentralización. Y ZMQ es la evolución de AMQP (está
> hecho por los diseñadores de AMQP).
>
> [0] https://bitbucket.org/claudiofreire/chorde/overview
> [1] http://www.zeromq.org/
> _______________________________________________
> 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
>
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: <http://listas.python.org.ar/pipermail/pyar/attachments/20130510/42fde874/attachment.html>


More information about the pyar mailing list