[pyar] [Django] syncronización entre "instancias" de una aplicación

Pumarfa pumarfa en gmail.com
Lun Jun 7 09:27:31 ART 2010


El 5 de junio de 2010 17:33, Nicolas Echaniz <nico en rakar.com> escribió:

> On Friday 04 June 2010 18:47:37 Facundo Batista wrote:
> > 2010/6/4 Nicolas Echaniz <nico en rakar.com>:
> > > Para un proyecto en el que estoy empezando a trabajar, una de las
> > > necesidades es que si tengo la aplicación instalada en diferentes
> > > servidores, todas esas "instancias" puedan sincronizar su información
> > > (no hace falta que sea real- time).
> >
> > La información ya está en DB? O estás explorando DB como mecanismo
> > sincronizador?
>
> Aclaro un poco más.
>
> El proyecto es el repositorio de cultura libre (libros, audio, video, etc.)
> del que venimos hablando con algunas gentes desde hace tiempo.
> Y la idea con esto es que pueda haber más de un repositorio corriendo en
> diferentes lugares (servidores que pueden estar en diferentes países
> inclusive) pero que estos repositorios coordinen la información que tienen
> de
> manera que uno pueda acceder al repositorio completo desde cualquier
> "instancia" y si una muere la información siga disponible en las otras.
>
> Cuando yo empecé a plantear esta idea del repositorio de cultura libre, en
> realidad se me ocurrió pensando en los repositorios de software que
> mantienen
> las distribuciones de GNU/Linux.
>
> Voy a mirar un poco las cosas que mandaron. PyReplica suena interesante,
> principalmente porque todo lo demás que vi estaba hecho en Perl : ) y
> también
> porque el autor es Mariano : P
>
> Por lo que estuve leyendo de multi-master, una tecnica que se utiliza es
> determinar el incremento de los campos autoincrement de la base en función
> de
> cuántos servidores van a estar replicándose, para evitar los conflictos de
> ID
> que se generarían si todos incrementaran de a un paso, pero eso en este
> caso
> no serviría porque yo no sé de antemano cuántos servidores puede haber.
> Seguiré leyendo/investigando y voy a mirar un poco más de PyReplica, a ver
> si
> es un buen camino.
>
> Un tema a considerar es que no me preocupa si es un proceso que se puede
> disparar una vez por semana y apagar el ABM durante el tiempo que dure la
> sincronización.
>
> Por otro lado me imagino que habría que hacer rsync entre servidores para
> sincronizar efectivamente los archivos de video, audio, documentos, etc. a
> los
> que estaría haciendo referencia la base de datos.
>
>
>
Por la complejidad derivada de la sincronización,necesidades del proyecto,
etc... ¿han planteado usar otro motor de DB? Las bases de datos
"Estructurales" no se llevan bien con el hecho de tenerlas "distribuidas"  y
sincronizadas...

Me atrevo a sugerir, en mi inexperiencia, usar CouchDB completamente
soportado en Python y que permite escalar y sincronizar de forma nativa; sin
agregados...

En definitiva. Cualquier solución tendrá su costo... Usar CouchDB significa
desacoplar la gestión de DB de Django para reemplazarlo.


-- 
"El software libre es el nuevo continente que hemos construido en el
ciberespacio, y por ser virtual tiene campo para todos".
-R.Stallman.

"Hoy en día llaman libertad de expresión a la libertad que tienes de hablar
sin que nadie te escuche" - David Bravo Bueno

16 resmas = 1 arbol. Razón suficiente para pensar si es necesario imprimir
este correo
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: <http://listas.python.org.ar/pipermail/pyar/attachments/20100607/280c3dbf/attachment.html>


More information about the pyar mailing list