[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Es Postgres una buena BD



On Sun, 25 Feb 2001, Christoph Simon wrote:

> On Sun, 25 Feb 2001 15:08:05 +0100 (CET)
> Antonio Castro <acastro@ciberdroide.com> wrote:
> 
> > Yo soy un convencido del software libre. Soy autónomo. Uso Postgres
> > para mi negocio y te puedo decir que ahora confió en Postgres porque
> > ya lo he usado, pero mis necesidades son muy pequeñas y no sirven de
> > ejemplo. Soy incapaz de recomendarlo a una empresa que tenga un elevado
> > número de tablas grandes sobre las cuales se realicen muchas transacciones
> > en poco tiempo.
> > 
> > Los datos de una empresa son algo sagrado y un empresario no va a tomar 
> > a la ligera una decisión como esta que puede mandarle directamente a la 
> > ruina (o incluso a la carcel según los casos) si algo sale mal. 
> 
> Bien. Con software, libre o no libre, siempre tendrás un riesgo, igual
> como con el hardware. Nadie dudará en responsabilizarte por no hacer
> backups. Y justamente porque es un tema delicado, no creo que vayas a
> encontrar alguien quien te lo garante sin cobrar por una vigilancia
> permanente.

Hago backups todos los días. Perder datos es malo pero no es lo
peor que puede suceder. Lo peor es confiar en una información 
pensando que es la correcta. Acaso tu backup es capaz de recuperar
a un paciente diabético al que se le inyecta suero glucosado ? Es
que no lees lo que pongo ? Una historia clínica equivocada como yo
mencionaba antes puede desembocar en esto. 

> 
> Lo que yo haría es andar como con los ojos cerrados en una habitación
> oscura: Monta una máquina con Postgres 7. Coloca una cantidad de datos
> mas o menos similar a la que te esperas tener que gestionar. Monta
> tres o cuatro máquinas como clientes y simula el acesso a la base de
> datos con unos scripts, que lo pueden hacer mucho más rápido que
> cualquier usuario manualmente. Así podrás simular la carga. Déjalo

Es cierto se puede averiguar si responderá a la carga pero eso no es
todo.

> correr durante una semana, un mes, o el tiempo que sea, hasta que tú
> mismo cojas confianza en el invento. Si no te da la velicidad que
> necesitas, si se te cae, si pierdes datos, o cualquier otra cosa mala,

Cualquier otra cosa ? Es que acaso crees que vas a ser capaz de
detectar cualquier otra cosa ? Cuando un sistema se usa en un entorno
real hay miles de personas trabajando sobre unos datos y que pueden
detectar alguna de las anomalías que se puedan producir. El fallo de
Acces al que me referí antes capaz de confundir la historia de un
paciente con la de otro tardó en ser detectado muchísimo tiempo porque
se necesitaba un conjunto de condiciones muy especiales para que ocurriera.
Ya se nos ha olvidado lo mucho que se tardó en detectar en fallo de cálculo
de coma flotante de intel ? Asi que nada tu pruebas algo y si funciona
pues  lo das por válido pero depende para que lo vayas a usar quizas 
necesites alguna seguridad adicional. 

Si una empresa importante lleva usando un sistema para algo similar a lo
que tu necesitas de ta una cierta tranquilidad. No hay certeza pero si
tengo que cruzar un campo minado prefiero pisar sobre las huellas de
alguien que lo cruzó antes que yo.

> tal vez no sea la base de datos que busques (pero no me lo creo). En

Para mi si lo es. No cambio Postgres por ninguna otra.

> caso de éxito, y si ya existe una instalación, móntala para correr en
> otra máquina y en paralelo, usando scripts que dupliquen estos datos

Me parece que la cosa no es tan sencilla como tu la presentas. En una
empresa puede haber miles de programas distintos que vayan contra una 
BD y para cuando termines de hacer los scripts puede que ni los datos
ni los programas sean los mismos. Hacer operaciones simultaneas sería
en dos BD creo que sería complicado de sincronizar. Supongo que si se 
podría ejecutar en diferido el histórico de todas las operaciones que 
modifican una BD (altas, bajas y modificaciones) sobre la otra.

> automaticamente sin que el operador lo note. Así podrás hacer una
> transición gradual. Si todavía no existe, corre simplemente esta. Haz
> un backup diário, exportando los datos en SQL estándar, así que lo
> podrías importar en cualquier otro banco de datos si realmente fuera
> necesaria la subsitución. En el peor caso puedes perder los datos de
> un día y tendrás el trabajo de volver a montar todo con otra base de
> datos. Claro, no deberías usar estructuras que sean específicas y
> exclusivas a PostgreSQL.

Hacer funcionar dos sistemas en paralelo solo porque no confías en 
uno de ellos es carísimo. La gente usa aquello en lo que confía
y punto. No digo que no se pueda hacer. Todo es posible con la suficiente
cantidad de dinero pero yo busco argumentos que inviten a usar Postgres
y tu propuesta casi invita a lo contrario. Nadie va a usar Postgres si
antes tiene que hacer algo así y me explico porque es un tema que lo
he conocido de primera mano. 

El Banco Espirito Santo cambió de IBM a UNIX todo su sistema informático 
aprovechando un puente y sin pasar por un periodo de prueba en paralelo 
con datos reales. Claro pruebas previas con datos más o menos reales
se hicieron muchas.

Los informáticos de ese banco trabajaron en turnos de 48horas seguidas.
Además los meses inmediatos al cambio fueron una pesadilla.

La cuestión es que trabajar en real duplicando los sistemas supone
casi trilicar la plantilla de trabajadores mientras dure ese periodo.

> 
> Pero piensa también eso: No importa que sea Oracle, Sybase o cualquier
> otra, yo no conozco base de datos comercial de la cual no haya oido de
> algún desastre, especialmente en la fase inicial. Hasta que no se lo

Y no sería mejor hablar de los éxitos de Postgres que de los fracasos
de Oracle, Sybase etc..Esdtoy seguro de que Postgres ha demostrado
su fiabilidad pero no tengo tados y me gustaría conocerlos.

> demuestre en la práctica no puedes confiar tampoco en las bases de
> datos comerciales. Tienes dos soluciones: una es proceder como

Para mi que una BD sea libre es algo que me inspira mucha confianza
porque si algo importante falla seguro que se arreglará pronto pero
para una empresa grande este criterio puede no resultar suficiente si
no se demuestra de partida una buena fiabilidad. Yo supongo que si es
fiable y para mi con eso me basta.

> descrito arriba, o puedes trasladar el problema a otra empresa
> especializada en esta base de datos; si algo va mal, que fusilen
> aquellos. Pero entonces, tal empresa existe también para PostgreSQL
> (la encontrarás en la home page de postrgres). ¿A dónde nos lleva
> esto?

Pues no lo se. Yo solo pedía datos que creo de interés general y a cambio
solo recibo una polémica absurda. Yo uso Postgres. Yo defiendo Postgres.

Yo solo pido referencias que demuestren hasta donde es capaz de responder
Postgres para usos serios en instalaciones reales. No porque a mi me 
interese personalmente porque ya tengo tomada la decisión sino porque lo 
creo de interés general.



Un saludo

Antonio Castro

+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
        /\     /\      Ciberdroide Informática (Tienda de Linux)
          \\W//            <<< http://www.ciberdroide.com >>>
	 _|0 0|_                                                    
+-oOOO--(___o___)--OOOo----------------------------------------------------+ 
|  . . . . U U . . . . Antonio Castro Snurmacher  acastro@ciberdroide.com  |  
|  . . . . . . . . . .                                                     | 
+()()()----------()()()----------------------------------------------------+
| *** 1.700 sitios clasificados por temas sobre Linux en ***Donde_Linux*** |
| <<< http://www.ciberdroide.com/misc/donde/dondelinux.html >>>            |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+




Reply to: