Saya menghabiskan seminggu di kota Lisbon yang megah untuk menghadiri Konferensi PostgeSQL Eropa tahunan. Ini menandai peringatan 10 tahun sejak konferensi PostgreSQL Eropa pertama dan keenam kalinya saya menghadirinya.
Kesan Pertama
Kotanya luar biasa, suasananya luar biasa dan sepertinya akan menjadi minggu yang sangat produktif dan informatif yang penuh dengan percakapan menarik dengan orang-orang yang cerdas dan ramah. Jadi pada dasarnya hal keren pertama yang saya pelajari di Lisbon adalah betapa hebatnya Lisbon dan Portugal, tapi saya rasa Anda datang ke sini untuk sisa cerita!
Buffer Bersama
Kami menghadiri sesi pelatihan “PostgreSQL DBA toolbelt untuk operasi sehari-hari”
oleh Kaarel Moppel (Cybertec) . Satu hal yang saya perhatikan adalah pengaturan shared_buffers. Karena shared_buffers sebenarnya bersaing atau melengkapi cache sistem, itu tidak boleh disetel ke nilai apa pun antara 25% dan 75% dari total RAM yang tersedia. Jadi, meskipun, secara umum, setelan yang disarankan untuk beban kerja tipikal adalah 25% dari RAM, setelan ini dapat disetel ke>=75% untuk kasus khusus, tetapi tidak di antaranya.
Hal lain yang kami pelajari dalam sesi ini:
- sayangnya aktivasi/pengaktifan data-checksum yang mudah secara online (atau offline) belum dalam 11 (initdb/replikasi logis tetap menjadi satu-satunya pilihan)
- hati-hati dengan vm.overcommit_memory, sebaiknya nonaktifkan dengan menyetelnya ke 2. Setel vm.overcommit_ratio ke sekitar 80.
Replikasi Logika Tingkat Lanjut
Dalam pembicaraan Petr Jelinek (Kuadran 2) , penulis asli replikasi logis, kami belajar tentang penggunaan lebih lanjut dari teknologi baru yang menarik ini:
- Pengumpulan Data Terpusat:kami mungkin memiliki beberapa penerbit dan kemudian sistem pusat dengan pelanggan untuk masing-masing penerbit tersebut, membuat data dari berbagai sumber tersedia di sistem pusat. (penggunaan umum:OLAP)
- Data global bersama atau dengan kata lain sistem pusat untuk memelihara data dan parameter global (seperti mata uang, saham, nilai pasar/komoditas, cuaca, dll) yang dipublikasikan ke satu atau lebih pelanggan. Kemudian data ini disimpan hanya dalam satu sistem tetapi tersedia di semua pelanggan.
- Replikasi logis bisa asinkron tetapi juga sinkron (dijamin pada komit)
- Kemungkinan baru dengan decoding logis:
- integrasi dengan Debezium/Kafka melalui plugin decoding logis
- plugin wal2json
- Replikasi dua arah
- Peningkatan waktu henti yang mendekati nol:
- mengatur replikasi logis di server baru (mungkin initdb dengan mengaktifkan data-checksum)
- tunggu sampai lag relatif kecil
- dari pgbouncer menjeda database
- tunggu sampai lagnya nol
- ubah konfigurasi pgbouncer untuk menunjuk ke server baru, muat ulang conf pgbouncer
- dari pgbouncer melanjutkan database
Yang Baru di PostgreSQL 11
Dalam presentasi yang menarik ini, Magnus Hagander (Redpill Linpro AB) memperkenalkan kami keajaiban PostgreSQL 11
- pg_stat_statements mendukung queryid 64-bit.
- pg_prewarm (metode untuk menghangatkan cache sistem atau buffer bersama):penambahan parameter konfigurasi baru
- Peran default baru memudahkan perpindahan dari postgres (pengguna yang saya maksud :) )
- Prosedur tersimpan dengan kontrol aksial
- Penelusuran teks lengkap yang disempurnakan
- Replikasi logis mendukung TRUNCATE
- Cadangan dasar (pg_basebackup) memvalidasi checksum
- Beberapa peningkatan dalam memparalelkan kueri
- Mempartisi bahkan lebih halus daripada di 10
- partisi default
- pembaruan lintas partisi (memindahkan baris dari satu partisi ke partisi lain)
- indeks partisi lokal
- kunci unik di semua partisi (masih belum bisa direferensikan)
- partisi hash
- penggabungan berdasarkan partisi
- agregat berdasarkan partisi
- partisi mungkin tabel asing di server asing yang berbeda. Ini membuka kemungkinan besar untuk sharding berbutir lebih halus.
- Kompilasi JIT
zheap:Jawaban untuk Kesengsaraan PostgreSQL Menggembung
Ini masih belum di 11, tetapi kedengarannya sangat menjanjikan sehingga saya harus memasukkannya ke dalam daftar hal-hal keren. Presentasi diberikan oleh Amit Kapila (EnterpriseDB) salah satu penulis utama teknologi baru ini yang pada akhirnya bertujuan untuk diintegrasikan ke dalam inti PostgreSQL sebagai jenis tumpukan alternatif. Ini akan diintegrasikan dengan API Penyimpanan Pluggable baru di PostgreSQL, yang akan mendukung beberapa Metode Akses Tabel (dengan cara yang sama seperti berbagai Metode Akses [Indeks] yang tercakup dalam blog pertama saya).
Ini akan mencoba memecahkan kekurangan kronis yang dimiliki PostgreSQL dengan:
- meja mengasapi
- perlu vakum (otomatis)
- berpotensi sebagai sampul id transaksi
Semua itu bukan masalah bagi rata-rata bisnis menengah hingga besar (walaupun ini sangat relatif), kita tahu bank dan lembaga keuangan lainnya yang menjalankan PostgreSQL dari puluhan TB data dan beberapa 1000 transaksi/detik tanpa masalah. Tabel mengasapi ditangani oleh autovacuum dan pembekuan baris memecahkan masalah sampul id transaksi, tetapi tetap saja ini tidak bebas perawatan. Komunitas PostgreSQL bekerja menuju database yang benar-benar bebas perawatan, oleh karena itu arsitektur zheap diusulkan. Ini akan membawa:
- log UNDO baru
- UNDO log akan membuat data terlihat oleh transaksi lama dengan melihat versi lama
- UNDO akan digunakan untuk membalikkan efek dari transaksi yang dibatalkan
- perubahan terjadi di tempat. Versi lama tidak lagi disimpan dalam file data.
Sasaran tingkat tinggi:
- kontrol kembung yang lebih baik
- lebih sedikit tulisan
- tajuk tuple yang lebih kecil
Ini akan membuat PostgreSQL setara dengan MySql dan Oracle dalam hal ini.
Kueri Paralel di PostgreSQL:Bagaimana Tidak (salah)Menggunakannya?
Dalam presentasi oleh Amit Kapila dan Rafia Sabih (EnterpriseDB) ini, kami mempelajari bagian dalam paralelisasi dan juga tip untuk menghindari kesalahan umum serta beberapa pengaturan GUC yang disarankan:
- paralelisme hanya mendukung indeks B-tree
- max_parallel_workers_per_gather disetel ke 1→ 4 (tergantung pada inti yang tersedia)
- perhatikan pengaturan berikut:
- parallel_tuple_cost:biaya transfer satu tuple dari proses pekerja paralel ke proses lain
- parallel_setup_cost:biaya peluncuran pekerja paralel dan inisialisasi memori bersama yang dinamis
- min_parallel_table_scan_size:ukuran minimum relasi yang harus dipertimbangkan untuk pemindaian urutan paralel
- min_parallel_index_scan_size:ukuran minimum indeks yang dipertimbangkan untuk pemindaian paralel
- random_page_cost:perkiraan biaya mengakses halaman acak dalam disk
