, versi terbaru dari βdatabase relasional open source terbaik di dunia,β akan dirilis dalam beberapa minggu (jika semuanya berjalan sesuai rencana). Ini mengikuti jadwal yang biasa untuk merilis versi baru dengan banyak fitur baru setahun sekali, dan sejujurnya, itu mengesankan. Itu sebabnya saya menjadi anggota aktif komunitas PostgreSQL.
Menurut pendapat saya, tidak seperti rilis sebelumnya, PostgreSQL 12 tidak berisi satu atau dua fitur revolusioner (seperti partisi atau paralelisme kueri). Saya pernah bercanda bahwa fitur utama PostgreSQL 12 adalah stabilitas yang lebih baik. Bukankah itu yang Anda perlukan saat mengelola data penting bisnis Anda?
Namun PostgreSQL 12 tidak berhenti di situ: dengan fitur dan peningkatan baru, kinerja aplikasi akan lebih baik, dan yang perlu Anda lakukan hanyalah meningkatkan!
(Yah, mungkin membangun kembali indeksnya, tapi dalam rilis ini tidak seseram biasanya.)
Akan sangat bagus untuk memutakhirkan PostgreSQL dan segera menikmati peningkatan signifikan tanpa keributan yang tidak perlu. Beberapa tahun yang lalu, saya meninjau pemutakhiran dari PostgreSQL 9.4 ke PostgreSQL 10 dan melihat bagaimana aplikasi dipercepat berkat paralelisme kueri yang ditingkatkan di PostgreSQL 10. Dan, yang paling penting, hampir tidak ada yang diperlukan dari saya (cukup atur parameter konfigurasi max_parallel_workers).
Setuju, akan lebih mudah jika aplikasi bekerja lebih baik segera setelah peningkatan. Dan kami berusaha keras untuk menyenangkan pengguna, karena PostgreSQL memiliki lebih banyak pengguna.
Jadi bagaimana upgrade sederhana ke PostgreSQL 12 bisa membuat Anda bahagia? Aku akan memberitahumu sekarang.
Peningkatan pengindeksan besar-besaran
Tanpa pengindeksan, database tidak akan berkembang jauh. Bagaimana lagi Anda dapat menemukan informasi dengan cepat? Sistem pengindeksan fundamental PostgreSQL disebut . Jenis indeks ini dioptimalkan untuk sistem penyimpanan.
Kita cukup menggunakan operator CREATE INDEX ON some_table (some_column), dan PostgreSQL melakukan banyak pekerjaan untuk menjaga indeks tetap mutakhir sementara kami terus-menerus menyisipkan, memperbarui, dan menghapus nilai. Semuanya bekerja dengan sendirinya, seolah-olah disihir.
Tapi indeks PostgreSQL punya satu masalah - mereka dan menghabiskan ruang disk ekstra serta mengurangi kinerja pengambilan dan pembaruan data. Yang saya maksud dengan "menggembung" adalah mempertahankan struktur indeks secara tidak efektif. Ini mungkin - atau mungkin tidak - terkait dengan tupel sampah yang dihapus (terima kasih kepada Peter Gaghan atas informasinya))). Penggembungan indeks terutama terlihat pada beban kerja yang indeksnya berubah secara aktif.
PostgreSQL 12 sangat meningkatkan kinerja indeks B-tree, dan eksperimen dengan tolok ukur seperti TPC-C menunjukkan bahwa rata-rata 40% lebih sedikit ruang yang digunakan kini. Sekarang kita menghabiskan lebih sedikit waktu tidak hanya untuk memelihara indeks B-tree (yaitu, pada operasi tulis), tetapi juga untuk mengambil data, karena indeksnya jauh lebih kecil.
Aplikasi yang secara aktif memperbarui tabelnya - biasanya aplikasi OLTP () - akan menggunakan disk dan memproses permintaan dengan lebih efisien. Semakin banyak ruang disk, semakin banyak ruang database yang harus dikembangkan tanpa meningkatkan infrastruktur.
Beberapa strategi peningkatan memerlukan pembangunan kembali indeks B-tree untuk memanfaatkan manfaat ini (mis. tidak akan membangun kembali indeks secara otomatis). Pada versi PostgreSQL sebelumnya, membangun kembali indeks besar pada tabel mengakibatkan waktu henti yang signifikan karena perubahan tidak dapat dilakukan untuk sementara waktu. Namun PostgreSQL 12 memiliki fitur keren lainnya: sekarang Anda dapat membangun kembali indeks secara paralel dengan perintah untuk sepenuhnya menghindari waktu henti.
Ada perbaikan lain pada infrastruktur pengindeksan di PostgreSQL 12. Hal lain di mana ada keajaiban - , alias WAL (log tulis-depan). Log write-ahead mencatat setiap transaksi di PostgreSQL jika terjadi kegagalan dan replikasi. Aplikasi menggunakannya untuk pengarsipan dan . Tentu saja, log write-ahead ditulis ke disk, yang dapat mempengaruhi kinerja.
PostgreSQL 12 telah mengurangi overhead catatan WAL yang dibuat oleh indeks GiST, GIN, dan SP-GiST selama pembuatan indeks. Hal ini memberikan beberapa manfaat nyata: catatan WAL menggunakan lebih sedikit ruang disk, dan data diputar ulang lebih cepat, seperti selama pemulihan bencana atau pemulihan point-in-time. Jika Anda menggunakan indeks tersebut dalam aplikasi Anda (misalnya, aplikasi geospasial berbasis PostGIS banyak menggunakan indeks GiST), ini adalah fitur lain yang akan meningkatkan pengalaman secara signifikan tanpa perlu usaha apa pun dari Anda.
Mempartisi - lebih besar, lebih baik, lebih cepat
PostgreSQL 10 diperkenalkan . Di PostgreSQL 11 menjadi lebih mudah digunakan. Di PostgreSQL 12 Anda dapat mengubah skala bagian.
Di PostgreSQL 12, kinerja sistem partisi menjadi jauh lebih baik, terutama jika terdapat ribuan partisi dalam tabel. Misalnya, jika kueri hanya memengaruhi beberapa partisi dalam tabel yang berjumlah ribuan, kueri akan dieksekusi lebih cepat. Performa tidak hanya ditingkatkan untuk jenis kueri ini. Anda juga akan melihat betapa cepatnya operasi INSERT pada tabel dengan banyak partisi.
Merekam data menggunakan - ngomong-ngomong, ini cara yang bagus dan ini contohnya β tabel yang dipartisi di PostgreSQL 12 juga menjadi lebih efisien. Dengan COPY semuanya sudah cepat, tetapi di PostgreSQL 12 semuanya benar-benar berjalan lancar.
Berkat keunggulan ini, PostgreSQL memungkinkan Anda menyimpan kumpulan data yang lebih besar dan membuatnya lebih mudah diambil. Dan tidak ada usaha dari Anda. Jika aplikasi memiliki banyak partisi, seperti merekam data deret waktu, pemutakhiran sederhana akan meningkatkan kinerjanya secara signifikan.
Meskipun ini bukan peningkatan "tingkatkan dan nikmati", PostgreSQL 12 memungkinkan Anda membuat kunci asing yang mereferensikan tabel yang dipartisi, sehingga membuat partisi menjadi menyenangkan untuk digunakan.
DENGAN pertanyaan menjadi jauh lebih baik
Ketika (alias CTE, alias DENGAN pertanyaan), saya tidak sabar untuk menulis artikel tentangnya . Ini adalah salah satu fitur yang akan mempercepat aplikasi. Kecuali, tentu saja, Anda menggunakan CTE.
Saya sering menemukan bahwa pemula dalam SQL suka menggunakan CTE; jika Anda menulisnya dengan cara tertentu, rasanya seperti Anda sedang menulis program yang sangat penting. Secara pribadi, saya suka menulis ulang pertanyaan ini untuk menyiasatinya tanpa CTE dan meningkatkan produktivitas. Sekarang semuanya berbeda.
PostgreSQL 12 memungkinkan Anda memasukkan jenis CTE tertentu tanpa efek samping (SELECT), yang hanya digunakan sekali menjelang akhir permintaan. Jika saya melacak kueri CTE yang saya tulis ulang, sebagian besar kueri tersebut termasuk dalam kategori ini. Ini membantu pengembang menulis kode yang jelas yang kini juga berjalan dengan cepat.
Selain itu, PostgreSQL 12 mengoptimalkan eksekusi SQL itu sendiri, tanpa Anda harus melakukan apa pun. Dan meskipun saya mungkin tidak perlu mengoptimalkan kueri seperti itu sekarang, bagus sekali PostgreSQL terus berupaya mengoptimalkan kueri.
Just-in-Time (JIT) - sekarang default
Pada sistem PostgreSQL 12 dengan dukungan Kompilasi JIT diaktifkan secara default. Pertama-tama, Anda mendapatkan dukungan untuk beberapa operasi internal, dan kedua, kueri dengan ekspresi (contoh paling sederhana adalah x + y) dalam daftar pilihan (yang Anda miliki setelah SELECT), agregat, ekspresi dengan klausa WHERE, dan lainnya dapat menggunakan JIT untuk meningkatkan kinerja.
Karena JIT diaktifkan secara default di PostgreSQL 12, kinerja akan meningkat dengan sendirinya, namun saya sarankan untuk menguji aplikasi di PostgreSQL 11, yang memperkenalkan JIT, untuk mengukur kinerja kueri dan melihat apakah Anda perlu menyesuaikan sesuatu.
Bagaimana dengan fitur baru lainnya di PostgreSQL 12?
PostgreSQL 12 memiliki banyak fitur baru yang keren, mulai dari kemampuan memeriksa data JSON menggunakan ekspresi rute SQL/JSON standar hingga autentikasi multifaktor dengan parameter clientcert=verify-full, membuat kolom dan banyak lagi. Cukup untuk posting tersendiri.
Seperti PostgreSQL 10, PostgreSQL 12 akan meningkatkan kinerja secara keseluruhan segera setelah peningkatan. Anda, tentu saja, dapat memiliki jalur Anda sendiri - uji aplikasi dalam kondisi serupa pada sistem produksi sebelum mengaktifkan perbaikan, seperti yang saya lakukan dengan PostgreSQL 10. Meskipun PostgreSQL 12 sudah lebih stabil dari yang saya harapkan, jangan malas dalam pengujian aplikasi secara menyeluruh, sebelum melepaskannya ke produksi.
Sumber: www.habr.com