Ukuran basis data berkurang setelah cadangan di PostgreSQL 8.3 dan kembalikan di PostgreSQL 9.4


8

Saya melakukan pg_dumppada database JIRA yang saya hosting di server PostgreSQL 8.3. Ukuran basis data setelah vacuum fullitu 217132652(sekitar 207 MB).

Kemudian saya mengembalikan database JIRA pada server PostgreSQL 9.4 dengan perintah berikut:

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

Saya menganggap pemulihan akan keluar pada kesalahan apa pun sejak saya gunakan ON_ERROR_STOP=1, tetapi skrip SQL selesai dengan benar (meskipun beberapa peringatan tidak terkait dengan pemulihan data).

Saya berakhir dengan database dengan ukuran 158019348(sekitar 151 MB).

Jadi, bagaimana ceritanya di sini? Bisakah saya berasumsi bahwa basis data berhasil dipulihkan dan PostgreSQL mengoptimalkan penyimpanannya (di suatu tempat antara versi 8.3 dan 9.4) dan menggunakan ruang lebih efisien?


3
Pablo, sudahkah Anda mencoba mengembalikan ke 8.3 dan memeriksa ukurannya? Itu akan mengkonfirmasi atau menghilangkan efek dari versi cahnge
Jack mengatakan coba topanswers.xyz

Jawaban:


10

Ketika Anda mengembalikan database Anda memiliki semua informasi di dalamnya dikemas , tanpa ruang kosong di antara baris (atau dalam indeks), kecuali beberapa pengaturan tertentu sudah ada (pada dasarnya: FILLFACTORuntuk tabel dan FILLFACTORuntuk indeks ).

Di sisi lain, ketika basis data Anda telah digunakan selama beberapa waktu, dan Anda sudah memiliki bagian sisipan, pembaruan, dan penghapusan Anda, ruang kosong yang tidak digunakan akan muncul . Ini karena cara PostgreSQL dan Multiversion Concurrency Control, alias MVCC bekerja. MVCC memungkinkan penguncian lebih sedikit, yang pada dasarnya berarti Anda menghemat waktu . Tetapi Anda membayar harga dalam hal ruang :

  1. Setiap UPDATEsetara dengan INSERTbersama dengan DELETE, dengan overhead (setidaknya dalam hal ruang yang digunakan) yang terkait dengan keduanya.
  2. Bila Anda memiliki beberapa transaksi berjalan, dan setiap orang yang INSERTing, UPDATEing atau DELETEing, Anda harus secara simultan beberapa salinan dari setiap baris yang terlibat.
  3. Ruang yang dialokasikan untuk versi baris ini tidak akan dibebaskan segera setelah komit, dan untuk sementara waktu, akan ada ruang yang tidak digunakan dalam file tempat data tabel Anda (dan indeks) disimpan.

Autovacuum menangani ruang ini yang dapat digunakan kembali secara default, atau Anda dapat memiliki beberapa prosedur khusus untuk menyedot debu secara rutin .

Fakta ini sudah bisa menjelaskan perubahan ukuran.

Optimalisasi antar versi mungkin juga terjadi; dan dapat menjelaskan peningkatan lebih lanjut. Optimalisasi juga dapat dibuat untuk kecepatan dan bukan untuk ukuran, dan ukuran sebenarnya dapat tumbuh dari satu versi ke versi berikutnya. Saya benar-benar tidak tahu secara spesifik untuk bisa mengatakan; meskipun komentar dari @Erwin menyatakan bahwa kedua perubahan yang membuat tabel Anda menyusut dan perubahan yang membuat tabel Anda menggembung (tumbuh) telah terjadi sejak versi 8.3.

Untuk membedakan antara dua efek, jika Anda penasaran, Anda bisa, seperti yang disarankan @Jack Douglas, pulihkan database Anda di 8.3. Kemungkinan besar ukurannya akan menyusut. Jika menyusut menjadi kurang dari 151 MB (ukuran lebih kecil dari yang Anda dapatkan dengan versi 9.4), maka penghapusan ruang yang tidak digunakan membuat DB Anda menyusut, dan perubahan versi sebenarnya membuat DB Anda tumbuh.


Untuk pemahaman yang lebih baik tentang MVCC, lihat presentasi Bruce Momjian .


1
Ini sangat penting. Dan ya, perubahan ukuran tabel dasar menyusut dan kembung telah terjadi sejak Postgres 8.3.
Erwin Brandstetter
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.