Optimice PostgreSQL para una gran cantidad de INSERTOS y actualizaciones bytea

Lo que tenemos (software):

• PostrgeSQL 9.3 con configuración base (sin cambios postgresql.conf)
• Windows 7 de 64 bits

Hardware:

• Intel Core i7-3770 3.9 Ghz
• 32 Gb de RAM
• Unidad WDC WD10EZRX-00L4HBAta (1000 Gb, SATA III)

Entonces, tenemos que cargar en DB aprox. 100,000,000 filas con una columna bytea , y 500,000,000 filas más simples (sin LOB). Hay 2 varcharíndices en la primera tabla (con 13, 19 de longitud) y 2 varcharíndices en la segunda tabla (18, 10 de longitud). También hay secuencias para la generación de id para cada tabla.

Por ahora, estas operaciones se realizan con 8 conexiones en paralelo con 50 tamaños de lote JDBC. La siguiente imagen muestra la carga del sistema: es carga cero en los postgresqlprocesos. Después de 24 horas de carga, hemos cargado solo 10,000,000 filas, lo que es un resultado muy lento.

Estamos pidiendo ayuda para ajustar la PostrgreSQLconfiguración en propósitos de:

1) para la carga ultrarrápida de esta cantidad de datos, es una operación única, por lo que podría ser una configuración temporal

2) para el modo de producción para hacer un número moderado de SELECT en estas 2 tablas por sus índices sin unir y sin ordenar.

Para el insertrendimiento, vea acelerar el rendimiento de inserción en PostgreSQL y la inserción masiva en PostgreSQL .

Estás perdiendo el tiempo con el procesamiento por lotes JDBC insert. PgJDBC no hace nada útil con insertlotes, solo ejecuta cada declaración . <- Esto ya no es cierto en las versiones más nuevas de PgJDBC, que ahora pueden procesar declaraciones preparadas para reducir considerablemente los tiempos de ida y vuelta. Pero aún es mejor:

Use en su COPYlugar; ver copia por lotes PgJDBC y el CopyManager. En cuanto al número de cargadores concurrentes: apunte a un par por disco, si las operaciones están vinculadas a E / S de disco. Ocho es probablemente lo máximo que querrás.

Para su "modo de producción", sugiero cargar una muestra de datos, configurar las consultas que espera ejecutar y utilizar explain analyzepara investigar el rendimiento. Solo para fines de prueba, use los enable_parámetros para explorar diferentes selecciones de planes. Establecer los parámetros de costos planeador de consultas ( random_page_cost, seq_page_cost, effective_cache_size, etc.) apropiada para su sistema, y asegurarse de que shared_buffersel valor apropiado. Continúe monitoreando a medida que agrega una carga de trabajo de producción simulada, utilizando el auto_explainmódulo, la log_min_duration_statementconfiguración, la pg_stat_statementsextensión, etc.

Para más detalles, consulte el manual de usuario de PostgreSQL. Sugiero volver aquí cuando tenga un problema más concreto con los explain analyzedetalles de ejecución de consultas, etc.