примере КЛАДР (пункт 3.1 - алгоритм полной синхронизации): https://habr.com/ru/company/tensor/blog/492464/
Суть в том, что есть большая таблица на миллионы строк и нужно обновлять в ней данные, а в обновлении очень мало строк меняется, поэтому данные заливаются в temp таблицу и силами PG делаются апдейты существующих строк, удаляются отсутствующие в новой выгрузке и добавляются недостающие в старой таблице.
У меня ровно такая же задача, в таблице 150 млн строк, пытался делать через вычитку и обновление силами python, заоптимизировался так, что уже некуда (redis для кеша, copy на вставку, fsync = off, synchronous_commit = off, full_page_writes = off, unlogged table и тд) - и всё равно обновление проходит больше чем 24 часа, что неприемлимо. Хочу пробовать кейс из этого примера, поэтому возникла пара вопросов, может быть кто-то делает что-то подобное и может подсказать:
1. На сколько вообще в предложенном примере оптимально написаны запросы для обработки (фактически построчной вычитки / объединения через антиджоин) 2х таблиц по 150 млн строк?
2. Что бы вы подкрутили в настройках pg, чтоб эти запросы выполнялись быстрее (вначале добавление данных через COPY, а потом апдейты/инсерты)? Памяти на сервере 4ГБ, 3ГБ могу отдать целиком PG.
памяти бы 32 гб, ну да ладно. я бы делал итеративный апдейт по 500-1500 строк за итерацию и занимался бы оптимзацией по факту получения значений на итерацию, а потом 150M/итерацию и смотрел бы на результат. Одним из шагов было бы партиционирование (возможно, временное) по стабильному индексу из входных данных, если это возможно и в таком случае запускал бы параллельные итерации
Обсуждают сегодня