D
вот, 5 милионов записей. и настравилаи батч инсерт по 100 штук
Size: a a a
2019 January 10
D
постгрес после 20ой заливки только перезагрузкой спасать можно было
D
я читал на эту тему, говорят что просто обычныве штучные инсерты работают в 10 примерно раз быстрее чем батчинсерты
ПН
гуглить можно бесконечно долго ) моет просто кто-то недавно сталкивался с проблемой
обычно для БД используют миграции (flyway/liquibase), и там можно отдельной миграцией всё сделать. При старте приложения БД докатывается до последней версии
D
может такое быть ?
ПН
я читал на эту тему, говорят что просто обычныве штучные инсерты работают в 10 примерно раз быстрее чем батчинсерты
чииво
D
про ликвибейз - знаю такой метод, спс. лениво писать sql rjl ))
ПН
больше читайте интернетов. Меньше проверяйте
D
не, я сам лично не проверял
ПН
самое медленное — по инсерту на транзакцию
D
короче пробовали 5 милионов по 100 штук в батче
D
а если одна транзакция на все инсерты
D
ты уверен что это не preliminary optimization — что-то вынести в справочник и закэшировать? )
ты уверен что именно это тормозит? )
Типа, чтобы запрос в бд на выборку по ключу из 5к объектов тормозил — это что-то невероятное
ты уверен что именно это тормозит? )
Типа, чтобы запрос в бд на выборку по ключу из 5к объектов тормозил — это что-то невероятное
не понял твой вопрос
ПН
вот, 5 милионов записей. и настравилаи батч инсерт по 100 штук
у нас был проект где каждую ночь перестраивается БД из 10кк объектов + всякая мишура к ним в виде справочников. Считается дифф, что-то добавляется, что-то удаляется, что-то обновляется
ПН
Всё работало как часы, пачками в транзакциях, да
ПН
Никакие постгресы не ребутались :))
D
ну считать дифф с помощью ликвибейза это одно. а нагенерировать 5кк записей 20-30 раз подряд ( для графиков ) немного другое
ПН
а если одна транзакция на все инсерты
постгресу будет так себе. Делайте короткие транзакции, по 1к-10к записей за раз менять. Лучше INSERT INTO ..... VALUES ( <1>, <2>, .....);
D
ну т.е. , батчами )
ПН