Saya telah memperbarui / mengakses tabel di mana saya menyimpan objek java serial. Mereka berada di tabel selama 2-3 jam (juga sedang diperbarui selama periode itu) dan kemudian dihapus. Ukuran meja sekitar 300MB. Saya telah melihatnya sangat, sangat sering VACUUMed dan bertanya-tanya apakah mengubah fillfactorakan membantu?
Jawaban:
Kata-kata kunci di sini adalah:
Poin 1. adalah indikasi untuk faktor pengisian yang lebih rendah, sedangkan 2. adalah kebalikannya. Ini membantu kinerja jika beberapa versi baris disimpan pada halaman data yang sama. Pembaruan HOT akan mencapai itu. Baca di sini atau di sini . Mereka membutuhkan ruang gerak pada halaman data - seperti tupel mati atau ruang yang disediakan oleh fillfactor<100. Tetapi mereka hanya dapat melakukan hal mereka, jika tidak ada indeks yang melibatkan kolom yang diperbarui , yang seharusnya berlaku untuk kasus Anda.
Faktor penting lainnya di sini adalah ukuran tuple (dibandingkan dengan ukuran halaman Anda (yang paling umum 8 kb). Lebih detail dalam jawaban terkait ini:
Jika ukuran tupel adalah 4 kb atau lebih, mengurangi faktor pengisian akan sia-sia, karena tidak akan pernah ada lebih dari satu tupel pada halaman data. Anda mungkin membiarkannya di 100(yang merupakan defaultnya). Namun, beberapa tipe data "dipanggang" dan disimpan di luar jalur jika melebihi batas ukuran, sehingga tupel yang membutuhkan banyak garpu hubungan utama jarang.
Apa pun yang Anda lakukan, VACUUM akan sering dijalankan. Dan itu umumnya hal yang baik, saya tidak akan khawatir tentang itu. Anda membuat banyak tupel mati. VACUUMmengidentifikasi baris mati yang tidak terlihat oleh transaksi terbuka lagi. Manual:
Bentuk standar
VACUUMmenghapus versi baris mati dalam tabel dan indeks dan menandai ruang yang tersedia untuk digunakan kembali di masa depan .
Penekanan berani saya.
Anda dapat bermain dengan pengaturan per-tabel untuk autovacuum agar lebih jarang memicu (atau lebih) untuk tabel ini saja:
Ambang batas default dan faktor skala diambil dari
postgresql.conf, tetapi dimungkinkan untuk menimpanya berdasarkan tabel-demi-tabel ;
Penekanan berani saya. Khususnya dengan autovacuum_vacuum_thresholddanautovacuum_vacuum_scale_factor . Berlari VACUUMbanyak mungkin sebenarnya ide yang bagus, bukan yang sangat rendah fillfacter. Itu tergantung pada pola akses. Jika semua tuple hidup, katakanlah, 3 jam dan masing-masing diperbarui beberapa kali, saya masih akan menurunkannya fillfactormenjadi sekitar 50. Anda harus menguji dan menemukan sweet spot.
Selain itu, karena data Anda tampaknya tidak stabil untuk memulai dengan: gunakan UNLOGGEDtabel :
Data yang ditulis pada tabel yang tidak di-log tidak dituliskan ke log tulis-depan (lihat Bab 29 ), yang membuatnya jauh lebih cepat daripada tabel biasa. Namun, mereka tidak aman untuk crash : tabel yang tidak di- log secara otomatis terpotong setelah crash atau shutdown yang tidak bersih. Isi dari tabel yang tidak di-log juga tidak direplikasi ke server siaga.
Penekanan kuat pada saya. Jangan gunakan ini jika server Anda mungkin macet dan Anda masih membutuhkan data setelahnya. Tetapi jika kita berbicara tentang data sesi untuk aplikasi web, ini mungkin harga yang dapat diterima untuk membayar.
Atau, yang lebih radikal: Gunakan toko nilai kunci seperti Redis jika Anda dapat melakukannya tanpa fitur dan keamanan yang disediakan oleh RDBMS sama sekali.
Saya akan menyarankan DBMS nilai kunci, tapi saya membuang ini di luar sana demi kepentingan.
Alih-alih melakukan pernyataan INSERT & DELETE, hanya lakukan UPDATE.
Struktur tabel akan seperti ini
ID integer -- sequential ID
Used boolean -- default FALSE
Object -- whatever type is appropriate
Kolom penahan objek akan memiliki panjang tetap untuk menghindari perpecahan dan gerakan baris. Ukuran kolom ini untuk mengakomodasi objek Anda dan untuk mengisi halaman pada disk secara efisien.
Pra-isi tabel Anda dengan sebanyak mungkin baris yang Anda butuhkan dan beberapa lainnya.
Ketika sebuah objek ditulis, temukan baris dengan Used = False dan UPDATE baris itu. Saat sebuah objek akan dihancurkan, atur dulu objek itu ke "False". Tidak ada sampah yang dibuat dan karenanya tidak ada pengumpulan sampah.
Tentu saja ada banyak, banyak kondisi pengecualian untuk ditangani (limpahan baris, limpahan tabel, kondisi balapan pada penggunaan ID dll.) Tetapi tidak ada yang dapat diatasi.