desarrollo deaAplicacion grande

[Rodrigo Fuentealba]

El 24/09/07, Alvaro Herrera <alvherre en alvh.no-ip.org> escribió:
> Ricardo Mun~oz A. escribió:
> > cierto. pero depende del modelo y la aplicacion si es que en algun momento
> > se puede producir un conflicto... por algo los mismos desarrolladores de
> > Slony-I indican que sirve cuando todos los nodos estan disponibles todo el
> > tiempo...
>

Estás poniendo a Slony-I para que se adapte a tu modelo, cuando en
realidad es al revés, debes adaptar tu modelo para que funcione con
esta solución. Por eso es que Álvaro hablaba de tablas heredadas; por
lo que entiendo, y como se me ocurre usarla, es hacer una tabla
maestra en cada zona que "extienda" a la tabla de datos total,
utilizando la característica de orientación a objetos de PostgreSQL, y
a esa tabla que extiende la pones como maestra en la aplicación. ¿Es
así, Álvaro?

> > volviendo al mail original, le recomendarias a Graciela el uso de Postgres
> > + Slony-I?
>
> Depende mucho de la naturaleza de la aplicacion.

También lo creo así.

> Lo que yo intentaria
> hacer seria tener copias esclavas de la base de dato en cada una de las
> sucursales, de solo lectura (con Slony-I); y que las escrituras vayan a
> la base de datos central.  De este modo no se notaria la lentitud del
> enlace en las consultas de solo lectura (puesto que son locales a la
> sucursal), y se requeriria contactar al central solamente para las
> escrituras.

Mira, este plugin lo estamos arreglando y usando para un sitio Web en
el cual tenemos ese inconveniente a nivel nacional, y no ha tenido
mayor problema hasta ahora (aunque es alfa!):

http://trac.symfony-project.com/trac/wiki/sfPropelLoadbalancerPlugin

El problema podría ser si la aplicación escribe constantemente en la
base de datos y volúmenes grandes de información va a ser un problema
grande; hay que dimensionar en este aspecto.

Por poner un ejemplo descabellado (pero posible!!!), si se les ocurre
la brillante idea de meter en la base de datos algunos archivos de una
cierta cantidad de Mb. para que éstos se compartan entre todas las
sucursales van a tener un problema así. Para eso es mejor utilizar un
repositorio local o alguna otra solución independiente de la base de
datos. Por alguno de estos parajes utilizaban un manejador de
documentos (no relacionado con PostgreSQL) con una conexión de 2 Mb.
fijos, y era un problema cuando alguien intentaba acceder a un
documento grande desde otra sucursal.

> De esa forma, te ahorras todo el problema de la resolucion de conflictos
> y de replicacion multimaestro.  El inconveniente es que cuando se caiga
> la conexion sucursal-servidor, no podrias escribir (pero ojo, que eso
> sucede en casi todos los sistemas multimaestro, incluso los
> comerciales).

Inclusive aquí debes apelar a las leyes de la física y no aceptar a
personas que se crean Criss Angel, para que aparezcan al mismo tiempo
en dos sucursales distintas solicitando la misma información. Entrete
caso, :-s

-- 
Rodrigo Fuentealba