Usa la ruta nativa de bulk-load de la base de datos (Postgres COPY, MySQL ), divide el fichero en chunks cargados hacia una con índices y constraints , luego reconstruye los índices una vez y haz merge — y haz todo el job para que un crash pueda reanudar sin duplicar filas.
LOAD DATA100M-row CSV
│ split by byte offset
▼
[chunk 1] [chunk 2] ... [chunk N] N parallel workers
│ │ │
└──── COPY / LOAD DATA (no indexes) ────▶ staging_table (UNLOGGED)
│
rebuild indexes + validate
│
INSERT ... SELECT (upsert) into target
Un INSERT ingenuo por fila paga un round-trip, un parse, una escritura WAL/redo y una actualización de índice 100 millones de veces. A incluso 1ms cada uno son más de un día. Las rutas bulk ganan amortizando todo esto: COPY transmite filas en un único mensaje de protocolo, agrupa el WAL, y se salta el planning por sentencia. En hardware real un único COPY hace 100k–500k filas/s frente a unos pocos miles del INSERT.
UNLOGGED en Postgres se salta el WAL por completo), nunca directamente en la tabla viva. Esto aísla la carga de los lectores y te deja validar antes de publicar.CREATE INDEX una vez — construir un índice en bulk (ordenado) es mucho más barato que 100M de actualizaciones incrementales.COPY. El throughput escala con el I/O y la CPU hasta que saturas el disco o el WAL. Ajusta N a los cores/IOPS, no a "tantos como sea posible".INSERT ... ON CONFLICT DO NOTHING/UPDATE (upsert) para que re-ejecutar nunca inserte doble.El entrevistador está comprobando si sabes que la ruta bulk existe y por qué es órdenes de magnitud más rápida — no la sintaxis de COPY. Bueno: "usa COPY". Excelente: "COPY hacia una staging table UNLOGGED, índices eliminados, chunks paralelos, reconstruir después, upsert para publicar, reanudable por chunk id." La trampa clásica es hacer bucle de INSERTs (o un saveAll de ORM) y sorprenderse de que tarde horas; la segunda trampa es cargar directamente en la tabla viva y bloquear producción.
maintenance_work_mem/espacio temporal; una construcción de índice de 100M de filas puede desbordar a disco.Una biblioteca de preguntas de entrevista de IT con respuestas detalladas — de Junior a Senior.
Donar