Untuk opsi kompresi kolom, PostgreSQL 14 menyediakan metode kompresi baru LZ4. Dibandingkan dengan metode kompresi PGLZ yang ada di TOAST, kompresi LZ4 lebih cepat. Artikel ini menjelaskan cara menggunakan seluruh opsi dan membandingkan kinerjanya dengan algoritme kompresi lainnya.
latar belakang
Di PG, halaman adalah unit penyimpanan data, dan defaultnya adalah 8KB. Secara umum, deretan data tidak boleh disimpan di seluruh halaman. Namun, ada beberapa tipe data panjang variabel, dan data yang disimpan dapat melebihi satu halaman universitas. Untuk mengatasi seluruh batasan, bidang besar akan dikompresi atau dipecah menjadi beberapa baris fisik. Teknik ini adalah TOAST:
Secara default, jika ada kolom dengan panjang variabel dalam tabel, dan ukuran data baris melebihi TOAST_TUPLE_THRESHOLD (default 2KB), TOAST akan dipicu. Pertama, data akan dikompres terlebih dahulu; jika masih terlalu besar setelah kompresi, penyimpanan akan meluap. Perlu dicatat bahwa jika strategi penyimpanan kolom menentukan EKSTERNAL/PLAIN, kompresi akan dilarang.
Sebelum PG14, TOAST hanya mendukung satu algoritma kompresi PGLZ (algoritma bawaan PG). Tetapi algoritma kompresi lain mungkin lebih cepat dari PGLZ atau memiliki rasio kompresi yang lebih tinggi. Ada opsi kompresi baru kompresi LZ4 di PG14, yang merupakan algoritma kompresi lossless yang dikenal karena kecepatannya. Jadi kami dapat mengharapkannya untuk membantu meningkatkan kecepatan kompresi dan dekompresi TOAST.
Bagaimana cara menggunakan LZ4?
Untuk menggunakan fitur kompresi LZ4, Anda perlu menentukan -with-lz4 saat kompilasi, dan mengikuti pustaka LZ4 di sistem operasi. Algoritma kompresi default TOAST dari instans PG dapat ditentukan melalui parameter GUC default_toast_compression. Bisa di postgresql. Konfigurasi di conf, Anda juga dapat mengubah hanya koneksi saat ini melalui perintah SET:
postgres SET default roti panggang kompresi lz4
SET
Tentukan algoritma kompresi kolom saat membuat tabel di CREATE TABLE:
Kita dapat menggunakan perintah d+ untuk melihat algoritma kompresi untuk semua kolom. Jika kolom tidak mendukung atau tidak menentukan algoritma kompresi, maka spasi akan ditampilkan di kolom Kompresi. Pada contoh di atas kolom id tidak mendukung algoritma kompresi, kolom col1 menggunakan PGLZ, col2 menggunakan LZ4, dan col3 tidak menentukan algoritma kompresi, maka akan menggunakan algoritma kompresi default.
Anda dapat memodifikasi algoritme kompresi kolom melalui ALTER TABLE, tetapi perlu dicatat bahwa algoritme yang dimodifikasi hanya memengaruhi data penyisipan setelah seluruh perintah dijalankan.
postgres＝＃ INSERT INTO tbl VALUES 1， ulangi（＇abc＇，1000）， ulangi（＇abc＇，1000），ulangi（＇abc＇，1000））；
MASUKKAN 0 1
postgres＝＃ ALTER TABLE tbl ALTER COLUMN col1 SET KOMPRESI lz4；
ALTER TABEL
postgres＝＃ INSERT INTO tbl VALUES 2， ulangi（＇abc＇，1000）， ulangi（＇abc＇，1000），ulangi（＇abc＇，1000））；
MASUKKAN 0 1
postgres＝＃ PILIH id，
postgres, pg, kolom, kompresi, id, kompresi AS, kolid,
postgres, pg, kolom, kompresi, col1, kompresi AS, col1
postgres, pg, kolom, kompresi, col2, kompresi AS, col2
postgres, pg, kolom, kompresi, col3, kompresi AS, col3
postgres－＃ DARI tbl；
id kompresi＿cold kompresi＿col1 kompresi＿col2 kompresi＿col3
kan
1 pglz lz4 lz4
2 lz4 lz4 lz4
2 baris）
Anda dapat melihat bahwa untuk baris yang disisipkan sebelum memodifikasi algoritme kompresi, col1 masih menggunakan algoritme kompresi PGLZ, meskipun algoritme kompresi dimodifikasi dari PGLZ ke LZ4. (Jadi, algoritma mana yang harus digunakan untuk dekompresi setelah modifikasi?)
Perhatikan bahwa jika Anda memindai data dari tabel lain dan memasukkannya ke dalam tabel ini, seperti CREATE TABLE. . . SEBAGAI. . . Atau MASUKKAN KE. . . PILIH. . . , Algoritma kompresi yang digunakan oleh data yang disisipkan masih menggunakan metode kompresi dari data aslinya. pg_dump dan pg_dumpall juga menambahkan opsi-no-toast-compuression. Setelah menggunakan seluruh opsi, opsi kompresi TOAST tidak akan dibuang.
Perbandingan kinerja
Menguji tingkat kompresi dan kecepatan kompresi LZ4 dan PGLZ. Dan menambahkan hasil pengujian data yang tidak terkompresi (strategi penyimpanan yang ditentukan adalah EKSTERNAL). Untuk data yang tidak dikompresi, tidak ada kompresi dan dekompresi yang memakan waktu, tetapi waktu untuk membaca dan menulis data akan meningkat.
Data yang digunakan dalam pengujian: dokumen PG (satu file HTML per baris data); data yang disediakan oleh SilesiaCorpus, termasuk HTML, Teks, kode sumber, file biner yang dapat dieksekusi, dan gambar
Penggunaan mesin ujiIntel? Xeon? Perak 4210 CPU 2．20GHz dengan 10 inti／20 utas／2 soket。
Gunakan pgbench untuk menguji waktu eksekusi pernyataan SQL, dan pg_table_size untuk memeriksa tabel universitas (jalankan VACUUM FULL sebelum setiap eksekusi untuk menghilangkan pengaruh catatan mati).
Rasio kompresi
Tingkat kompresi PGLZ dan LZ4 keduanya bergantung pada data berulang. Semakin banyak tupel yang diulang, semakin tinggi tingkat kompresi. Namun, jika PG menilai tingkat kompresi seperti itu tidak baik, kompresi tidak akan dilakukan, bahkan jika ukuran data mencapai ambang batas. Karena kompresi tidak secara efisien menghemat ruang disk, ini juga membawa waktu ekstra dan konsumsi sumber daya untuk kunci dekompresi.
Pada PG14 saat ini, PGLZ membutuhkan rasio kompresi minimal 25%, sedangkan LZ hanya lebih kecil dibandingkan saat data tidak terkompresi. Saya membandingkan ukuran LZ4, tabel PGLZ dan tabel tidak terkompresi. Dapat dilihat bahwa di sebagian besar skenario, rasio kompresi PGLZ sedikit lebih baik, rasio kompresi dievaluasi sebagai 2.23, dan rasio kompresi LZ4 adalah 2.07. Ini berarti PGLZ dapat menghemat 7% ruang disk.
Gambar 1 Membandingkan ukuran tabel dalam KB）
Kecepatan kompresi / dekompresi
Data TOAST akan dikompresi dan didekompresi selama penyisipan dan kueri. Oleh karena itu, saya mengeksekusi beberapa pernyataan SQL untuk melihat dampak dari algoritma kompresi yang berbeda.
Pertama, bandingkan kinerja pernyataan INSERT, saat menggunakan LZ, PGLZ, dan tidak menggunakan kompresi. Dapat dilihat bahwa dibandingkan dengan data yang tidak dikompresi, LZ4 membutuhkan waktu lebih lama, dan PGLZ membutuhkan lebih banyak waktu. Waktu kompresi LZ4 adalah 20% lebih sedikit dari rata-rata PGLZ. Ini adalah peningkatan yang sangat signifikan.
Gambar 2 Membandingkan kinerja INSERT
Bandingkan PILIH di bawah ini. Dibandingkan dengan PGLZ, LZ4 dapat menghemat 20% waktu, dan tidak ada banyak perbedaan dibandingkan dengan data yang tidak terkompresi. Biaya dekompresi telah dikurangi ke tingkat yang sangat rendah.
Gambar 3 Membandingkan kinerja SELECT
Bandingkan pernyataan INSERT bersamaan dari 16 klien. Dibandingkan dengan PGLZ, kinerja kompresi satu file besar (HTML, teks bahasa Inggris, kode sumber, file biner yang dapat dieksekusi, gambar) menggunakan LZ4 60% -70% lebih cepat. Masukkan beberapa file kecil (file PG), kinerjanya tidak meningkat. Dibandingkan dengan data yang tidak dikompresi, ada peningkatan besar. Diperkirakan bahwa menggunakan kompresi mengurangi jumlah data yang ditulis ke disk.
Gambar 4 Membandingkan kinerja INSERT dengan 16 klien
Dengan 16 PILIHAN klien, LZ4 berkinerja lebih baik daripada PGLZ di sebagian besar skenario:
Gambar 5 Membandingkan kinerja SELECT dengan 16 klien
Ini juga membandingkan kecepatan pemrosesan teks menggunakan fungsi string SELECT dan UPDATE. LZ4 lebih baik daripada PGLZ di seluruh adegan. Dibandingkan dengan data yang tidak dikompresi, data algoritma kompresi LZ4 memiliki kecepatan pemrosesan fungsi yang hampir sama, dan algoritma LZ4 hampir tidak mempengaruhi kecepatan operasi string.
Gambar 6 Membandingkan kinerja menggunakan fungsi string
Dibandingkan dengan PGLZ, LZ4 mengompresi dan mendekompresi data TOAST lebih efisien dan memberikan kinerja yang baik. Dibandingkan dengan data yang tidak dikompresi, kecepatan kueri hampir sama, dan dibandingkan dengan PGLZ, penyisipan 80% lebih cepat. Tentu saja, tingkat kompresi tidak terlalu bagus dalam beberapa skenario, tetapi jika Anda ingin meningkatkan kecepatan eksekusi, sangat disarankan untuk menggunakan algoritma LZ4.
Juga perlu diperhatikan, perlu dipertimbangkan apakah data dalam tabel tersebut cocok untuk dikompresi. Jika rasio kompresinya tidak bagus, ia akan tetap mencoba memampatkan angkanya dan kemudian menyerah. Ini akan menghasilkan tambahanRAMPemborosan sumber daya, dan sangat mempengaruhi kecepatan memasukkan data.
masa depan
LZ4 telah sangat meningkatkan kinerja kompresi dan dekompresi TOAST. Selain LZ4, ada banyak algoritma kompresi lain seperti Zstandard. Pengguna yang mendukung Zstandard bisa mendapatkan rasio kompresi yang lebih baik daripada PGLZ. LZ4 HC memiliki kecepatan kompresi 98.5% daripada dekompresi LZ4, tetapi dapat meningkatkan kecepatan kompresi secara signifikan. Semoga versi PG yang akan datang dapat menggunakan lebih banyak algoritma kompresi.
Selain TOAST, adegan lain juga perlu dikompres. Sejauh yang saya tahu, versi pengembangan saat ini sudah mendukung kompresi LZ4 WAL, yang merupakan fitur menarik.