El 27 de abril de 2014, 5:12, Jesus Cea <[email protected]> escribió: > On 26/04/14 14:46, Chema Cortes wrote: > > No sé si usarás un modelo Linda en tu "tablón de anuncios", pero este > > modelo no es precisamente de *"escabilidad infinita"*. Era su punto > > flaco, que al crecer el número de procesos el sincronismo del > > tuple-space ralentizaba bastante y hacía perder disponibilidad. > > Conozco el teorema CAP. > > En mi caso uso la idea del tablón de anuncios para enviar trabajos a los > "workers". Son trabajos idempotentes. La escalabilidad la obtengo > aumentando el número de "workers" y de tablones, y la redundancia igual. > > Lo peor que puede pasar es que un tablón quede inaccesible y sus > trabajos pendientes (o las respuestas) se pierdan. Como el trabajo es > idempotente, el cliente simplemente lo vuelve a postear de nuevo en otro > sitio. Si fue una falsa alarma, tendremos un resultado duplicado, que es > muy esporádico y que no me causa problemas precisamente por el tema de > idempotencia. > > Por ejemplo, el correo electrónico puede postar en el tablón un email y > pedir un análisis antivirus o antispam. Esta actividad es claramente > idempotente :-). > > O, en otro proyecto, generación de "tiles" para mapas. > > Como siempre, todo depende de la aplicación :). > > Lo que te dice el teorema CAP, relevante a esta discusión, es que la red > puede particionarse. En mi contexto las particiones no afectan mi > disponibilidad. Pero yo estoy hablando de workers de trabajos > idempotentes, no de almacenamiento. > > La consistencia no me afecta, porque los trabajos no requieren > coordinación ni información 100% consistente (el ejemplo del antivirus o > de los mapas). > > La disponibilidad se resuelve con la detección de caídas de tablones y > nuevo posteo de la petición. Lo peor que puede pasar es que se reciban > duplicados, triviales de eliminar. > > En resumen, la aplicación está cuidadosamente diseñada, y mi problema me > permite gestionar el trabajo así. Mi problema no es el de facebook, es > el de OpenStreetMap y sus tiles :). > > En realidad no uso múltiples tablones, sino un tablón distribuido con > ésto por debajo: http://www.spread.org/ . Lo tengo en producción hace lo > menos 10 años, posiblemente más. >
Muy interesante este proyecto. Mis felicitaciones. ¿Tema para Z-podcast? :) El teorema CAP, aunque se asocia al almacenamiento de datos, en realidad está formulado en términos de los mensajes que intercambian los nodos. Aunque tus workers estén desacoplados, los tablones no lo están. Y aunque sea un único tablón distribuido a través de spread, el mantenerlo sincronizado hace que pierda disponibilidad y/o consistencia. Se pierde disponibilidad cuando no llegan los mensajes de confirmación del último cambio; se pierde consistencia cuando los nodos dejan de recibir los mensajes de actualización. Lo que viene a decir el teorema CAP es que siempre perderás uno u otro tipo de mensajes. > > -- > Jesús Cea Avión _/_/ _/_/_/ _/_/_/ > [email protected] - http://www.jcea.es/ _/_/ _/_/ _/_/ _/_/ _/_/ > Twitter: @jcea _/_/ _/_/ _/_/_/_/_/ > jabber / xmpp:[email protected] _/_/ _/_/ _/_/ _/_/ _/_/ > "Things are not so easy" _/_/ _/_/ _/_/ _/_/ _/_/ _/_/ > "My name is Dump, Core Dump" _/_/_/ _/_/_/ _/_/ _/_/ > "El amor es poner tu felicidad en la felicidad de otro" - Leibniz > > > _______________________________________________ > Python-es mailing list > [email protected] > https://mail.python.org/mailman/listinfo/python-es > FAQ: http://python-es-faq.wikidot.com/ > > -- Hyperreals *R "Quarks, bits y otras criaturas infinitesimales": http://ch3m4.org/blog Buscador Python Hispano: http://ch3m4.org/python-es
_______________________________________________ Python-es mailing list [email protected] https://mail.python.org/mailman/listinfo/python-es FAQ: http://python-es-faq.wikidot.com/
