Capacidad de firebird

[ivantech]

saludos

la institución para la que laboro es de tipo gubernamental orientado al sector salud, el caso es que se esta elaborando un instrumento (Formulario) de captura a nivel nacional de información de servicios en las clínicas rurales y policlínicas que es a lo que aquí y en otros países le llaman primer nivel de atención en salud.

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?

[[movorack]]

Para mi, la cuestión no es de capacidad sino de medio o forma de difusión... dices que es a nivel nacional... ¿pq medio harás la propagación de este formulario? ¿web? ¿applicativo via intranet?

[Casimiro Notevi]

Empezado por movorack

Para mi, la cuestión no es de capacidad sino de medio o forma de difusión... dices que es a nivel nacional... ¿pq medio harás la propagación de este formulario? ¿web? ¿applicativo via intranet?

Como bien dice movorack, lo principal es que expliques cómo se va a trabajar accediendo a la base de datos, deberías orientarnos lo más detallado posible del sistema que se piensa crear.
Por cierto, cien mil registros no es nada para ninguna base de datos "decente", y millones de registros tampoco es problema.

[ivantech]

gracias por responder

bueno, la forma es la siguiente sabemos que lo ideal fuese que esta herramienta fuera en linea a traves de la web. pero la realidad de mi pais (Rep. Dominicana) todavía no esta a la altura para que este proyecto sea web en este momento pero se esta trabajando, ya que a nuestro entender y como nuestro ministerio esta en proceso de Descentralización y anteriormente todo se hacia aquí, ahora tenemos la misión de crear la cultura de procesamiento de datos y determinamos que un proyecto de esta envergadura a nivel Web no estaría garantizado por la limitación de la banda ancha en sitios remotos de nuestro país.

el caso es que se va a desarrollar el modulo en Delphi + Firebird 2.5 en local en las unidades de supervisioón y monitoreo que son los centros de acopio de estos formularios ya llenos y que son unos 16 en promedio por cada Gerencia Regional. aquí serán procesados y convertidos a electrónicos, luego a través de archivos planos (TXT) serán llevados y consolidados en la Gerencia Regional de Salud que en total son 9 a nivel nacional cada cierto periodo y por último cada una de las 9 Gerencia de Salud enviaran vía correo, cd, dvd o memoria USB cada cierto periodo las informaciones en un archivo (TXT) ya con todas las informaciones de su región, para de esta forma consolidar todas la informaciones del país en el Ministerio de Salud donde yo laboro. nada este es el modelo que se quiere implementar como verán ya aquí en el ministerio vamos a manejar bastante información luego que se consolide. no se, este modelo esta abierto a todo tipo de sugerencia. por favor opinen según su experiencia de verdad este proyecto es muy grande y debe ser lo mas realista posible.

gracias.

[Casimiro Notevi]

Desconozco la realidad de las conexiones por internet en tu país, pero lo que sí creo es que con ese sistema va a ser todo bastante descontrolado porque existen demasiados pasos intermedios, demasiados sistemas de recopilación de datos, demasiadas variables que pueden ser imprevistas, por ejemplo: un pendrive que se pierde por el camino, un dvd que no se puede leer, un correo que no llega, alguien que "se le olvida" enviar la documentación, etc.
Ahora bien, si el sistema se va a limitar a almacenar lo que llegue y sin preocuparse de nada más, pues vale, ahí no hay problema.
Y por supuesto, con Firebird puedes trabajar confiadamente en un sistema así.

[[movorack]]

Comparto a lo que dice casimiro, pero en tu lugar trataria de dar mi aporte al desarrollo de las comunicaciones en el país.

Aquí en Colombia ya es normal que la mayoria de entidades tengan herramientas de consulta o procesos en la web; Pero esto no fué hasta que las entidades estatales lanzaron sus primeras herramientas de consulta (algo bastante precarias) hace unos 3 años.

Decir "todavía no esta a la altura para que este proyecto sea web en este momento" puede ser hasta cierto punto valido... pero si se de alguien que puede imponer procedimientos es el gobierno.

Disculpa si me fuí mas allá de la pregunta técnica.

[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 Notevi]

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 Notevi]

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