Capacidad de firebird

[guillotmarc]

Empezado por ivantech

el caso es que se esta elaborando una herramienta de captura de dichos formularios y estamos analizando un gestor de base de datos apto para el almacenaje de dicha información que sera bastante y crecerá a un ritmo acelerado de 117 a 120 mil registros al año. Yo estoy en lo personal proponiendo a Firebird como Gestor de BD para este proyecto, pero quiero afianzar mi sugerencia y ahí se desprende mi pregunta. ¿Puede firebird almacenar esta cantidad de registros a largo plazo? ¿que implicaría en materia de administración esta cantidad de registros? ¿Sugerencias sobre el manejo de este gran volumen de información?

Hola Ivan, si en el periódico The Examiner se las arreglan para registrar 200.000 transacciones al día con Firebird, no creo que debería ser muy problemático manejar 120.000 transacciones al año.

http://www.vivalinux.com.ar/soft/fir...a-empresa.html

De vez en cuando salen noticias como esta, solo te he enlazado esta porqué la tenía a mano, la he leído hace poco, pero te puedo asegurar de que no es un caso aislado, hay varias empresas telefónicas y Bancos que utlizan Firebird en sus sistemas, y manejan bases de datos de esta envergadura, especialmente en países como Rusia o Brasil. En los foros oficiales de Firebird (firebird-support en Yahoo Groups) ofrecen toda la ayuda posible para estas instalaciones, aunque naturalmente nosotros también echaremos una mano en lo que esté a nuestro alcance.

Saludos.

[ivantech]

saludos y nuevamente gracias por sus respuestas

pero estamos consciente del lo que esto implica, pero como te dije el caso es que ya se han intentado implementar de todo tipo de proyectos, han venido consultores de todo tipo y lo único que sucede es que al no existir una cultura en los escalafones inferiores, todos estos proyectos se caen luego concluidas dichas consultorias e implementaciones costosisimas. nuestro propósito es ver de que forma empezamos a crear la cultura y luego de a poco entonces vendría lo otro.

Claro que si casimiro, estoy totalmente consiente de las implicaciones que tiene el proyecto implementado de esta forma pero como te dije es únicamente una herramienta para almacenaje y no se va a procesar ni validar nada, únicamente es para convertir los formularios a datos electrónicos para luego incorporarlos en los niveles superiores que si es donde se va a procesar la información y como casi el 94 % de los datos están precodificados se requiere la menos validación posible. pero ahora tampoco es relevante porque el caso aquí es crear la cultura y necesidad de informatizar dicho nivel y que de este trabajo se desprenda lo demás.

el caso es que en los siguientes niveles existirán personas que estarán consultando las informaciones y probablemente estarán enterándose si les falta algunas informaciones y se la volverían a exigir al nivel donde se esta digitando la información. ademas existen otras instituciones gubernamentales del sector salud que también exigirán algunas informaciones para incorporarlas a sus sistemas y este mecanismo servirá como medio de presión y compromisos para que no se pierda la información, otra cosa es que no seria diario que tendrían que enviar las informaciones, sino en un periodo que se acuerde a lo interno de la Gerencia Regional. con las demás instituciones superiores siempre seria mensual o trimestral, etc.

ahora, en valor de porcentaje y desde sus puntos de vista y como ultima pregunta para concluir este tema, ¿que posibilidad tiene este proyecto de funcionar? y por favor sean sinceros.

[guillotmarc]

Hola Ivan.

En este enlace puedes leer los resultados de unas pruebas que hicieron con Firebird para evaluar bases de datos de 1 Tb en un ordenador normal y corriente (Athlon x2 5200, 4Gb RAM DDRII y discos normales SATA II).

Tardaron 70 horas en rellenar la base de datos con la desorbitada cantidad de un Terabyte de información (en una simulación realista sobre varias tablas maestro-detalle), a razón de 24.500 registros por segundo para un total de 6,2 billones de registros insertados.

Una vez rellenada la base de datos probaron la ejecución de varias consultas (uniones incluídas), y el resultado se obtenía en el rango habitual de varios milisegundos para su ejecución (siempre y cuando las consultas tengan el índice adecuado para su optimización).

http://www.ib-aid.com/articles/item104

NOTA: En el mismo artículo citan varias empresas que tienen en el centro de sus sistemas bases de datos Firebird de más de 300Gb de tamaño.

Saludos.

[ivantech]

gracias guillot

pues si, estoy convencido con las capacidades de firebird y ya no tengo dudas de sus capacidades, ahora lo que quería afianzar es el mecanismo que vamos a implementar y debatir los puntos de vista con respecto a este mecanismo como las advertencias que hace casimiro a lo que podría pasar.

gracias por tu respuesta.

[Casimiro Noteví]

Empezado por guillotmarc

[..]
NOTA: En el mismo artículo citan varias empresas que tienen en el centro de sus sistemas bases de datos Firebird de más de 300Gb de tamaño.
Saludos.

Bueno, he de comentar que en la empresa donde trabajo, nuestros clientes tienen casi todos bases de datos de más de 500 Mb, pero hay un par de ellos que producen varios cientos de miles de transacciones diarias y sus bases de datos oscilan en estos momentos los 20 Gb, manteniendo unas 100 conexiones continuas por red local y varias sucursales conectadas por internet. Por supuesto que la respuesta del sistema es inmediata, si tardaran sólo un segundo ya estarían llamándonos para que le resolvamos el "problema".
Al mismo tiempo los clientes hacen consultas y pedidos por la web en tiempo real, pues el servidor web (linux+apache) está conectado al otro servidor de bases de datos (linux+firebird).

[ivantech]

entonces para concluir con este tema, marcguillot y casimiro.

si la herramienta y el mecanismo que estamos por implementar (en mi institución) es solo como almacenaje y difusión hasta los niveles superiores de procesamiento y aclarado el punto de las capacidades de firebird con respecto al volumen de almacenaje y rendimiento, también tomando en cuenta que el proceso inicial busca crear la cultura de trabajar con aplicaciones en los niveles inferiores y que ahora en esta etapa no es relevante el echo de la calidad de la información y tomando en consideración que para poder manejar muchas informaciones es necesario que tengamos que trabajar con la indexación adecuada de la Base de Datos. Puedo implementar este modelo sin mayor obstáculo. entonces me gustaría saber si tienen alguna sugerencia o algún sitio donde especifiquen las cosas a tomar en cuenta para realizar consultas e informes con volúmenes de información de mas de 1 millón de registro. ojo no se si tendría que iniciar otro tema o seguimos con este favor de aclararme.

[guillotmarc]

Hola Ivan.

En efecto, tienes razón, para trabajar con ese volumen de información es crítico tener los índices adecuados para poder optimizar tus consultas.

La mayor base de datos con la que trabajan mis clientes solo tiene 1Gb (eso dice mucho de la elevada compresión que hace Firebird al guardar los datos), pero almacena la información de 15 tiendas interconectadas y hasta veinte años de su gestión (compras, ventas, etc. ...).

Algunas de sus tablas superan perfectamente el millón de registros (como las líneas de venta) y nunca hemos tenido que implementar ningún mecanismo especial para que funcionen correctamente. Simplemente funciona igual de bien que en una tienda pequeña que solo tenga unos pocos miles de registros. Solo hay que asegurarse de tener los índices adecuados para todas las consultas que se ejecutan a esas tablas.

Lamentablemente no recuerdo ningún artículo ni documento que explique como deben definirse los índices más óptimos en una tabla. Así que no te puedo poner ningún enlace. La verdad es que es bastante intuitivo, pero hay que tener en cuenta que muchas veces necesitarás índices múltiples.

Ejemplo : select * from clientes where Empresa = 1 and Tipo = 4

Aquí lo óptimo no es tener un índice para Empresa y otro para Tipo, puesto que el motor solo va a utilizar uno de los índices. Entonces, supongamos que escoge el índice Tipo (se va a basar en la granularidad del índice, es decir de los índices que pueden acelerar una consulta, va a escoger el que tiene más valores y por lo tanto tiene menos registros asociados a un determinado valor). Supongamos pues que el índice escogido por el motor es el de Tipo, entonces va a tener que recorrer todos los registros del Tipo 4 para evaluar si son de la Empresa 1.

En cambio si definimos un índice múltiple para Tipo + Empresa, entonces el motor puede realizar la consulta de forma inmediata, ya que con ese índice puede detectar inmediatamente los registros del Tipo 4 que también son de la Empresa 1.

NOTA: Con el tiempo los índices se desbalancean (son árboles binario de búsqueda y para su correcto funcionamiento todas las ramas del árbol deben tener aproximadamente el mismo número de nodos, en caso contrario unas consultas serían más rápidas y otras más lentas debidas a que tienen que recorrer un camino más largo en el árbol) por lo que cada mucho tiempo (cada 5 años o así) hacemos una reestructuración de la base de datos (un backup y restore posterior con lo que se rehace la base de datos y los índices se regeneran). Es la única tarea de mantenimiento que hacemos.

[Casimiro Noteví]

Aquí tienes un sencillo documento que habla sobre los índices en firebird, está escrito por una de las programadores de firebird.