RE: [pgsql-es-ayuda] Configuración para aplicación

Ya que estan en eso de GPS, no han probado a usar OPenGTS? Es muy bueno, lo unico malo que tiene es que esta en MySQL pero ya me estoy "emburujando" con el a ver si lo puedo poner para PG.No tengo tantos GPS , ahpra solo 92 pero va subiendo

> CC: pgsql-es-ayuda(at)postgresql(dot)org
> Subject: Re: [pgsql-es-ayuda] Configuración para aplicación
> From: alvherre(at)alvh(dot)no-ip(dot)org
> To: jgromero(at)gmail(dot)com
> Date: Mon, 6 Feb 2012 12:43:30 -0300
>
>
> Excerpts from Juan Romero's message of lun feb 06 12:20:01 -0300 2012:
> > Un amigo me pregunta lo siguiente, y quisiera que me ayudaran con sus
> > opiniones al respecto:
> >
> > Se está desarrollando una aplicación de seguimiento vehicular (AVL).
> > Como Servidor de Mapas estamos usando Geoserver y como Repositorio de
> > BD estamos usando PostgreSQL + PostGIS, este ultimo para realizar
> > consultas espaciales directamente con la DB.
> >
> > Unos equipos GPS están enviando información. Esta información es leída
> > e interpretada mediante un listener que escucha un socket, con lo que
> > estamos poblando un par de tablas en la DB. Se esperan 20.000 GPS
> > enviando información
> >
> > Quieren tener una copia de la DB en otro server esclavo y/o de replicación.
> >
> > 1. Dado que en la versión 9.1 tenemos replicación síncrona, pero que
> > existen otras opciones, no tengo claro que tipo de replicación se debe
> > hacer.
>
> La replicación síncrona no es muy conveniente, porque en cuanto el
> standby se cae, el maestro deja de aceptar nuevos commit de
> transacciones. Me parece que replicación asíncrona es mejor para tu
> caso: siempre tendrás casi todo en la réplica; y si el maestro estalla,
> podrás recuperar desde la réplica con mínima pérdida. Si es la réplica
> la que estalla, el maestro sigue procesando nuevos datos. En ambos
> casos estoy pensando en "streaming replication".
>
> > 2. En el momento tengo 1 servidor (Worksatation Dell Precision 690)
> > Dell con 1 Procesador Dual Core XEON de 2.33Ghz, Ram 8Gb, HD 750 GB en
> > raid 0 (Gemelos), con sistema operativo Mandriva Linux 2011. También
> > tengo disponible una maquina Dell Core 2 Quad, Ram 4Gb, HD 1TB. Esta
> > ultima para las replicas o lo que se requiera.
>
> ¿20.000 GPS en operación enviando datos y no tienen fondos para comprar
> un buen juego de discos? Me imagino que deben haber implantado chips
> GPS a los vagabundos de la calle, con dinero fiscal, y se quedaron sin
> fondos para proveer de hardware a la solución de almacenamiento.
> ¿O quizás Greenpeace está empezando un seguimiento masivo de ballenas, y
> todavía no reciben mi donación?
>
> Mandriva ... ¿no era la que quebró como en 2007? Creo que volverá a
> quebrar este año. ¿Será la mejor opción? http://bit.ly/w1B09h
>
> > 3. Cuáles serian las mejores prácticas de configuración de la DB y de
> > la gestión de cola, ya que el número de usuarios es directamente
> > proporcional con el número de equipos GPS enviando información a la DB
> > y que el Listener debe interpretar y almacenar.
>
> Usando commit asíncrono le darías respuesta rápida a cada requerimiento
> de commit de inserción; el commit debería ser síncrono para otro tipo de
> transacciones. Así puedes sobrellevar la carga sin matar el sistema.
>
> Me imagino que pondrás el listener en una (o unas) máquina remota que se
> conecte vía TCP al maestro. De este modo, si el maestro es acuchillado,
> el listener se da cuenta, espera hasta que la réplica levanta como
> maestro, y se conecta al nuevo maestro para continuar la inserción, sin
> pérdida de servicio.
>
> --
> Álvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
> -
> Enviado a la lista de correo pgsql-es-ayuda (pgsql-es-ayuda(at)postgresql(dot)org)
> Para cambiar tu suscripci�n:
> http://www.postgresql.org/mailpref/pgsql-es-ayuda