Используйте нативный путь bulk-load базы (Postgres COPY, MySQL ), разбейте файл на чанки, загружаемые в с индексами и ограничениями, затем один раз перестройте индексы и слейте — и сделайте всю работу , чтобы сбой можно было продолжить без дублирования строк.
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
Наивный INSERT на строку платит round-trip, парсинг, запись WAL/redo и обновление индекса 100 миллионов раз. Даже при 1 мс на каждый это больше суток. Bulk-пути выигрывают, амортизируя всё это: COPY стримит строки в одном протокольном сообщении, батчит WAL и пропускает планирование на оператор. На реальном железе одиночный COPY даёт 100k–500k строк/с против нескольких тысяч у INSERT.
UNLOGGED в Postgres полностью пропускает WAL), никогда не прямо в живую. Это изолирует загрузку от читателей и позволяет валидировать перед публикацией.CREATE INDEX один раз — построение индекса bulk-ом (отсортированно) намного дешевле 100 млн инкрементных обновлений.COPY. Throughput масштабируется с I/O и CPU, пока не насытите диск или WAL. Подбирайте N под ядра/IOPS, а не «сколько получится».INSERT ... ON CONFLICT DO NOTHING/UPDATE (upsert), чтобы повторный запуск не задваивал.Интервьюер проверяет, знаете ли вы, что bulk-путь существует и почему он на порядки быстрее — а не синтаксис COPY. Хорошо: «использовать COPY». Отлично: «COPY в UNLOGGED staging-таблицу, индексы убраны, параллельные чанки, перестроить после, upsert для публикации, возобновляемо по chunk id». Классическая ловушка — цикл INSERT-ов (или ORM saveAll) и удивление, что это занимает часы; вторая — загрузка прямо в живую таблицу и блокировка продакшена.
maintenance_work_mem/temp-пространство; построение индекса на 100 млн строк может уходить на диск.Библиотека вопросов для IT-собеседований с подробными ответами — от Junior до Senior.
Поддержать