PostgreSQL 12 , versi terbaru "database relasional open-source terbaik di dunia," keluar dalam beberapa minggu (jika semuanya berjalan sesuai rencana). Ini sesuai dengan jadwal yang biasa - versi baru dengan banyak fitur baru keluar setahun sekali, dan, terus terang, itu mengesankan. Karena itu, saya menjadi anggota aktif komunitas PostgreSQL.
Menurut pendapat saya, tidak seperti rilis sebelumnya, PostgreSQL 12 tidak mengandung satu atau dua fungsi revolusioner (seperti partisi atau concurrency of queries). Saya pernah bercanda bahwa fitur utama PostgreSQL 12 lebih stabil. Bukankah itu yang Anda butuhkan ketika Anda mengelola data bisnis penting?
Tetapi PostgreSQL 12 tidak terbatas pada ini: dengan fitur dan penyempurnaan baru, aplikasi akan bekerja lebih baik, dan Anda hanya perlu memutakhirkan!
(Yah, mungkin bahkan membangun kembali indeks, tetapi dalam rilis ini tidak seram seperti dulu.)
Akan bagus untuk memutakhirkan PostgreSQL dan segera menikmati peningkatan signifikan tanpa gerakan yang tidak perlu. Beberapa tahun yang lalu, saya menganalisis peningkatan dari PostgreSQL 9.4 ke PostgreSQL 10 dan melihat bagaimana aplikasi dipercepat karena peningkatan paralelisme permintaan di PostgreSQL 10. Dan, yang paling penting, hampir tidak ada yang diperlukan dari saya (hanya mengatur max_parallel_workers konfigurasi max_parallel_workers ).
Setuju, akan lebih mudah bila, tepat setelah peningkatan, aplikasi bekerja lebih baik. Dan kami berusaha sangat keras untuk menyenangkan pengguna, karena PostgreSQL memiliki lebih dari itu.
Dan bagaimana peningkatan sederhana ke PostgreSQL 12 membuat Anda bahagia? Aku akan memberitahumu sekarang.
Perbaikan pengindeksan utama
Tanpa pengindeksan, basis data tidak akan berjalan jauh. Dan bagaimana lagi mencari informasi dengan cepat? Sistem pengindeksan PostgreSQL yang mendasar disebut B-tree . Jenis indeks ini dioptimalkan untuk sistem penyimpanan.
Kami hanya menggunakan pernyataan CREATE INDEX ON some_table (some_column) , dan PostgreSQL melakukan pekerjaan yang bagus untuk menjaga agar indeks tetap mutakhir sementara kami terus-menerus memasukkan, memperbarui, dan menghapus nilai. Semuanya bekerja dengan sendirinya, seperti sulap.
Tetapi indeks PostgreSQL memiliki satu masalah - mereka menggembung dan mengambil ruang disk tambahan, dan kinerja pengambilan dan pembaruan data berkurang. Dengan "mengasapi," maksud saya tidak efektif mempertahankan struktur indeks. Mungkin atau mungkin bukan karena tuple sampah yang dihapus VACUUM (terima kasih atas informasinya kepada Peter Geoghegan ). Indeks mengasapi sangat terlihat dalam beban kerja di mana indeks secara aktif berubah.
PostgreSQL 12 secara serius meningkatkan kinerja indeks B-tree, dan percobaan dengan tes seperti TPC-C menunjukkan bahwa ruang sekarang digunakan, rata-rata, dengan 40% lebih sedikit. Sekarang kita menghabiskan lebih sedikit waktu tidak hanya untuk mempertahankan indeks B-tree (yaitu, pada operasi penulisan), tetapi juga pada mengekstraksi data, karena indeks telah menjadi jauh lebih kecil.
Aplikasi yang secara aktif memperbarui tabelnya - biasanya aplikasi OLTP ( pemrosesan transaksi real-time ) - jauh lebih efisien dalam menggunakan disk dan memproses permintaan. Semakin banyak ruang disk, semakin banyak ruang yang dimiliki database untuk pertumbuhan tanpa meningkatkan infrastruktur.
Beberapa strategi peningkatan memerlukan pembangunan kembali indeks pohon-B untuk mengambil keuntungan dari ini (misalnya, pg_upgrade tidak akan membangun kembali indeks secara otomatis). Dalam versi PostgreSQL sebelumnya, membangun kembali indeks besar dalam tabel menyebabkan downtime yang signifikan, karena pada saat itu tidak mungkin untuk membuat perubahan. Tetapi PostgreSQL 12 memiliki trik keren lainnya: Anda sekarang dapat membangun kembali indeks secara paralel dengan perintah REINDEX CONCURRENTLY untuk sepenuhnya menghindari downtime.
PostgreSQL 12 memiliki peningkatan lain pada infrastruktur pengindeksan. Hal lain yang tidak bisa dilakukan tanpa sihir adalah log write-ahead, yang juga WAL (write-ahead log). Log tulis-depan mencatat setiap transaksi dalam PostgreSQL jika terjadi kegagalan dan replikasi. Aplikasi menggunakannya untuk cadangan dan memulihkan pada suatu titik waktu . Tentu saja, log tulis-depan ditulis ke disk, dan ini dapat memengaruhi kinerja.
PostgreSQL 12 telah mengurangi overhead WAL yang dibuat oleh indeks GiST, GIN, dan SP-GiST ketika membangun indeks. Ini memberikan beberapa keuntungan nyata: catatan WAL mengambil lebih sedikit ruang disk, dan data direproduksi lebih cepat, misalnya, selama pemulihan dari kegagalan atau pemulihan pada suatu titik waktu. Jika Anda menggunakan indeks seperti itu di aplikasi Anda (misalnya, aplikasi geospasial berbasis PostGIS banyak menggunakan indeks GiST), ini adalah fitur lain yang secara signifikan akan meningkatkan kinerja tanpa upaya dari pihak Anda.
Partisi - Lebih Besar, Lebih Baik, Lebih Cepat
PostgreSQL 10 memperkenalkan partisi deklaratif . PostgreSQL 11 membuatnya lebih mudah digunakan. Di PostgreSQL 12, Anda dapat mengubah skala bagian.
Dalam PostgreSQL 12, kinerja sistem pemartisian jauh lebih baik, terutama jika ada ribuan bagian dalam tabel. Misalnya, jika kueri hanya memengaruhi beberapa bagian dalam tabel, yang jumlahnya ribuan, kueri akan berjalan lebih cepat. Kinerja telah ditingkatkan tidak hanya untuk jenis kueri ini. Anda juga akan melihat bagaimana operasi INSERT telah dipercepat dalam tabel dengan banyak partisi.
Menulis data menggunakan COPY - omong-omong, ini adalah cara yang bagus untuk memuat data massal dan di sini adalah contoh menerima JSON - dalam tabel yang dipartisi di PostgreSQL 12 juga menjadi lebih efisien. Dengan COPY, semuanya sangat cepat, tetapi di PostgreSQL 12 terbang.
Berkat manfaat ini, PostgreSQL dapat menyimpan set data yang lebih besar dan mempermudah pengambilan. Dan tidak ada usaha dari Anda. Jika aplikasi memiliki banyak bagian, misalnya, merekam data deret waktu, peningkatan sederhana akan secara signifikan meningkatkan kinerjanya.
Meskipun peningkatan ini tidak sepenuhnya dari kategori “upgrade and rejoice”, di PostgreSQL 12 Anda dapat membuat kunci asing yang mereferensikan tabel yang dipartisi sehingga bekerja dengan mempartisi adalah suatu kesenangan.
DENGAN pertanyaan jauh lebih baik
Ketika tambalan diterapkan pada ekspresi tabel umum yang terintegrasi (mereka adalah CTE, mereka juga dengan kueri), saya ingin sekali menulis artikel tentang bagaimana pengembang aplikasi dengan PostgreSQL senang . Ini adalah salah satu fitur yang akan mempercepat aplikasi. Kecuali, tentu saja, Anda menggunakan CTE.
Saya sering melihat bahwa pendatang baru di SQL suka menggunakan CTE: jika Anda menulisnya dengan cara tertentu, Anda langsung merasa bahwa Anda sedang menulis program yang penting. Secara pribadi, saya suka menulis ulang pertanyaan ini untuk menghilangkan CTE dan meningkatkan kinerja. Sekarang semuanya berbeda.
PostgreSQL 12 memungkinkan Anda untuk menanamkan tipe CTE tertentu tanpa efek samping ( SELECT ), yang hanya digunakan sekali di dekat akhir kueri. Jika saya menyimpan statistik permintaan dengan CTE yang saya tulis ulang, kebanyakan dari mereka akan masuk dalam kategori ini. Ini membantu pengembang menulis kode yang dapat dimengerti yang sekarang juga bekerja dengan cepat.
Selain itu, PostgreSQL 12 mengoptimalkan pelaksanaan SQL itu sendiri, Anda tidak perlu melakukan apa pun. Dan meskipun sekarang, mungkin, saya tidak perlu mengoptimalkan pertanyaan seperti itu, sangat bagus bahwa PostgreSQL terus bekerja pada optimasi kueri.
Just-in-Time (JIT) - Sekarang Default
Pada sistem PostgreSQL 12 dengan dukungan LLVM , kompilasi JIT diaktifkan secara default. Pertama, Anda mendapatkan dukungan JIT untuk beberapa operasi internal, dan kedua, kueri dengan ekspresi (contoh paling sederhana adalah x + y) dalam daftar pilih (yang Anda miliki setelah SELECT), agregat, ekspresi dengan klausa WHERE dan lainnya. dapat menggunakan JIT untuk meningkatkan kinerja.
Karena JIT dimasukkan dalam PostgreSQL 12 secara default, kinerjanya akan meningkat dengan sendirinya, tetapi saya merekomendasikan pengujian aplikasi di PostgreSQL 11, di mana JIT baru saja muncul untuk mengukur kinerja permintaan dan melihat apakah Anda perlu menyetel apa pun.
Tetapi bagaimana dengan fitur-fitur baru PostgreSQL 12 lainnya?
PostgreSQL memiliki 12 ton fitur baru yang keren - dari kemampuan untuk memeriksa data JSON menggunakan ekspresi rute SQL / JSON standar hingga otentikasi multi-faktor dengan clientcert=verify-full parameter clientcert=verify-full , kolom yang dibuat dan banyak lagi. Cukup untuk pos terpisah.
Seperti PostgreSQL 10, PostgreSQL 12 akan meningkatkan kinerja keseluruhan segera setelah peningkatan. Tentu saja, Anda dapat memiliki cara Anda sendiri - menguji aplikasi di bawah kondisi yang sama dalam sistem kerja sebelum menyalakan perbaikan, seperti yang saya lakukan dengan PostgreSQL 10. Bahkan jika PostgreSQL 12 sudah lebih stabil dari yang saya harapkan, jangan malas untuk menguji kualitas aplikasi, sebelum melepaskannya dalam produksi.