Experiencia con Firebird

[Casimiro Notevi]

Hola,. bienvenido a clubdelphi
Suponemos que la base de datos es firebird, cuéntanos algo más, si puedes, sobre el tipo de gestión, servidor/es, etc. es que soy muy curioso

[Neeruu]

La verdad que una base de datos impresionante!!!!

No me imagino la cantidad de datos que pueden almacenarse en semejante DB....


Saluda Atte Neeruu!!!

[cointec]

Hola:

Nosotros utilizamos tanto interbase como firebird. Las instalaciones son todas en windows, principalmente windows 2003, aunque las últimas se están haciendo en Windows 2008. Las instalaciones con más carga de trabajo funcionan sobre VMWare.

Para la próxima implantación, vamos a utilizar Windows 2008 R2 sobre VMWare. El servidor virtual de base de datos, va a contar con 8 cores y 24/32Gb RAM. La versión de Firebird es 2.5.1. Necesitamos tanta memoria, ya que el problema que tiene la versión classic, cuando el metadata es grande, es el uso de memoria. Nos hemos encontrado que con la versión 2.5.1, el uso de memoria ha incrementado por conexión. Mientras Firebird 2.1.X utilizaba por conexión a nuestra base de datos un mínimo de 54Mb, la versión 2.5 utiliza 80MB RAM. Preveemos que por conexión utilice un máximo de 110MB y que tengamos picos de 200 conexiones.

Un Saludo, Jesus

[Neeruu]

Hola.... unas consultas...

Como mantienes una base de datos tan grande...???
Utilizas algún programa que supervise la DB....??? ( En este Link Mencionan que utilizan esta herramienta "IBSurgeon’s FBDataGuard" para mantenimiento)
Como haces el calculo de consumo de memoria???

No te convendría tener el servidor de firebird sobre linux??? Digo por lo que leí la versión clasic trabaja mejor sobre linux y aprovecha mejor los procesadores.... (Esto es si no entendí mal )



Saluda Atte Neeruu!!!

[[fjcg02]]

Empezado por cointec

Hola:

El servidor virtual de base de datos, va a contar con 8 cores y 24/32Gb RAM. La versión de Firebird es 2.5.1. Necesitamos tanta memoria, ya que el problema que tiene la versión classic, cuando el metadata es grande, es el uso de memoria. Nos hemos encontrado que con la versión 2.5.1, el uso de memoria ha incrementado por conexión. Mientras Firebird 2.1.X utilizaba por conexión a nuestra base de datos un mínimo de 54Mb, la versión 2.5 utiliza 80MB RAM. Preveemos que por conexión utilice un máximo de 110MB y que tengamos picos de 200 conexiones.

Dos preguntas:
1.- No es mejor no virtualizar para mejorar el rendimiento ? Nosotros virtualizamos los servidores de aplicación, pero no los de bbdd.
2.- Utilizais aplicaciones de 2 capas o de tres ? En el caso de aplciaciones de 3 capas podriais mantener el consumo de memoria reutilizando las conexiones a la bbdd, siempre y cuando el rendimiento sea bueno. No entiendo muy bien lo de atacar ví asp... en este caso no hay servidor de aplicaciones intermedio ?

Das poca información, pero me han llamado la atención estos dos aspectos.

Un saludo

[cointec]

Empezado por Neeruu

Como mantienes una base de datos tan grande...???

El mantenimiento es mínimo. Realizamos backups nocturnos, revisamos los logs y semanalmente hacemos restore. En cuanto al mantenimiento de versiones, lo hacemos mediante scripts de actualización de base de datos.

Empezado por Neeruu

Utilizas algún programa que supervise la DB....??? ( En este Link Mencionan que utilizan esta herramienta "IBSurgeon’s FBDataGuard" para mantenimiento)

Nos hemos planteado empezar a utilizarlo a corto plazo, pero por ahora no utilzamos ninguno.

Empezado por Neeruu

Como haces el calculo de consumo de memoria???

Realizamos conexiones a la base de datos y simulamos un trabajo normal, y comprobamos el uso de memoria que tiene la conexión.

Empezado por Neeruu

No te convendría tener el servidor de firebird sobre linux??? Digo por lo que leí la versión clasic trabaja mejor sobre linux y aprovecha mejor los procesadores....

No tenemos experiencia con Linux, y por ahora no lo hemos necesitado.

[cointec]

Empezado por fjcg02

Dos preguntas:
1.- No es mejor no virtualizar para mejorar el rendimiento ? Nosotros virtualizamos los servidores de aplicación, pero no los de bbdd.
2.- Utilizais aplicaciones de 2 capas o de tres ? En el caso de aplciaciones de 3 capas podriais mantener el consumo de memoria reutilizando las conexiones a la bbdd, siempre y cuando el rendimiento sea bueno. No entiendo muy bien lo de atacar ví asp... en este caso no hay servidor de aplicaciones intermedio ?

1. La virtualización es una imposición de nuestros clientes, no nuestra. Por supuesto el rendimiento es mejor sin virtualizar.
2. Hay usuarios de cliente pesado desarrollado en Delphi con 2 capas. Otros usuarios se conectan a través de una aplicación desarrollada en ASP.NET con 2 capas, pero utilizan pool de conexiones.

[[fjcg02]]

Empezado por cointec

1. La virtualización es una imposición de nuestros clientes, no nuestra. Por supuesto el rendimiento es mejor sin virtualizar.
2. Hay usuarios de cliente pesado desarrollado en Delphi con 2 capas. Otros usuarios se conectan a través de una aplicación desarrollada en ASP.NET con 2 capas, pero utilizan pool de conexiones.

1.- Ok, me lo figuraba.
2.- Os costaría mucho hacerlo en 3 capas y utilizar mínimo nº de conexiones ? me respondo y mismo que sí, pero bueno, es por aportar ideas.

Un saludo

[cointec]

Empezado por fjcg02

2.- Os costaría mucho hacerlo en 3 capas y utilizar mínimo nº de conexiones ? me respondo y mismo que sí, pero bueno, es por aportar ideas.

Si que nos costaría bastante y por ahora no es necesario, salvo por el uso de classic server, y lo podemos solucionar con memoria.

Nuestra aplicación cliente utiliza intensamente la base de datos, y puede que minimizásemos las conexiones, pero seguirían siendo bastantes. También un problema que habría en dicha conversión, vendría derivado porque utilizamos para las conexiones de la aplicación cliente, un usuario de base de datos. Nuestros usuarios, se crean a nivel de base de datos y se utiliza el usuario desde el matadata para realizar logs, permisos para realizar acciones sobre tablas, etc.

Con 3 capas, tendríamos que abandonar todo este diseño, y es algo que aumentaría considerablemente el trabajo a realizar. Quizá firebird 3 nos lo resuelva antes .

Un Saludo