Tabel B-Tree vs Hash


103

Di MySQL, tipe indeks adalah b-tree, dan akses elemen di b-tree dalam waktu logaritmik diamortisasi O(log(n)).

Di sisi lain, mengakses elemen dalam tabel hash ada di O(1).

Mengapa tabel hash tidak digunakan sebagai pengganti b-tree untuk mengakses data di dalam database?


9
Tabel hash untuk tidak mendukung kueri rentang, dan tidak dapat tumbuh atau menyusut dengan lancar selama operasi.
hmakholm meninggalkan Monica

3
@HenningMakholm Mengapa tidak hash untuk kolom yang tidak membutuhkan query range?
Pacerier

Jawaban:


116

Anda hanya dapat mengakses elemen dengan kunci utamanya di hashtable. Ini lebih cepat daripada dengan algoritma pohon ( O(1)bukanlog(n) ), tetapi Anda tidak dapat memilih rentang ( semua di antara xdany ). Algoritme pohon mendukung ini di mana Log(n)indeks hash dapat menghasilkan pemindaian tabel penuh O(n). Juga overhead konstan indeks hash biasanya lebih besar ( yang bukan merupakan faktor dalam notasi teta, tetapi masih ada ). Juga algoritma pohon biasanya lebih mudah untuk dipelihara, dikembangkan dengan data, skala, dll.

Indeks hash bekerja dengan ukuran hash yang telah ditentukan sebelumnya, jadi Anda akan mendapatkan beberapa "keranjang" tempat objek disimpan. Objek ini diulangi lagi untuk benar-benar menemukan yang benar di dalam partisi ini.

Jadi, jika Anda memiliki ukuran kecil, Anda memiliki banyak overhead untuk elemen kecil, ukuran besar menghasilkan pemindaian lebih lanjut.

Algoritme tabel hash saat ini biasanya menskalakan, tetapi penskalaan bisa jadi tidak efisien.

Memang ada algoritme hashing yang dapat diskalakan. Jangan tanya saya bagaimana cara kerjanya - ini juga merupakan misteri bagi saya. AFAIK mereka berevolusi dari replikasi terukur di mana hashing ulang tidak mudah.

Yang disebut RUSH - R eplication U nder S calable H ashing, dan algoritma yang demikian disebut algoritma RUSH.

Namun mungkin ada titik di mana indeks Anda melebihi ukuran yang dapat ditoleransi dibandingkan dengan ukuran hash Anda dan seluruh indeks Anda perlu dibuat ulang. Biasanya ini bukan masalah, tetapi untuk database yang sangat-sangat-sangat-sangat besar, ini bisa memakan waktu berhari-hari.

Pengorbanan untuk algoritme pohon kecil dan cocok untuk hampir semua kasus penggunaan dan karenanya menjadi default.

Namun jika Anda memiliki kasus penggunaan yang sangat tepat dan Anda tahu persis apa dan hanya apa yang akan dibutuhkan, Anda dapat memanfaatkan indeks hashing.


Bisakah Anda menjelaskan lebih lanjut tentang pembangunan kembali indeks? Apakah ini berarti bahwa selama x hari ketika indeks dibangun kembali, tabel tersebut sama sekali tidak tersedia untuk digunakan selama periode itu?
Pacerier

itu tergantung pada sistem database yang digunakan. pertanyaannya hanya mencakup aspek teoretis. saya tidak terlalu tahu tentang detail implementasi sistem database umum. tetapi biasanya tidak demikian karena indeks kedua dapat dibuat saat indeks pertama masih digunakan
The Surrican

"Anda hanya dapat mengakses elemen dengan kunci utamanya" - maksud Anda dengan nilai kolom yang memiliki hak indeks, apakah itu kunci utama atau jenis indeks lainnya?
Mark Fisher

90

Sebenarnya, MySQL tampaknya menggunakan kedua jenis indeks tersebut, baik tabel hash maupun b-tree sesuai dengan tautan berikut .

Perbedaan antara menggunakan b-tree dan tabel hash adalah tabel pertama memungkinkan Anda menggunakan perbandingan kolom dalam ekspresi yang menggunakan operator =,>,> =, <, <=, atau BETWEEN, sedangkan tabel hash hanya digunakan untuk perbandingan kesetaraan yang menggunakan operator = atau <=>.


9
Itu tidak adil. Jawaban terbaik memiliki skor terendah.
Андрей Беньковский

6
Inilah yang saya cari. Saya lebih peduli tentang bagaimana hal itu memengaruhi kueri saya daripada analisis teknis.
Ben Dehghan

Ya! Jawaban ini paling membantu saya.
Ron Ross

terima kasih banyak, sudah lama tetapi jawaban ini banyak membantu saya juga.
Reham Fahmy

14

Kompleksitas waktu hashtable konstan hanya untuk hashtable berukuran cukup (perlu ada cukup bucket untuk menyimpan data). Ukuran tabel database tidak diketahui sebelumnya sehingga tabel harus di-rehash sesekali untuk mendapatkan kinerja yang optimal dari hashtable. Pengulangan juga mahal.


2
Apakah reshashing dapat dilakukan saat db online? Atau apakah kita harus mengunci meja untuk mengulang semuanya?
Pacerier

1
Pacerier, MySQL tidak mendukung indeks hash. Secara teoritis dimungkinkan untuk mengulang indeks saat database masih online (tetap menggunakan indeks lama, buat indeks baru, alihkan ke yang baru setelah selesai) tetapi saya tidak tahu apa yang akan dilakukan MySQL jika diterapkan indikasi hash.
Emil Vikström

3
MySQL mendukung indeks hash, bukan? : dev.mysql.com/doc/refman/5.5/en/index-btree-hash.html
Pacerier

Anda tampaknya benar. Itu berita baru bagi saya! Saya harus mencoba untuk mengikuti perkembangan :-) Maka Anda jauh lebih baik dalam menjawab pertanyaan Anda daripada saya, tapi seperti yang saya katakan: secara teori.
Emil Vikström

Btw, mengapa Anda mengatakan bahwa "btree dapat dengan mudah dipindahkan ke disk tetapi hashtable tidak bisa"? Tidak dapatkah hashtable disimpan dalam disk karena pencarian kunci sederhana sudah cukup?
Pacerier


0

Pilih DB / OS didasarkan pada hashing dan bekerja dengan baik. Dengan lebih banyak memori akhir-akhir ini untuk mendukung tabel hash renggang yang efisien, dan hashing yang berlebihan untuk mendukung kueri rentang sederhana, menurut saya hashing mungkin belum ada tempatnya (beberapa lebih suka memiliki bentuk lain dari pencocokan kemiripan non-rentang, seperti wildcard dan regexps ). Kami juga merekomendasikan penyalinan untuk menjaga collision chain tetap berdekatan saat hierarki memori memiliki perbedaan kecepatan yang besar.

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.