[pyar] Caché para clusters?

Alejandro Santos listas en alejolp.com
Vie Mayo 10 18:33:29 ART 2013


2013/5/10 Claudio Freire <klaussfreire en gmail.com>:
> 2013/5/10 Alejandro Santos <listas en alejolp.com>:
>> 2013/5/10 Claudio Freire <klaussfreire en gmail.com>:
>>> 2013/5/10 Alejandro Santos <listas en alejolp.com>:
>>>> 2013/5/10 Claudio Freire <klaussfreire en gmail.com>:
>>>>>
>>>>> 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.
>>>>>
>>>>
>>>> Si buscás "coherencia" vas a tener que implementar un mecanismo de
>>>> transacciones distribuidas eficientes.
>>>>
>>>> No se si te estoy entendiendo bien, pero me parece que buscás algo que
>>>> ni siquiera el App Engine ofrece.
>>>
>>>
>>> Es cierto, mi requerimiento es de coherencia eventual nomás. Pero
>>> podría hacerse mejor que eso, esperando confirmaciones. Horrible, pero
>>> posible.
>>>
>>
>> Solo para confirmar que estamos hablando de lo mismo, ¿lo que ganás en
>> eficiencia distribuyendo la carga entre multiples hosts lo perdés
>> esperando la confirmación?
>
>
> No necesariamente. El tradeoff es muy dependiente de la aplicación, y
> del criterio de balanceo de carga. La invalidación es sincrónica, así
> que siempre vas a pagar un roundtrip. Pero es más que posible que el
> cálculo tarde más que el roundtrip, y el costo se amortice. La
> notificación puede ser async, paralela al cómputo, sólo tiene que
> sincronizar en algún punto muy dependiente de la aplicación.
>
> Imaginate:
>
> deletion = manager.fire_deletion(key)
> hacer_algo()
> deletion.wait()
> return
>

Claro, además es un precio a pagar solo para las escrituras o
borrados. Las lecturas son gratis.

--
Alejandro Santos



More information about the pyar mailing list