Sebuah gem Ruby baharu yang dipanggil pg_hash_func menjanjikan untuk mempercepatkan pertanyaan hash partition PostgreSQL sehingga 20 kali ganda, tetapi komuniti pembangun mempersoalkan sama ada dakwaan prestasi tersebut benar-benar berlaku dalam senario dunia sebenar. Gem ini bertujuan untuk memintas overhed carian katalog PostgreSQL dengan mengira lokasi partition secara terus dalam kod aplikasi.
Kekurangan Bukti Prestasi Dunia Sebenar
Kebimbangan terbesar yang dibangkitkan oleh pembangun tertumpu kepada kekurangan penanda aras prestasi pertanyaan sebenar. Walaupun pencipta gem mendakwa peningkatan kelajuan yang ketara, penanda aras hanya mengukur masa pengiraan hash, bukan pelaksanaan pertanyaan lengkap. Pengkritik menunjukkan bahawa pendekatan ini gagal mengambil kira apa yang berlaku semasa operasi pangkalan data sebenar, di mana carian katalog hanya mewakili satu bahagian daripada keseluruhan proses pertanyaan.
Komuniti amat ragu-ragu kerana perbandingan prestasi hanya menunjukkan pengiraan hash Ruby berbanding pengiraan hash SQL, tanpa menunjukkan peningkatan prestasi pertanyaan hujung ke hujung apabila membuat pertanyaan partition tertentu berbanding membiarkan PostgreSQL mengendalikan pemilihan partition secara automatik.
Dakwaan Prestasi vs Realiti
- Peningkatan yang didakwa: 20-40x lebih pantas dalam pengiraan hash
- Skop penanda aras: Hanya masa pengiraan hash, bukan pelaksanaan pertanyaan penuh
- Data yang hilang: Perbandingan prestasi pertanyaan hujung ke hujung
- Kebimbangan komuniti: Tiada penanda aras pertanyaan dunia sebenar disediakan
Risiko Penyelenggaraan dan Keserasian
Beberapa pembangun telah menyerlahkan mimpi ngeri penyelenggaraan yang berpotensi dalam melaksanakan semula fungsi hash dalaman PostgreSQL . Pendekatan ini memerlukan sinkronisasi dengan butiran pelaksanaan dalaman PostgreSQL , yang boleh berubah antara versi. Ini mewujudkan gandingan rapat antara kod aplikasi dan versi PostgreSQL tertentu yang dianggap membimbangkan oleh ramai pihak.
ini kelihatan seperti mimpi ngeri penyelenggaraan pada masa hadapan, tetapi saya mungkin salah. Jika anda terperangkap pada versi pg tertentu untuk seketika, mungkin ia berbaloi.
Gem ini pada masa ini hanya menyokong pembahagian berasaskan integer (bigint, integer, smallint) dan tidak menyokong teks, UUID, atau jenis data biasa lain, yang selanjutnya mengehadkan kebolehgunaan praktikalnya.
Had Semasa Gem pg_hash_func
- Jenis yang disokong: bigint (int8), integer (int4), smallint (int2)
- Jenis yang tidak disokong: text/string, UUID, jenis data lain
- Platform: Ruby sahaja
- Kebergantungan versi PostgreSQL: Memerlukan penyegerakan dengan perubahan pelaksanaan dalaman
Strategi Pengoptimuman Yang Dipersoalkan
Ahli komuniti juga mempersoalkan premis asas pengoptimuman tersebut. Hash partitioning biasanya dipilih secara khusus apabila anda tidak mengetahui corak data terlebih dahulu, namun pendekatan ini memerlukan pengetahuan terperinci tentang kunci dan struktur partition. Ini seolah-olah bercanggah dengan salah satu kelebihan utama hash partitioning - mengedarkan data tanpa memerlukan analisis corak awal.
Penyelesaian yang dicadangkan untuk menggunakan pertanyaan SQL statik dengan fungsi hash terkod keras sebagai ganti rutin katalog PostgreSQL telah menyebabkan beberapa pembangun keliru, kerana ia memperkenalkan kerumitan tambahan sambil berpotensi mengorbankan pengoptimuman terbina dalam PostgreSQL .
Kesimpulan
Walaupun konsep mengoptimumkan pertanyaan partition PostgreSQL adalah berharga, respons komuniti menunjukkan bahawa penanda aras yang lebih komprehensif dan ujian dunia sebenar diperlukan untuk mengesahkan faedah yang didakwa. Pendekatan ini mungkin mempunyai merit untuk senario throughput tinggi tertentu dengan versi PostgreSQL yang stabil, tetapi overhed penyelenggaraan dan skop terhad menimbulkan persoalan tentang kebolehgunaan yang lebih luas. Pembangun nampaknya lebih berminat untuk melihat perbandingan prestasi pertanyaan sebenar daripada penanda aras pengiraan hash terpencil untuk menilai teknik pengoptimuman ini dengan betul.
Rujukan: Bypass PostgreSQL catalog overhead with direct partition hash calculations