Base de datos enormes con firebird. ¿Cómo la estructuro?

[Angel Fernández]

Empezado por mamcx

Eso es lo que se hace para los sistemas OLAP. El ejemplo tipico es la fecha. En ves de ingresar un datetime se hace:

Fecha, Año, Mes, Dia, Hora, Min, Sec

Todo separado. Eso es genial porque puedes indexar de forma MUY eficiente.

Eso me viene muy bien saberlo, porque los datos que yo recibo en formato texto, vienen así, el año por un lado, el mes por otro, el día por otro, etc.

Como voy a agrupar frecuentemente por hora y presumo que también por mes, puedo crear una columna HORA_STR tipo CHAR(10) cuyo dato sea tal que así:

2008011508 (Año 2008, mes 01, día 15, hora 08) y ponerle un índice.

Y otra MES_STR tipo CHAR(6) con datos:

200801 (año 2008, mes 01) y ponerle otro índice.

De esta forma, al agrupar por hora no tengo que hacer un extract(hour from fecha) sino sencillamente agrupar por el campo HORA_STR.

¿Os parece buena idea o es una tontería?

Lo que dice fjcg02 me acongoja un poco... mis conocimientos son bastante pobres.

Un saludo.

[[fjcg02]]

Empezado por Angel Fernández

Lo que dice fjcg02 me acongoja un poco... mis conocimientos son bastante pobres.

No quería acongojar a nadie. Simplemente recordar que a veces el rendimiento de una bbdd no depende únicamente del análisis y el desarrollo, sino de algo que a veces se nos escapa, que es la configuración del srv de bbdd y la propia bbdd. Yo nunca he tenido que llegar a estos extremos porque nunca he tenido bbdd's tan grandes, pero en ocasiones - sobre todo cuando manejas volumenes tan grandes - es la solución a esos problemas de rendimiento.
Además, soy el primero que utiliza firebird - y cualquier otro motor - según se instala, sin cambiar nada.

Saludos

[Angel Fernández]

Lo que dije, fcjg02, supongo habrás entendido que era broma. Por supuesto que cualquier aportación será bien recibida, incluso si es un tirón de orejas.

Saludos.

[mamcx]

Es mejor dejar el año, mes, dia en columnas separadas que meterlas en un solo campo. La razon es que en vez de tener un solo indice tenes 3>, se hace muy optimo las consultas y es mas flexible porque tampoco tienes que hacer substring (por ejemplo, para llegar al dia) y ademas los campos se pueden dejar tipo INTEGER que es mas optimo que tipo STRING.

Por lo demas, tampoco es de enredarse mucho la pita. Hay un principio (el de Paretto) que dice que el 80% del esfuerzo se concentra en el 20% de las cosas. Determina que es lo mas probable y optimiza para ello, pero no te pongas a complicarte (igual, la optimizacion prematura causa mas lios que lo que mejora).

En terminos generales, tunear la BD, tener suficiente RAM y si se puede contar con discos en RAID o al menos 2 separados (1 para el OS otro para la BD) es mas que suficiente en la mayoria de los casos.

[tocomi]

Empezado por Angel Fernández

¿Os parece buena idea o es una tontería?

Personalmente creo que es una buena idea, de hecho si estuviera en tu situacion la consideraria seriamente

Ahora bien respecto del volumen de datos, y ya que se planteo por ahi el crear una tabla por cada sensor, por que no crear una tabla por año??, serian un numero de registros conocidos 565000 aprox y para el primer intento se podrian poblar con datos ficticios, hacer un par de consultas, y ver que como responde la aplicacion y el servidor

Definitivamente le recomendaria al cliente linux como sistema operativo, tanto por costo como por estabilidad (estoy desarrollando una aplicacion para windows que usa una base de datos Mysql en linux y al hacer las pruebas el rendimiento es bastante bueno, casi pareciera que estuviese local, la base esta en un servidor HP SCSI)

[Angel Fernández]

Gracias Tocomi por tu opinión. De hecho la base ya la tengo estructurada (con posibilidad de hacerle cambios) y estoy buscando formas de meterle los datos desde ficheros CSV. Lo de estructurarla por años, no me parece mala idea, pero me he enterado que el proyecto va a durar 5 años de recogida de datos y con esta cantidad de datos, firebird los aguanta perfectamente según he leído en la documentación que me han recomendado en este hilo.

Sí que he añadido los índices para anyo, mes, día y hora, los he puesto tipo integer como me recomendaba mamcx. Y también como me recomendaba mamcx, he decidido no "enredarme mucho la pita". He decidido un diseño de acuerdo a lo que me habéis indicado y lo he puesto en marcha.

Ya os iré diciendo qué tal va...

[jachguate]

Empezado por Angel Fernández

estoy buscando formas de meterle los datos desde ficheros CSV.

En ese caso, te recomiendo que leas, en mi blog, la entrada Exportar Datos de Firebird, que habla de como exportar/importar datos desde un csv de manera sencilla a firebird.

Empezado por Angel Fernández

Ya os iré diciendo qué tal va...

Siempre son bienvenidas las historias de éxito sobre firebird...

Un saludo

[Angel Fernández]

Empezado por jachguate

En ese caso, te recomiendo que leas, en mi blog, la entrada Exportar Datos de Firebird, que habla de como exportar/importar datos desde un csv de manera sencilla a firebird.

Gracias Juan Antonio por tu sugerencia. Sin embargo, he visitado la entrada de tu blog y, si mal no he entendido, allí tratas el tema de exportar de Firebird a csv. Yo ahora mismo lo que pretendo es justamente lo contrario, importar de csv a delphi. Tengo los datos en un fichero csv separados por punto y coma y quiero leerlos y ponerlos en una tabla de firebird.

En la entrada dices que la importación lo dejas para una próxima entrada, la cual estoy ya impaciente por leerla. Lo que voy a intentar hacer es un readln de cada línea del fichero csv, después con la utilidad strman.pas (completísima unidad con infinidad de utilidades para trabajar con cadenas de texto -en torry está-) le voy quitando lo que hay delante de cada ; y lo asigno al campo correspondiente.

De tu blog me he descargado la hoja de trucos para Firebird. Interesante, pero echo de menos funciones estadísticas (min, max, avg, etc)

Una cosa, he intentado añadir tu blog a Google Reader y no he encontrado la sindicación de RSS. ¿No la encuentro o no existe?

En cuanto a lo que comenta Casimiro, me alegra saber que hay gente con bases de firebird muy muy grandes sin problemas.

Un saludo a todos.

[tocomi]

Empezado por Angel Fernández

Lo que voy a intentar hacer es un readln de cada línea del fichero csv, después con la utilidad strman.pas (completísima unidad con infinidad de utilidades para trabajar con cadenas de texto -en torry está-) le voy quitando lo que hay delante de cada ; y lo asigno al campo correspondiente.

Te dejo esto por si te sirve

 
function Buscandocol(lintmp:string;nrocol:integer):string;
var
i:integer;
hasta:integer;
largo:integer;
dato:string;
valor:integer;
begin
lintmp:=trim(lintmp);
For i:=1 to nrocol do
   begin
   largo:=length(lintmp);
   hasta:=pos(';',lintmp);
   dato:=copy(lintmp,1,hasta-1);
   lintmp:=copy(lintmp,hasta+1,largo);
end;
result:=trim(dato);
end;

Esta funcion lee la linea de texto y te devuelve la columna que le indicas, obviamente las columnas estan separadas por un punto y coma, lo tuve que hacer porque habia un cliente que enviaba los datos en formato CSV, y tenia que separarlos para poder incorporarlos a la base

En terminos practicos haces el readln, lo dejas en una variable string, por ejemplo "linea" y para buascar la quinta columna la sintaxis seria:

Buscandocol(linea,5);

Te devolveria lo que esta en la quinta columna, en formato String

Nos cuentas como te va

[[RONPABLO]]

De tu blog me he descargado la hoja de trucos para Firebird. Interesante, pero echo de menos funciones estadísticas (min, max, avg, etc)

esas funciones las tiene FIrebird


una duda viendo la herramienta para exportar/importar... yo puedo crear/usar un archivo de texto que tenga el siguiente formato:

Empezado por formato tabulado y sin comillas

juan[tabulador]Colombia[tabulador]1

en vez de:

Empezado por formato por comas y con comillas

"juan","Colombia","1"

[jachguate]

Empezado por Angel Fernández

Gracias Juan Antonio por tu sugerencia. Sin embargo, he visitado la entrada de tu blog y, si mal no he entendido, allí tratas el tema de exportar de Firebird a csv. Yo ahora mismo lo que pretendo es justamente lo contrario, importar de csv a delphi. Tengo los datos en un fichero csv separados por punto y coma y quiero leerlos y ponerlos en una tabla de firebird.

Cierto que trato solamente el tema de la exportación, por ahora, sin embargo te queda el utilitario, al que basta ver la ayuda para figurarse cómo sería la importación.

Empezado por Angel Fernández

En la entrada dices que la importación lo dejas para una próxima entrada, la cual estoy ya impaciente por leerla.

Efectivamente.... yo también estoy impaciente por escribirla..

Empezado por Angel Fernández

Una cosa, he intentado añadir tu blog a Google Reader y no he encontrado la sindicación de RSS. ¿No la encuentro o no existe?

Claro que si!

http://jachguate.wordpress.com/feed/
http://jachguate.wordpress.com/comments/feed/

Está en la sección meta.... pero ahora que lo mencionas, quizás no esté lo suficientemente visible o bien identificada... me daré a la tarea de ponerla mas visible en cuanto me sea posible.

Hasta luego.

[Casimiro Notevi]

Respecto al tamaño de la base de datos, me gustaría comentar algo que me ha pasado hoy atendiendo a un cliente que hacía tiempo no tenía noticias de él, la conversación fue más o menos así:

cliente: sí, he metido la pata y ahora hay artículos en almacenes equivocados y el stock está descontrolado, ¿puédes arreglarlo?
yo: sí, claro, puedo ejecutar un script que te lo arregle, aunque antes de hacerlo en tus datos reales, me gustaría hacer una prueba en una copia de tu base de datos, me sirve tu último backup, por ejemplo el de ayer.
cliente: bien, cómo te lo envío.
yo: me lo comprimes y yo me lo tráigo por aquí mismo (conexión ultravnc)
cliente: bueno, verás, es que ocupa casi 11 Gigas
yo: no te preocupes, el fbk ocupa menos, y luego lo comprimimos con zip, rar o 7z y queda en mucho menos.
cliente: ya, si, pero es el zip del fbk el que ocupa los 11 Gigas, la fdb ocupa mucho más.
yo: , bueno, irá por ahí alguien a recogerlo en un disco duro portátil

Pues eso, tenemos clientes, la mayoría, que sus bases de datos ocupan varios gigas, pero es el primero del que tengo noticias que pasa los 10 Gbs... y sin problemas.