Я сделал 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) и использует пространство более эффективно?
источник
Ответы:
Когда вы восстанавливаете базу данных, у вас упаковывается вся информация , без пустого пространства между строками (или в индексах), если только не установлены какие-то конкретные настройки (в основном:
FILLFACTOR
для таблиц иFILLFACTOR
для индексов ).С другой стороны, когда ваша база данных используется в течение некоторого времени, и у вас есть доля вставок, обновлений и удалений, появится свободное неиспользуемое пространство . Это из-за того , как работают PostgreSQL и Multiversion Concurrency Control, или MVCC . MVCC позволяет меньше блокировок, что в основном означает, что вы экономите время . Но вы платите цену с точки зрения пространства :
UPDATE
эквивалентен aINSERT
вместе с aDELETE
, с накладными расходами (по крайней мере, с точки зрения используемого пространства), связанными с обоими.INSERT
,UPDATE
вводит илиDELETE
делает, у вас одновременно несколько копий каждой строки.Autovacuum заботится о том, чтобы это пространство делалось многократно используемым по умолчанию, или у вас может быть какая-то особая процедура для обычной уборки .
Этот факт уже может объяснить изменение размера.
Оптимизация между версиями, вероятно, также имела место; и может объяснить дальнейшие улучшения. Оптимизация также могла быть сделана для скорости, а не для размера, и фактический размер мог фактически расти от одной версии до следующей. Я действительно не знаю особенностей, чтобы быть в состоянии сказать; хотя в комментарии @Erwin говорится, что с версии 8.3 произошли как изменения, приводящие к сокращению ваших таблиц, так и изменения, приводящие к их разрастанию (росту).
Чтобы различать эти два эффекта, если вам интересно, вы можете просто, как предлагает @Jack Douglas, восстановить базу данных на 8.3. Скорее всего, он уменьшится в размере. Если он уменьшается до 151 МБ (размер меньше, чем у версии 9.4), то удаление неиспользуемого пространства привело к сокращению вашей БД, а изменение версии фактически привело к росту вашей БД.
Для лучшего понимания MVCC посмотрите презентацию Брюса Момджяна .
источник