[pyar] Caché para clusters?

[Angel Java Lopez]

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?

Angel
@ajlopez



2013/5/10 Luis I. Facciolo <lifacciolo en gmail.com>

> Perdón que me cuele así de metido, pero según lo que entendí, vos estas
> preguntando si existe, hoy, aplicado y funcionando, una especie de "Quantum
> entanglement"[0] para cachear data in-process en clusters?
>
> O entendí cualquier cosa? Porque la verdad que si existe algo que te
> mantenga datos, dentro de procesos, sincronizados, completamente
> transparente al proceso y que no tenga que serializar las cosas para mandar
> de elemento a elemento del cluster lo quiero conocer yo también!
>
> Perdón si no se entiende lo que quiero decir, pero me interesa mucho el
> tema de programación en paralelo y quiero entender bien de que estamos
> hablando.
>
> Saludos!
>
>
> [0] https://en.wikipedia.org/wiki/Quantum_entanglement
>
>
> El 10 de mayo de 2013 10:16, Santiago Basulto <santiago.basulto en gmail.com>escribió:
>
> Coincido con Angel. El último email me desclocó pa' siempre (como
>> diría el gran Luis Landriscina).
>>
>> 2013/5/10 Angel Java Lopez <ajlopez2000 en gmail.com>:
>> > Hola gente!
>> >
>> > Hmmm... no entendi. A ver, primera capa en cache, en memoria, in
>> process.
>> >
>> > Pero tmb cluster coherente? Es decir que lo que tenga el nodo A,
>> tambien lo
>> > tenga el nodo B?
>> >
>> > Me pierdo en esos requerimientos: in process, pero distribuido y
>> coherente.
>> > Supongo que hablas de distintas capas, es asi? Pero entonces, si algo
>> tiene
>> > "orden de los MB" no vas a zafar de serializarlo para que si eso nace
>> en A,
>> > aparezca en B para que cualquiera que lo pida en B, tambien lo tenga.
>> >
>> > Podras dar el contexto? caso de uso? fuerzas que te llevan a eso?
>> >
>> > Porque con mas contexto, se puede ver mejores soluciones, no solo
>> cache. Tal
>> > vez hay otra forma de hacerlo que evite "orden de los MB" viajando de un
>> > lado al otro. No se.
>> >
>> > Nos leemos!
>> >
>> > Angel "Java" Lopez
>> > @ajlopez
>> >
>> >
>> >
>> > 2013/5/10 Claudio Freire <klaussfreire en gmail.com>
>> >>
>> >> 2013/5/9 Santiago Basulto <santiago.basulto en gmail.com>:
>> >> > Hola Claudio. Es una temática media complicada de la que hablás. Roza
>> >> > la ciencia oscura.
>> >> >
>> >> > Lo único que he escuchado similar es utilizando Apache Cassandra.
>> Hace
>> >> > mucho que no lo utilizo, pero recuerdo que habían formas de utilizar
>> >> > una cache en memoria. Aparte Cassandra tiene (o tenía al menos) el
>> >> > concepto de Particioner, al cuál podés llegar a setearle algún tipo
>> de
>> >> > afinidad y manejar la caché de acuerdo a eso. De todas maneras, creo
>> >> > que lo principal primero es pensar en la arquitectura distribuída (el
>> >> > cluster) y después encargarse de que cada nodo pueda o no cachear en
>> >> > memoria.
>> >>
>> >>
>> >> Usé cassandra, y no me convención. En principio, usa Thrift, que es
>> >> muy pero muy frágil.
>> >>
>> >> Pero más allá de eso, lo que no me convence de usarlo en este contexto
>> >> es que necesitás serializar todo hacia Cassandra, lo cual en mi caso
>> >> (con result sets a cachear en el orden de las decenas de MB) es
>> >> prohibitivo, al menos para la primer capa, la de más frecuente acceso.
>> >>
>> >> Capaz que debería haber hecho hincapié: la primer capa, no es sólo en
>> >> memoria. Es in-process. O sea, dentro mismo de Python, salir del
>> >> proceso cuesta serialización, que con valores en el orden de los MB
>> >> es... indeseable.
>> >> _______________________________________________
>> >> 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
>> >
>> >
>> >
>> > _______________________________________________
>> > 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
>>
>>
>>
>> --
>> Santiago Basulto.-
>> _______________________________________________
>> 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
>>
>
>
> _______________________________________________
> 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/1109769a/attachment.html>