MySQL'de, bir dizin türü bir b-ağacıdır ve bir b-ağacındaki bir öğeye erişim, logaritmik amortize edilmiş zamandır O(log(n)).
Öte yandan, bir karma tablodaki bir öğeye erişim içerdedir O(1).
Veritabanındaki verilere erişmek için neden b-ağacı yerine karma tablo kullanılmıyor?
Yanıtlar:
Öğelere yalnızca bir hashtable'daki birincil anahtarlarından erişebilirsiniz. Bu daha hızlı (bir ağaç algoritması ile daha O(1)yerinelog(n) ), ancak (aralıkları seçemezsiniz arasındaki her şeyi xvey ). Ağaç algoritmaları bunu desteklerken Log(n), karma dizinler tam bir tablo taramasıyla sonuçlanabilir O(n). Ayrıca, hash indekslerinin sabit ek yükü genellikle daha büyüktür ( bu, teta gösteriminde bir faktör değildir, ancak hala mevcuttur ). Ayrıca ağaç algoritmalarının bakımı genellikle daha kolaydır, verilerle büyür, ölçeklenir vb.
Karma dizinler önceden tanımlanmış karma boyutlarla çalışır, bu nedenle nesnelerin içinde depolandığı bazı "kümeler" ile sonuçlanırsınız. Bu nesneler, bu bölümün içinde gerçekten doğru olanı bulmak için tekrar döngüye alınır.
Dolayısıyla, küçük boyutlarınız varsa, küçük öğeler için çok fazla ek yükünüz varsa, büyük boyutlar daha fazla taramaya neden olur.
Günümüzün karma tablo algoritmaları genellikle ölçeklenir, ancak ölçeklendirme verimsiz olabilir.
Gerçekten ölçeklenebilir karma algoritmalar var. Bunun nasıl çalıştığını bana sorma - bu benim için de bir gizem. AFAIK, yeniden hashing işleminin kolay olmadığı ölçeklenebilir çoğaltmadan gelişti.
Onun adı Rush - R eplication u nder, S calable H külleme ve bu algoritmalar böylece Rush algoritmaları olarak adlandırılır.
Ancak, karma boyutlarınıza kıyasla dizininizin tolere edilebilir bir boyutu aştığı ve tüm dizininizin yeniden oluşturulması gereken bir nokta olabilir. Genellikle bu bir sorun değildir, ancak devasa-devasa veri tabanları için bu günler sürebilir.
Ağaç algoritmalarının değiş tokuşu küçüktür ve hemen hemen her kullanım durumu için uygundur ve bu nedenle varsayılandır.
Bununla birlikte, çok hassas bir kullanım durumunuz varsa ve tam olarak neye ve yalnızca neye ihtiyaç duyulacağını biliyorsanız, hash indekslerinden yararlanabilirsiniz.
Aslında, aşağıdaki bağlantıya göre MySQL her iki tür indeksi de ya bir hash tablosu ya da bir b-ağacı kullanıyor gibi görünüyor .
Bir b-ağacı ve bir karma tablosu kullanmak arasındaki fark, birincisinin =,>,> =, <, <= veya BETWEEN operatörlerini kullanan ifadelerde sütun karşılaştırmalarını kullanmanıza izin verirken, ikincisi yalnızca = veya <=> operatörlerini kullanan eşitlik karşılaştırmaları .
Hashtable'ların zaman karmaşıklığı, yalnızca yeterince boyutlandırılmış hashtable'lar için sabittir (verileri tutmak için yeterli bölüm olması gerekir). Bir veritabanı tablosunun boyutu önceden bilinmediğinden, bir hashtable'dan en iyi performansı elde etmek için tablonun ara sıra yeniden düzenlenmesi gerekir. Yeniden doldurma da pahalıdır.
Hashmap'lerin de ölçeklenmediğini düşünüyorum ve tüm haritanın yeniden düzenlenmesi gerektiğinde pahalı olabilir.
DB / OS Seç, karma işlemine dayanıyordu ve iyi çalıştı. Verimli seyrek karma tabloları desteklemek için bugünlerde daha fazla bellek ve mütevazı aralık sorgularını desteklemek için fazladan hashing ile, hashing'in yine de yerini alabileceğini söyleyebilirim (bazıları joker karakterler ve normal ifadeler gibi diğer aralık dışı benzerlik eşleştirme biçimlerine sahip olmayı tercih ederdi) ). Bellek hiyerarşileri büyük hız farklılıklarına sahip olduğunda, çarpışma zincirlerini bitişik tutmak için kopyalamayı da öneririz.