Размер базы данных уменьшился после резервного копирования в PostgreSQL 8.3 и восстановления в PostgreSQL 9.4


8

Я сделал pg_dumpдля базы данных JIRA, которую я размещал на сервере PostgreSQL 8.3. Размер базы данных после vacuum fullбыл 217132652(примерно 207 МБ).

Затем я восстановил эту базу данных JIRA на сервере PostgreSQL 9.4 с помощью следующей команды:

$ psql -X -v ON_ERROR_STOP=1 -d jira2 -U jira -h localhost < jiradb2017_03_12.sql

Я предполагаю, что восстановление завершится при любой ошибке, так как я использовал ON_ERROR_STOP=1, но сценарий SQL завершился правильно (несмотря на некоторые предупреждения, не связанные с восстановлением данных).

Я закончил с базой данных размером 158019348(примерно 151 МБ).

Итак, что за история здесь? Могу ли я просто предположить, что база данных была успешно восстановлена, а PostgreSQL оптимизировал механизм хранения (где-то между версиями 8.3 и 9.4) и использует пространство более эффективно?


3
Пабло, ты пробовал восстановить до 8.3 и проверить размер? Это подтвердит или устранит любой эффект версии cahnge,
говорит Джек, попробуйте topanswers.xyz

Ответы:


10

Когда вы восстанавливаете базу данных, у вас упаковывается вся информация , без пустого пространства между строками (или в индексах), если только не установлены какие-то конкретные настройки (в основном: FILLFACTORдля таблиц и FILLFACTORдля индексов ).

С другой стороны, когда ваша база данных используется в течение некоторого времени, и у вас есть доля вставок, обновлений и удалений, появится свободное неиспользуемое пространство . Это из-за того , как работают PostgreSQL и Multiversion Concurrency Control, или MVCC . MVCC позволяет меньше блокировок, что в основном означает, что вы экономите время . Но вы платите цену с точки зрения пространства :

  1. Каждый UPDATEэквивалентен a INSERTвместе с a DELETE, с накладными расходами (по крайней мере, с точки зрения используемого пространства), связанными с обоими.
  2. Когда у вас запущено несколько транзакций, и каждая из них выполняет INSERT, UPDATEвводит или DELETEделает, у вас одновременно несколько копий каждой строки.
  3. Пространство, выделенное для этих версий строк, не будет освобождено сразу после принятия, и какое-то время будет неиспользуемым пространством в файлах, где хранятся данные вашей таблицы (и индексы).

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

Этот факт уже может объяснить изменение размера.

Оптимизация между версиями, вероятно, также имела место; и может объяснить дальнейшие улучшения. Оптимизация также могла быть сделана для скорости, а не для размера, и фактический размер мог фактически расти от одной версии до следующей. Я действительно не знаю особенностей, чтобы быть в состоянии сказать; хотя в комментарии @Erwin говорится, что с версии 8.3 произошли как изменения, приводящие к сокращению ваших таблиц, так и изменения, приводящие к их разрастанию (росту).

Чтобы различать эти два эффекта, если вам интересно, вы можете просто, как предлагает @Jack Douglas, восстановить базу данных на 8.3. Скорее всего, он уменьшится в размере. Если он уменьшается до 151 МБ (размер меньше, чем у версии 9.4), то удаление неиспользуемого пространства привело к сокращению вашей БД, а изменение версии фактически привело к росту вашей БД.


Для лучшего понимания MVCC посмотрите презентацию Брюса Момджяна .


1
Это очень важно. И да, с Postgres 8.3 произошли изменения как размера, так и размера таблицы.
Эрвин Брандштеттер
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.