Bagaimana mungkin Indeks Hash tidak lebih cepat dari Btree untuk pencarian kesetaraan?


8

Untuk setiap versi Postgres yang mendukung pengindeksan hash , ada peringatan atau catatan bahwa indeks hash "mirip atau lebih lambat" atau "tidak lebih baik" dari indeks btree , setidaknya hingga versi 8.3. Dari dokumen:

Versi 7.2 :

Catatan: Karena utilitas indeks hash yang terbatas, indeks B-tree umumnya lebih disukai daripada indeks hash. Kami tidak memiliki bukti yang cukup bahwa indeks hash sebenarnya lebih cepat daripada B-tree bahkan untuk perbandingan =. Selain itu, indeks hash membutuhkan kunci yang lebih kasar; lihat Bagian 9.7.

Versi 7.3 (dan hingga 8.2) :

Catatan: Pengujian telah menunjukkan indeks hash PostgreSQL sama atau lebih lambat dari indeks B-tree, dan ukuran indeks serta waktu pengembangan untuk indeks hash jauh lebih buruk. Indeks Hash juga mengalami kinerja yang buruk di bawah konkurensi tinggi. Karena alasan ini, penggunaan indeks hash tidak disarankan.

Versi 8.3 :

Catatan: Pengujian menunjukkan indeks hash PostgreSQL berkinerja tidak lebih baik daripada indeks B-tree, dan ukuran indeks serta waktu pengembangan untuk indeks hash jauh lebih buruk. Selain itu, operasi indeks hash saat ini tidak dicatat dalam WAL, jadi indeks hash mungkin perlu dibangun kembali dengan REINDEX setelah terjadi kerusakan basis data. Untuk alasan ini, penggunaan indeks hash saat ini tidak disarankan.

Di utas versi 8.0 ini , mereka mengklaim bahwa tidak pernah menemukan kasus di mana indeks hash sebenarnya lebih cepat daripada btree.

Bahkan dalam versi 9.2, perolehan kinerja untuk apa pun selain menulis indeks yang sebenarnya hampir tidak ada menurut posting blog ini (14 Maret 2016):
Indeks Hash pada Postgres oleh André Barbosa.

Pertanyaan saya, bagaimana mungkin?

Menurut definisi, indeks Hash adalah O(1)operasi, di mana btree adalah O(log n)operasi. Jadi bagaimana mungkin O(1)pencarian lebih lambat daripada (atau bahkan mirip dengan) menemukan cabang yang benar, dan kemudian menemukan catatan yang benar?

Saya ingin tahu bagaimana dengan teori pengindeksan yang PERNAH memungkinkan!


Jawaban:


7

Indeks Btree berbasis disk benar-benar adalah O (log N), tetapi itu cukup banyak tidak relevan untuk array disk yang sesuai dengan tata surya ini. Karena caching, mereka sebagian besar O (1) dengan konstanta yang sangat besar ditambah O ((log N) -1) dengan konstanta kecil. Secara formal, itu sama dengan O (log N), karena konstanta tidak penting dalam notasi O besar. Tetapi mereka memang penting dalam kenyataan.

Banyak dari perlambatan dalam pencarian indeks hash berasal dari kebutuhan untuk melindungi terhadap korupsi atau kebuntuan yang disebabkan oleh hash-tabel mengubah ukuran bersamaan dengan pencarian. Sampai versi terbaru (setiap versi yang Anda sebutkan sudah ketinggalan zaman), kebutuhan ini menyebabkan konstanta yang lebih tinggi dan konkurensi yang agak buruk. Jauh lebih banyak jam kerja masuk ke optimalisasi BTree concurrency daripada hash concurrency.


Terima kasih. Saya sangat menyadari seberapa jauh tanggal kedaluwarsa mereka dari versi-versi itu, tetapi saya masih penasaran tentang bagaimana kinerja yang begitu jauh di belakang apa yang saya harapkan
Sampson Crowley

3

Pencarian Hash secara teoritis O(1)operasi ketika hash kunci memetakan langsung ke lokasi fisik dari catatan target. Cara kerjanya di Postgres, jika saya memahaminya dengan benar, sedikit lebih rumit: kunci hash memetakan ke ember yang berisi OID yang Anda cari. Sebuah ember berpotensi terdiri dari lebih dari satu halaman, yang perlu Anda pindai secara berurutan hingga Anda menemukan kunci (hash) khusus Anda. Inilah sebabnya mengapa ini tampak lebih lambat dari yang Anda harapkan.

Metode akses indeks hash File README dalam repo kode sumber memiliki semua detail.


jadi pada dasarnya indeks hash adalah jenis indeks percabangan sejauh psql yang bersangkutan
Sampson Crowley

yang sebenarnya jauh lebih masuk akal mengetahui mereka menggunakan ember untuk menyimpan kunci yang sebenarnya
Sampson Crowley

juga terima kasih atas tautannya ke readme. Saya tidak tahu yang ada di repo
Sampson Crowley

2
Halaman-halaman yang melimpah memang perlu dicari secara linear, dan dalam kasus-kasus buruk yang merosot, mungkin ada jumlah yang tidak terbatas. Tetapi pencarian di dalam halaman memiliki jumlah item terbatas yang dapat ada pada halaman sehingga mereka adalah O (1) per halaman overflow, dan mereka menggunakan pencarian biner sehingga konstanta tidak terlalu buruk juga. Itu benar-benar ketentuan untuk membuat operasi konkurensi aman yang merupakan hambatan.
jjanes

1
@AnoE - Anda akan terkejut ... Selalu ada trade-off antara kinerja dan [pemborosan] sumber daya; dalam beberapa kasus orang mungkin menyukai kinerja.
mustaccio
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.