pg_restore занимает намного больше времени, чем pg_dump

Я регулярно сохраняю и позже восстанавливаю небольшую базу данных PostgreSQL, которая используется для тестирования. Его данные регулярно обновляются в результате тестов, затем необходимо создать новый дамп, и дампы регулярно используются для воссоздания базы данных в четко определенном состоянии.

Я заметил, что дамп (использование pg_dump -Fc database) занимает всего несколько секунд, но восстановление ( pg_restore -d database) занимает около минуты. Это кажется странным. Я ожидал бы, что оба будут занимать примерно одинаковое время (при условии, что обе задачи связаны с вводом / выводом).

Есть ли проблема с восстановлением? Могу ли я сделать это быстрее? Или это нормально, что восстановление занимает намного больше времени, чем дамп? (И если да, то почему?)

Файл дампа обычно имеет около 3-4 МиБ; СУБД - это PostgreSQL V8.4, работающая на Pentium4 3 ГГц с оперативной памятью 1 ГБ под Ubuntu Linux.

performance postgresql database-backup

— sleske
источник

Ответы:

Содержимое индекса не является частью резервной копии, а только определением индекса. И это займет всего несколько байтов. Когда индекс создается во время восстановления и все данные индексируются, он будет намного больше. Это займет время, но это зависит от вашей ситуации, сколько времени.

У pg_restore есть возможность одновременного восстановления ( начиная с версии 8.4), используйте--jobs=number-of-jobs

— Фрэнк Хейкенс
источник

Интересно, спасибо. Есть ли способ также сбросить индекс, чтобы ускорить восстановление (за счет большего файла дампа)?

— Слеське

Нет, содержимое индекса не может быть частью резервной копии. Для очень маленькой базы данных, такой как ваша (3-4 МиБ), это не должно быть проблемой в любом случае.

— Фрэнк Хейкенс

Дополнительная информация: pg_dump не имеет доступа к содержимому индекса. pg_dump использует операторы SELECT для получения всего содержимого таблиц и содержимого системных таблиц для создания резервной копии. Это просто оболочка для некоторых операторов SELECT и некоторых функций для записи результатов на диск.

— Фрэнк Хейкенс

@Frank: Спасибо. Не знал о реализации pg_dump. В нашем случае было бы полезно ускорить восстановление, потому что оно должно запускаться многократно как часть автоматизированных тестов, поэтому снижение его с 1 минуты до 10 секунд поможет. Но, видимо, это невозможно. Я должен найти другое решение ...

— sleske

@Sleske, вы можете попробовать с подходом резервного копирования файловой системы . Это должно сохранить индексы и, кроме того, вероятно, работать немного быстрее для резервного копирования и восстановления

— Stefano

Для восстановления база данных должна сделать много дополнительной работы:

Некоторые вещи приходят на ум сразу:

Письмо медленнее, чем чтение
Разбор ввода занимает время
Обновление индексов и других внутренних структур
Поддержание ссылочной целостности

Не уверен, если это составляет эту разницу во времени, хотя.

— Свен
источник