FTP | CCD | Buscar | Trucos | Trabajo | Foros |
|
Registrarse | FAQ | Miembros | Calendario | Guía de estilo | Temas de Hoy |
|
Herramientas | Buscar en Tema | Desplegado |
#1
|
|||
|
|||
Inserción masiva en Firebird
Hola a tod@s.
Necesito hacer una inserción de muchos datos y tengo el problema de que al paso que va puede tardar más de un año. Yo pensaba que podía utilizar:
Pero, a partir de la primera inserción, me da error diciendo que intento acceder a una consulta cerrada y me obliga a hacer:
Con lo cual me obliga a hacer una búsqueda y una inserción, pero yo no necesito hacer la búsqueda porque pueden haber registros repetidos. ¿Alguien sabe cómo puedo mejorar la velocidad? Gracias. |
#2
|
||||
|
||||
No se qué componentes utilizas, pero deberías utilizar el TQuery más simple.
ExecQuery no devuelve datos por lo que debería ser mucho más rápido. |
#3
|
||||
|
||||
Si las tablas están en la misma BD es mucho mas eficiente un INSERT..SELECT:
__________________
El malabarista. |
#4
|
|||
|
|||
Gracias por la respuesta, pero se trata de insertar datos que están en un archivo externo y debo procesar antes de su inserción.
|
#5
|
||||
|
||||
Hola,
en qué formato están los datos a importar? Cuántos datos son? Saludos
__________________
Cuando los grillos cantan, es que es de noche - viejo proverbio chino - |
#6
|
|||
|
|||
Los archivos fuente están en formato CSV, pero esa información (comprimida) no la puedo pasar directamente a Firebird, yo cojo los datos fuente, los proceso y el resultado es el que pasa a Firebird.
Las fuentes 1,4 GB, pero el resultado de mi proceso generan sobre 500GB. |
#7
|
||||
|
||||
Desactiva trigers, índices y demás antes de iniciar y lo vuelves a activar cuando terminas.
__________________
La otra guía de estilo | Búsquedas avanzadas | Etiquetas para código | Colabora mediante Paypal |
#8
|
|||
|
|||
Gracias, ya está así.
No sé si otro motor me puede permitir hacer inserciones si tener que cerrar y abrir con una consulta cada inserción. |
#9
|
||||
|
||||
Cita:
De todas formas, hay muchas cosas a tener en cuenta de las que no has dado ninguna información. Aparte de que si son 500 GB, ¿eso lo importas una vez o acaso es algo que haces cada día? Ninguna BD va a ser rápida importando 500 GB de datos, y menos todavía leyéndolo de un fichero de texto CSV. Luego las consultas sí son rápidas, no influye el tamaño de la BD... si está bien diseñada. Y aparte no sabemos qué equipo está ejecutando esa BD, qué sistema operativo, qué configuración, cuánta memoria tiene, cómo tienes configurado los caché, directorios temporales, si los discos son rápidos, si hay mucha gente conectada, de qué tamaño son los discos, etc. etc. etc. Por no saber, no sabemos ni qué componentes usas, ni cómo están configurados, ni... nada de nada.
__________________
La otra guía de estilo | Búsquedas avanzadas | Etiquetas para código | Colabora mediante Paypal |
#10
|
||||
|
||||
Lee esta documentación... habla de 100.000 registros y de que va rápido.
https://www.ibexpert.net/ibe/pmwiki....1s%20elementos Seguramente tienes que hacer un análisis más profundo, hacer la carga por la noche para no impactar en el rendimiento, ... no sé, hay varias medidas que puedes tomar, pero dependerán de la situación. Tampoco sabemos cada cuánto tiempo tienes que importar ese volumen de datos. O si de ese volumen todos los datos se insertan o algunos se insertan y otros se actualizan. Por de pronto veo que haces Query1.Insert. Así poco vas a poder correr. Todo apunta a que tengas que hacer INSERTs a tutiplén directamente. Tengo un proceso mensual que carga casi 100.000 registros de una bbdd a otra ( no son firebird ) y tarda 3 minutos y medio. La BBDD ni está optimizada ni nada, tampoco el proceso, no me he roto mucho la cabeza. Se lanzan tantas INSERT como registros. "Actualizados 96449 registros mediante 96449 instrucciones." Mira a ver y sigue informando. Saludos
__________________
Cuando los grillos cantan, es que es de noche - viejo proverbio chino - |
#11
|
|||
|
|||
Si utilizas Firedac, mírate esta opción para inserción masiva: https://docwiki.embarcadero.com/Code...y.Batch_Sample
|
#12
|
|||
|
|||
Yo edito la base de datos con SQL Manager Lite, por favor si penáis que ibExpert es mejor, me lo decís.
No obstante, no sé si el IDE que utilizo para editar la estructura de la base de datos, puede resolver mi problema. Casimiro es cierto que he facilitado poca información, pero en mi humilde opinión eso no afecta a mi consulta inicial. ¿Hay alguna forma con la que pueda insertar sin tener que cerrar y hacer una consulta? Contenido de mi primer post:
|
#13
|
||||
|
||||
Pero si has dicho que estás importando desde un fichero CSV, ¿entonces para qué sirve ese "select de alguna tabla"?
__________________
La otra guía de estilo | Búsquedas avanzadas | Etiquetas para código | Colabora mediante Paypal |
#14
|
||||
|
||||
Cita:
Cita:
Y precisamente, tu pregunta: Cita:
No se entiende ese código si estás importando un fichero de texto. Perdón si parezco algo brusco, es sólo mi forma de "hablar"
__________________
La otra guía de estilo | Búsquedas avanzadas | Etiquetas para código | Colabora mediante Paypal |
#15
|
|||
|
|||
A ver si soy capaz de explicarme:
1 - tengo información un archivo CSV. 2 - Esta información está en formato no compatible con el motor, por ejemplo: la fecha viene "2010.10.15,23.40" = 15/10/2010 23:40:0. Esto me obliga a leer el archivo SCV desde mi aplicación Delphi, hacer conversiones, cálculos (aritméticos, trigonométricos, etc. 3 - El resultado de estas conversiones y cálculos es lo que debo guardar en la base de datos. Si ejecuto la aplicación realizando todo el trabajo: Lectura de CSV, conversiones y cálculos, el trabajo termina en 20 minutos. El problema es que si además intento guardar la información en la base de datos, el proceso puede tardar más de un año (cálculo aproximado empíricamente en función del tiempo que utilizo para tratar 1/100000 partes del fichero CSV. No sé si hay alguna manera de hacerlo más rápido, porque si tarda un año, cuando acabe ya no sirve la información. |
#16
|
|||
|
|||
Trabajo con ADOConection y ADOQuery
|
#17
|
||||
|
||||
Bien, vamos por partes, dices que leer el .csv procesarlo y demás tarda 20 minutos, ok. ¿Y dónde/en qué/cómo/ están esos datos ya procesados para guardarlos en la BD?
__________________
La otra guía de estilo | Búsquedas avanzadas | Etiquetas para código | Colabora mediante Paypal |
#18
|
||||
|
||||
¿ADO para firebird? olvida eso.
Utiliza los componentes de la paleta Interbase: IBdatabase, ibTransaction, dataset, query, etc. O sea, IBX, puede ser el propio de delphi o los libres. ¡Ves cómo si necesitamos información!
__________________
La otra guía de estilo | Búsquedas avanzadas | Etiquetas para código | Colabora mediante Paypal |
#19
|
|||
|
|||
Mi aplicación guarda los datos ya procesados en un registro:
Entonces es cuando necesito insertar estos datos en una tabla de Firebird configurada igual que mi registro Delpfi. Yo siempre he trabajado con ADO (no sé si es la mejor opción) hasta ahora he tenido suficiente, pero nunca había tenido la necesidad de insertar tantos registros seguidos. |
#20
|
||||
|
||||
Vamos progresando
¿Entonces tienes 500 GB en memoria RAM? ¿cuánta RAM tiene ese equipo? ¿De cuántos registros estamos hablando? Para que te hagas una idea de la diferencia de velocidad con diferentes componentes, esto ya es muy antiguo y es orientativo, se realizaron una serie de test de insersión, búsqueda, etc. y el resultado fue este:
__________________
La otra guía de estilo | Búsquedas avanzadas | Etiquetas para código | Colabora mediante Paypal |
|
|
Temas Similares | ||||
Tema | Autor | Foro | Respuestas | Último mensaje |
Insercion masiva desde Paradox a Firebird | MartinS | SQL | 5 | 22-12-2011 15:55:10 |
insercion masiva | Alfredo | Firebird e Interbase | 3 | 12-11-2008 21:34:46 |
Insercion masiva de una BD a otra BD | oscjae | Firebird e Interbase | 5 | 15-12-2006 21:25:49 |
Insercion masiva de registros MUY LENTA | Balda | Firebird e Interbase | 10 | 24-03-2004 22:40:21 |
Inserción masiva en MySQL | Morfo | MySQL | 3 | 09-01-2004 19:05:33 |
|