Despues de interbase?

[chutipascal]

Hola forosforos.


Casi todo lo que hago ultimamente es con interbase o firebird y no me quejo, por que va muy bien, pero en algunos clientes empiezo a tener pequeños problemas de velocidad...La solución pasa por tener un SGDB más rapido, MYSQL seria una exelente solución (que he usado varias veces) pero no quiero renunciar a vistas, procedimientos almacenados y trigers. Me interesa vuestra opinion pero sobre todo con el tema de cambiar facilmente el SGDB sin tener que reprogramar demasiado todas las aplicacione, ni tener que complicarme la vida o la del cliente con mantenimientos, tunings y otras historias.

Un Saludo.
Pascal.

[Iván]

Buenas :)

Antes que optar por MySQL, si quieres una solución OpenSource, yo miraría PostgreSQL. La verdad es q es una solución muy buena y estable, ya que lleva bastante tiempo en el mercado, y tiene todas las características que tiene que tener un SGBD.

Lo malo es q seguramente tendrás que toquetear bastante código, ya que aunque todas cumplan en cierta medida con el estandar SQL 92, pues aún así hay diferencias y lo que en una BD funciona correctamente, en la otra puede ser motivo de una mayor lentitud.

Las otras opciones son las de siempre.... Oracle, DB2, SQLServer..... pero todas pasando por caja.

Un saludo.

[__marcsc]

Hola,

Alguien de por aquí ha probado PostgreSQL? Es que que hice algunas prácticas y la verdad no me llevé muy buena impresión... Aunque la que yo probé fue una versión del año pasado Open Source, pero meparece recordar que también existe una versión comercial más avanzada.

Saludos.

[guillotmarc]

Hola.

En esos clientes, prueba a instalar la ultima versión de Firebird, la 1.5 RC5. Los cambios a realizar en la aplicación serán mínimos (si es que realmente es necesario hacer alguno), y se tiene que notar un aumento notable del rendimiento.

Entre otras casos el rendimiento va a aumentar debido a que ya viene por defecto un modo de actualización en caché en lugar de directamente a disco, para Windows. Esta actualización estaba desactivada por defecto y no se recomendaba en versiones anteriores debido a las grandes posiblidades de corrupción en caso de una terminación incorrecta del servidor (corte de luz, ...). Habiendo activado por defecto de una forma segura esta opción, el rendimiento de Firebird en Windows ya se acerca al rendimiento en Linux.

También se tiene que notar el aumento del rendimiento debido a las mejoras en el optimizador de consultas, por lo que ahora es más fácil que el motor encuentre los índices adecuados para agilizar la ejecución de la consulta.

En todo caso, si sigues teniendo problemas de velocidad, o bien Interbase / Firebird se queda pequeño (caso de millones de registros en una base de datos de más de 2 Gigabytes, o una base de datos a la que acceden más de un centenar de clientes), o bien quizá no has creado los índices adecuados para que el motor pueda optimizar la consulta problemática (este es el problema más usual).

NOTA : Recuerda de no poner Interbase/Firebird en un sistema multiprocesador, aunque tengas problemas de rendimiento. Puesto que la única versión que está preparada para funcionar correctamente en este entorno es Interbase 7 (las versiones actuales de Firebird tendrán un rendimiento peor con 2 procesadores, que con uno).

Saludos.

[chutipascal]

El asunto de pasar por caja no me preocupa, al cliente si le aseguro una mejora pagara, para eso esta la confianza.
De postgress la única vez que lo use me paso como a marcsc no me impresiono y menos en el tema de la velocidad...
SqlServer lo descarto completamente porque no puedo instalarlo en unix, linux, solo me queda Oracle y DB2 el problema es que la ultima vez que use Oracle fue en 1991 y de las versiones de DB2 más actuales no he pasado de instalar un trial, cuatro pruebas y olvidarme de el a los 10 minutos.
Es importante para mi no perder las opciones de view, Stored Proc. y triggers, además el cambio tiene que ser significativo en el tema de la velocidad, obviamente las condiciones economicas son importantes pero en segundo plano y en cuanto a uso quiero la maxima sencillez para el cliente, nada de miles de programas de administración etc... sinceramente estoy pensando en DB2 pero no encuentro comparativas de velocidad respecto a interbase y de Oracle mis fuentes me aseguran que para que vaya fino tienes que perder mucho tiempo haciendole un tuning -aparte de que la versión que me vino con el solaris me resulto muy "dura" de instalar-.


Un saludo.
Pascal.

[chutipascal]

Posteado originalmente por guillotmarc
En esos clientes, prueba a instalar la ultima versión de Firebird, la 1.5 RC5. Los cambios a realizar en la aplicación serán mínimos (si es que realmente es necesario hacer alguno), y se tiene que notar un aumento notable del rendimiento.

Si pero es todavia RC (Release Candidate) y no existe aún como SuperServer para Unix/Linux...Estare expectante...



También se tiene que notar el aumento del rendimiento debido a las mejoras en el optimizador de consultas, por lo que ahora es más fácil que el motor encuentre los índices adecuados para agilizar la ejecución de la consulta.


Buena noticia porque hasta ahora no parecia que el crear un indice mejorara dramaticamente la velocidad.


En todo caso, si sigues teniendo problemas de velocidad, o bien Interbase / Firebird se queda pequeño (caso de millones de registros en una base de datos de más de 2 Gigabytes, o una base de datos a la que acceden más de un centenar de clientes), o bien quizá no has creado los índices adecuados para que el motor pueda optimizar la consulta problemática (este es el problema más usual).


Tambien hay otro problema cuando tienes muchaaaas tablas...
y accedes a ellas a la vez.

[guillotmarc]

Hola


Si pero es todavia RC (Release Candidate) y no existe aún como SuperServer para Unix/Linux...Estare expectante...


Es verdad, aunque esta ultima RC practicamente es la versión final, han dado por cerrado el motor y aún no ha salido en versión final para dar tiempo a incluir detalles secundarios (documentación, instalador, applet de panel de control, ....). Lo que no sé es cuando van a sacar una compilación oficial para Linux.


Buena noticia porque hasta ahora no parecia que el crear un indice mejorara dramaticamente la velocidad.


Me extraña mucho, yo siempre he podido aumentar drasticamente la velocidad creando índices. La verdad es que normalmente consigo que todas las consultas tarden escasos segundos en ejecutarse, y solo en algunos casos muy concretos (debido a la cantidad de subconsultas y left outer joins) algunas consultas lleguan a tardar unos 15 segundos (tiempo máximo que creo que debería tardar una consulta con los índices adecuados, y que devuelva unos pocos miles de registros).

¿ Utilizas indices compuestos, es decir con varios campos ?. En muchos casos (sobretodo en subconsultas), para que el índice sea realmente útil tiene que contener varios campos. Por ejplo :

select *
from tabla
where estado = :A and fecha between :B and :C

Aquí un índice para el campo estado y otro para fecha, no són óptimos. Lo que dará un resultado óptimo es un índice para estado + fecha.

Además hay que verificar el plan que utiliza el motor en las consultas, de esta forma se verifica que el motor utiliza los índices adecuados en cada caso (a veces se ve como el motor no es capaz de detectar el índice correcto, por lo que se reescribe la consulta, o se indica manualmente el plan).


Tambien hay otro problema cuando tienes muchaaaas tablas...


¿ Cuantas són muchas tablas ?. Trabajo habitualmente con bases de datos con un centenar de tablas y por ahora no he encontrado este problema.

Un saludo.

[Iván]

Yo también estoy de acuerdo que el uso de los indices correctos aumenta dramaticamente el rendimiento... Y se nota mucho.

Por otra parte, si te pasas a un sistema "grande" como Oracle, DB2, SQLServer o Informix, vete preparando para perder horas y horas haciendo "tunning", ya que estos sistemas lo requieren. Además, siempre se ha puesto como una de las ventajas de InterBase / FireBird.

Lo que se comenta de IB multiprocesador, totalmente de acuerdo. La única versión preparada en teoría para ello es la 7 de IB, y ni IB (versiones anteriores) ni FB están al día en este tema. Por lo que he leido es una de las cosas a mejorar en FB2.0, aunque la espera puede ser muy larga.

Yo directamente no he usado PostgreSQL, pero en uno de mis anteriores trabajos, y eso ya hace 4 años, hablaban maravillas del mismo, y por las consultas pesadas que ellos hacían, la verdad es q el tiempo de respuesta era considerablemente bueno.

Yo estoy con guillotmarc y prueba FB1.5. Todo lo que he oido por el momento es hablar bien de la misma. Y por las pocas pruebas que he hecho, también me ha dejado contento.

yo en mi caso, a la hora de cruzar tablas, normalmente lo hago siempre cruzando con la clave primaria, y si puede ser, está ha de ser siempre un generador. Así es como yo he conseguido la mayor velocidad posible en consultas cruzadas. Aunque a veces, para ciertas consultas eso provoque un poco más de trabajo a la hora de montarlas.

Un saludo.