Naik taraf untuk yang malas: bagaimana PostgreSQL 12 meningkatkan prestasi

PostgreSQL 12, versi terkini "pangkalan data hubungan sumber terbuka terbaik di dunia," akan keluar dalam beberapa minggu (jika semuanya berjalan mengikut rancangan). Ini mengikut jadual biasa mengeluarkan versi baharu dengan satu tan ciri baharu sekali setahun, dan terus terang, itu mengagumkan. Itulah sebabnya saya menjadi ahli aktif komuniti PostgreSQL.

Pada pendapat saya, tidak seperti keluaran sebelumnya, PostgreSQL 12 tidak mengandungi satu atau dua ciri revolusioner (seperti pembahagian atau persamaan pertanyaan). Saya pernah bergurau bahawa ciri utama PostgreSQL 12 adalah kestabilan yang lebih besar. Bukankah itu yang anda perlukan apabila anda mengurus data kritikal perniagaan anda?

Tetapi PostgreSQL 12 tidak berhenti di situ: dengan ciri dan penambahbaikan baharu, aplikasi akan berprestasi lebih baik, dan apa yang anda perlu lakukan ialah menaik taraf!

(Nah, mungkin membina semula indeks, tetapi dalam keluaran ini ia tidak semenakutkan seperti biasa.)

Adalah bagus untuk menaik taraf PostgreSQL dan segera menikmati peningkatan yang ketara tanpa kekecohan yang tidak perlu. Beberapa tahun yang lalu, saya menyemak naik taraf daripada PostgreSQL 9.4 kepada PostgreSQL 10 dan melihat bagaimana aplikasi dipercepatkan terima kasih kepada persamaan pertanyaan yang lebih baik dalam PostgreSQL 10. Dan, yang paling penting, hampir tiada apa yang diperlukan daripada saya (hanya tetapkan parameter konfigurasi max_parallel_workers).

Setuju, adalah mudah apabila aplikasi berfungsi dengan lebih baik serta-merta selepas naik taraf. Dan kami berusaha keras untuk menggembirakan pengguna, kerana PostgreSQL mempunyai lebih ramai pengguna.

Jadi bagaimanakah peningkatan mudah kepada PostgreSQL 12 boleh menggembirakan anda? Saya akan memberitahu anda sekarang.

Penambahbaikan pengindeksan utama

Tanpa pengindeksan, pangkalan data tidak akan pergi jauh. Bagaimana lagi anda boleh mencari maklumat dengan cepat? Sistem pengindeksan asas PostgreSQL dipanggil B-pokok. Jenis indeks ini dioptimumkan untuk sistem storan.

Kami hanya menggunakan operator CREATE INDEX ON some_table (some_column), dan PostgreSQL melakukan banyak kerja untuk memastikan indeks dikemas kini semasa kami sentiasa memasukkan, mengemas kini dan memadam nilai. Semuanya berfungsi sendiri, seolah-olah dengan sihir.

Tetapi indeks PostgreSQL mempunyai satu masalah - mereka sedang melambung dan mengambil ruang cakera tambahan dan mengurangkan prestasi pengambilan dan pengemaskinian data. Dengan "kembung" yang saya maksudkan tidak berkesan mengekalkan struktur indeks. Ini mungkin - atau mungkin tidak - berkaitan dengan tupel sampah yang dialihkannya VACUUM (terima kasih kepada Peter Gaghan atas maklumat itu)Peter Geoghegan)). Kembung indeks amat ketara dalam beban kerja di mana indeks berubah secara aktif.

PostgreSQL 12 sangat meningkatkan prestasi indeks B-tree, dan percubaan dengan penanda aras seperti TPC-C telah menunjukkan bahawa secara purata 40% kurang ruang kini digunakan. Kini kami menghabiskan lebih sedikit masa bukan sahaja untuk mengekalkan indeks B-tree (iaitu, pada operasi tulis), tetapi juga untuk mendapatkan semula data, kerana indeksnya jauh lebih kecil.

Aplikasi yang aktif mengemas kini jadual mereka - biasanya aplikasi OLTP (pemprosesan transaksi masa nyata) - akan menggunakan cakera dan memproses permintaan dengan lebih cekap. Lebih banyak ruang cakera, lebih banyak ruang pangkalan data perlu berkembang tanpa menaik taraf infrastruktur.

Sesetengah strategi naik taraf memerlukan membina semula indeks B-tree untuk memanfaatkan faedah ini (mis. pg_upgrade tidak akan membina semula indeks secara automatik). Dalam versi PostgreSQL sebelum ini, membina semula indeks besar pada jadual mengakibatkan masa henti yang ketara kerana perubahan tidak dapat dibuat dalam masa yang sama. Tetapi PostgreSQL 12 mempunyai satu lagi ciri hebat: kini anda boleh membina semula indeks selari dengan arahan REINDEX SERENTAKuntuk mengelakkan downtime sepenuhnya.

Terdapat penambahbaikan lain pada infrastruktur pengindeksan dalam PostgreSQL 12. Satu lagi perkara di mana terdapat sihir - log tulis ke hadapan, aka WAL (log tulis ke hadapan). Log tulis ke hadapan merekodkan setiap transaksi dalam PostgreSQL sekiranya berlaku kegagalan dan replikasi. Aplikasi menggunakannya untuk mengarkib dan pemulihan titik dalam masa. Sudah tentu, log tulis ke hadapan ditulis pada cakera, yang boleh memberi kesan kepada prestasi.

PostgreSQL 12 telah mengurangkan overhed rekod WAL yang dicipta oleh indeks GiST, GIN dan SP-GIST semasa pembinaan indeks. Ini memberikan beberapa faedah ketara: Rekod WAL menggunakan lebih sedikit ruang cakera dan data dimainkan semula dengan lebih pantas, seperti semasa pemulihan bencana atau pemulihan titik dalam masa. Jika anda menggunakan indeks sedemikian dalam aplikasi anda (contohnya, aplikasi geospatial berasaskan PostGIS banyak menggunakan indeks GiST), ini adalah satu lagi ciri yang akan meningkatkan pengalaman dengan ketara tanpa sebarang usaha daripada pihak anda.

Pembahagian - lebih besar, lebih baik, lebih cepat

PostgreSQL 10 diperkenalkan pembahagian deklaratif. Dalam PostgreSQL 11 ia telah menjadi lebih mudah untuk digunakan. Dalam PostgreSQL 12 anda boleh menukar skala bahagian.

Dalam PostgreSQL 12, prestasi sistem pembahagian telah menjadi lebih baik dengan ketara, terutamanya jika terdapat beribu-ribu partition dalam jadual. Sebagai contoh, jika pertanyaan hanya mempengaruhi beberapa partition dalam jadual dengan beribu-ribu daripadanya, ia akan dilaksanakan dengan lebih pantas. Prestasi bukan sahaja dipertingkatkan untuk jenis pertanyaan ini. Anda juga akan melihat betapa cepatnya operasi INSERT pada jadual dengan berbilang partition.

Merekod data menggunakan SALINAN - dengan cara ini, ini adalah cara yang hebat muat turun data pukal dan inilah contohnya menerima JSON — jadual pembahagian dalam PostgreSQL 12 juga telah menjadi lebih cekap. Dengan COPY semuanya sudah pantas, tetapi dalam PostgreSQL 12 ia benar-benar terbang.

Terima kasih kepada kelebihan ini, PostgreSQL membolehkan anda menyimpan set data yang lebih besar dan menjadikannya lebih mudah untuk mendapatkan semula. Dan tiada usaha di pihak anda. Jika aplikasi mempunyai banyak partition, seperti merakam data siri masa, peningkatan mudah akan meningkatkan prestasinya dengan ketara.

Walaupun ini bukan penambahbaikan "naik taraf dan nikmati", PostgreSQL 12 membenarkan anda mencipta kunci asing yang merujuk kepada jadual pembahagian, menjadikan pembahagian senang digunakan.

DENGAN pertanyaan menjadi lebih baik

Apabila tampalan telah digunakan untuk ungkapan jadual biasa terbina dalam (aka CTE, aka WITH pertanyaan), saya tidak sabar untuk menulis artikel tentang betapa gembiranya pembangun aplikasi dengan PostgreSQL. Ini adalah salah satu ciri yang akan mempercepatkan aplikasi. Melainkan, sudah tentu, anda menggunakan CTE.

Saya sering mendapati bahawa pemula SQL suka menggunakan CTE; jika anda menulisnya dengan cara tertentu, ia benar-benar terasa seperti anda menulis program yang penting. Secara peribadi, saya suka menulis semula pertanyaan ini untuk mengetahuinya tanpa CTE dan meningkatkan produktiviti. Sekarang semuanya berbeza.

PostgreSQL 12 membolehkan anda menyelaraskan jenis CTE tertentu tanpa kesan sampingan (SELECT), yang digunakan sekali sahaja menjelang akhir permintaan. Jika saya menjejaki pertanyaan CTE yang saya tulis semula, kebanyakannya akan termasuk dalam kategori ini. Ini membantu pembangun menulis kod yang jelas yang kini juga berjalan dengan cepat.

Selain itu, PostgreSQL 12 mengoptimumkan pelaksanaan SQL itu sendiri, tanpa anda perlu melakukan apa-apa. Dan walaupun saya mungkin tidak perlu mengoptimumkan pertanyaan sedemikian sekarang, sangat bagus bahawa PostgreSQL terus bekerja pada pengoptimuman pertanyaan.

Just-in-Time (JIT) - kini lalai

Pada sistem PostgreSQL 12 dengan sokongan LLVM Penyusunan JIT didayakan secara lalai. Pertama sekali, anda mendapat sokongan JIT untuk beberapa operasi dalaman, dan kedua, pertanyaan dengan ungkapan (contoh paling mudah ialah x + y) dalam senarai pilihan (yang anda ada selepas SELECT), agregat, ungkapan dengan klausa WHERE dan lain-lain boleh menggunakan JIT untuk meningkatkan prestasi.

Memandangkan JIT didayakan secara lalai dalam PostgreSQL 12, prestasi akan bertambah baik dengan sendirinya, tetapi saya mengesyorkan menguji aplikasi dalam PostgreSQL 11, yang memperkenalkan JIT, untuk mengukur prestasi pertanyaan dan melihat jika anda perlu menala apa-apa.

Bagaimana pula dengan ciri baharu yang lain dalam PostgreSQL 12?

PostgreSQL 12 mempunyai satu tan ciri baharu yang hebat, daripada keupayaan untuk memeriksa data JSON menggunakan ungkapan laluan SQL/JSON standard kepada pengesahan berbilang faktor dengan parameter clientcert=verify-full, membuat lajur dan banyak lagi. Cukup untuk jawatan berasingan.

Seperti PostgreSQL 10, PostgreSQL 12 akan meningkatkan prestasi keseluruhan serta-merta selepas naik taraf. Anda, sudah tentu, boleh mempunyai laluan anda sendiri - menguji aplikasi dalam keadaan yang sama pada sistem pengeluaran sebelum mendayakan penambahbaikan, seperti yang saya lakukan dengan PostgreSQL 10. Walaupun PostgreSQL 12 sudah lebih stabil daripada yang saya jangkakan, jangan malas dalam menguji aplikasi dengan teliti, sebelum mengeluarkannya ke dalam pengeluaran.

Sumber: www.habr.com