A jó eloszlású index kulcsértékek előnyei


Két oka is van annak, hogy miért jó egy 'szétszórt' index:



1./ Az egymást követő insertek az indexpage-en egy lapra kerülnek így konkurens insertek esetén
indexpage foglalási problémák jelentkezhetnek.

Vagyis, ha konkurens felhasználók szúrnak be szekvenciában kiosztott kulcsú rekordokat,
akkor a konkurens felhasználók rekordjai lehet hogy más-más adatlapra kerülnek,
de nagy a valószínűsége van annak, hogy a kulcsértékek mégis azonos indexlapra kerülnek.
Mivel az adatbázis motornak nem csak az adatlapok lockolásával kell foglalkoznia, hanem indexlap
foglalásokkal is így ez kellemetlen foglaltsági helyzetekhez vezethet, vagyis a későbbi felhasználó
insertje várakozik, amíg a korábbi felhasználó nem zárja le a tranzakciót, még akkor is ha más-más datapage-ra került az új tétel, vagyis egymás zavarása nélkül dolgozhatnának.



2./ A Btree szerkezet már csak olyan, hogy hatékonyabb az indexlapok kitöltése
(egy lapra kerülő kulcsok száma vagyis a lap %-os kihasználtsága),
ha az egymást követő beszúrások 'szórt' kulcsértékekkel történnek.
A hatékonyság növekedés miatt kevesebb indexlap (és kevesebb indexszint) kell,
így gyorsabb az indexek beszúrása.

Ha beszúráskor az újabb kulcs értékek monoton növekszenek vagy csökkennek, akkor az indexet megvalósító (leggyakrabban btree) fa mindig kiegyensúlyozatlan lesz. Vagyis az ágak féloldalasra húzzák. Ezen persze némileg javít a továbbfejlesztett btree+ algoritmus, amely igyekszik kiegyensúlyozottan tartani a fát, de azért csodát nem tud művelni;)  
Az insertek szerencsés esetben egy indexlapra írást generálnak, de ha a fa egyensúlya felborult, és a „túlsúlyos” oldalra kell ismételten beszúrni, akkor ez lényegesen több lapra írást ill. idő előtti (felesleges) lappal bővítést eredményez. A felborult fa esetén azért is lesz lassú a rendszer, mert az indexek szerinti előkereséskor (a fa bejárása), több szintet, ergó több indexlapot kell végigolvasni, hiszen az érték keresése az egyre több szintet tartalmazó piramison lefelé lépkedve történik.

Van egy frappáns megoldás, amit én is használok.

Én mindíg integer kulcsot adok PK-nak.
Ezt egy szekvencia osztja ki, tehát konkurens inserttel vagy tömeges inserttel erősen terhelt táblákon nem az ideális,
de az integer előnyeit azért jó lenne megtartani, valamint szeretem azt is,
hogy azonnal látható a kulcsok kiadási sorrendje (ugye a szekvencia miatt szigorúan növekvő)
A kiosztott integer kulcsot kell megkeverni és az összezagyvált értéket használni kulcsként.

Nekem a legszimpatikusabb az a módszer, hogy az integer értéket char*-ra alakítom,
a karaktereket megforgatom majd visszaalakítom integerre. Ezt használom.
Pl. 123 -> "123" -> "321" -> 321



© eMeL Bt. 2006.02.24