2010-08-09 14 views
9

que tienen una estructura de datos que tiene este aspecto:¿Cómo importar * enormes * fragmentos de datos a PostgreSQL?

Model Place 
    primary key "id" 

    foreign key "parent" -> Place 
    foreign key "neighbor" -> Place (symmetryc) 
    foreign key "belongtos" -> Place (asymmetric) 

    a bunch of scalar fields ... 

Tengo más de 5 millones de filas de la tabla modelo, y tengo que insertar ~ 50 millones de filas en cada una de las dos tablas de claves foráneas. Tengo SQL archivos que se ven así:

INSERT INTO place_belongtos (from_place_id, to_place_id) VALUES (123, 456); 

y que están a punto 7 Gb cada uno. El problema es que cuando hago psql < belongtos.sql, me toma aproximadamente 12 horas para importar ~ 4 millones filas en mi CPU AMD Turion64x2. OS es Gentoo ~ amd64, PostgreSQL es la versión 8.4, compilada localmente. El directorio de datos es un montaje de enlace, ubicado en mi segunda partición extendida (ext4), que creo que no es el cuello de botella.

Sospecho que lleva mucho tiempo insertar las relaciones de clave foránea porque psql comprueba las restricciones de clave para cada fila, lo que probablemente agrega cierta sobrecarga innecesaria, ya que estoy seguro de que los datos son válidos. ¿Hay alguna manera de acelerar la importación, es decir, deshabilitar temporalmente la verificación de restricciones?

+0

sí, pero creo que solo en 8.4+ hmm tiene que buscarlo ... – xenoterracide

Respuesta

16
  1. asegurarse de que tanto las claves foráneas son DEFERRABLE
  2. Uso COPY para cargar sus datos
  3. Si no puede utilizar la copia, utilice un prepared statement para su INSERT.
  4. La configuración de ajustes de Propper también ayudará, compruebe la configuración de WAL.
+4

+1 por COPIA, hace una gran diferencia en los DB que encuentro que insertan toneladas de datos regularmente ... – Ryley

+0

Ya uso DEFERRABLE. COPY es lo que estaba buscando, ¡gracias! –

+0

Usar una opción deferible es una cosa, realmente usar esta opción es otra cosa: DIFUNDIDO INICIALMENTE o ESTABLECER RESTRICCIONES TODO DIFERIDO; –

0

La respuesta es sí ... Depesz wrote an article here on deferrable uniqueness. desafortunadamente parece ser una característica de 9.0.

hmm ... ¿Tal vez ese artículo no se aplica a su situación? Parece que hemos sido capaces de set constraints to deferred por un tiempo ... Supongo que única es una situación única (juego de palabras).

+0

Las claves externas ya son diferibles en versiones anteriores, no hay problema. –

+0

Oye, aprende algo nuevo todos los días;). – xenoterracide

+0

El artículo de Depesz describe restricciones diferibles * únicas * (por ejemplo, una clave principal) que no eran diferibles antes de 9.0, p. para ejecutar UPDATE id = id + 1 (donde id es una columna PK) Las restricciones FK regulares han sido "siempre" diferibles. Establecer la restricción para diferir no impedirá la comprobación, solo retrasará la comprobación hasta el final de la transacción (es decir, cuando se ejecute la confirmación) –

Cuestiones relacionadas