Bejegyzés

Index használata kötelező – nem csak sávváltáskor

Szabadságom derekán benéztem az irodába és azzal fogadtak, hogy a v1.94-es verzió lassú. De mi lehet a probléma, hány ügyfélnél jelentkezett, komoly-e a baj? Tanulságos volt az a 30 perc a fejlesztőknek.

Mik az indexek?

Az adatbázisban tárolt információk nagyon sokan vannak, hasonlóan egy könyvtárhoz. Az adatok/könyvek közti keresésben segítenek az indexek. Például Molnár Ferenc Pál utcai fiúk könyve egy rendes könyvtárban kétszer van indexelve. Az M betűnél, azon belül Molnár Ferencnél is megtalálható, emellett a P betűnél, Pál utcai fiúk jelölés alatt is megtalálható, közvetlenül a “Pakura készítése” és a “Pálinkafőzés” című könyvek között. (Attól most tekintsünk el, hogy a regény címe A betűvel kezdődik, ez annyira általános, hogy az indexekből ki is szokták hagyni).

Indexelni kötelező!

Minden adatbázis kell, hogy tartalmazzon indexeket, amelyek automatikusan jönnek létre vagy a programozó készíti őket, hogy az adatelérés gyorsabb legyen. Például az ABC Kft. tárgy havi számláinak lekérdezésében egy automatikus index (idegen kulcs a vevőre) és egy kézi index (dátum) segít. Indexek nélkül az összes számlát végig kellene nézni, hogy megtaláljuk a megfelelőket (full scan, nagyon rossz stratégia).

Rakjunk mindenre indexet!

Az indexek az adatbázisban tárolt adatok másolatai (minden adat kétszer szerepel), emiatt mindent indexelni nem célszerű. És ez a problémánkat nem is oldja meg! Az indexeket a rendszer csak akkor használja, ha értelme van (lásd lentebb). Intelligensek ezek a rendszerek!

Akkor mi volt a probléma?

Megszüntettünk egy egyedi (unique) indexet, de létrehoztuk helyette a négy (!!!) mezőjére vonatkozó indexeket. Gondoltuk, ezzel készen is vagyunk… De a régi index helyett létrehozott négy új nem ugyanazt a hatást váltotta ki. A négy indexből a rendszer csak kettőt használt (query plan), a többinek annyira kicsi volt az értékkészlete, hogy az adatbázis kezelő figyelem kívül hagyta őket.

Értékkészlet?

Egy indexszel gyorsított adatmező(k) előfordulási értékei lehetnek nagyon kicsik. A számlák tábla dátum mezője az első héten még csak 5 különböző értéket tartalmaz (ha szombat-vasárnap is állítunk ki számlát, akkor 7-et). Az adatbázis kezelő az ilyen kis variációjú indexekre azt mondja, hogy nincs értelme használni őket. Ha például kiállítunk 3 nap alatt 9000 számlát (ez persze csak egy példa), akkor minden dátumhoz 3000 számla fog tartozni. Az index nem sokat segít nekünk abban, hogy melyik számlák készültek ma, hiszen 3000 értéket fog visszaadni, az összes számla egy harmadát.

Mi lehet a megoldás?

A v1.94-es verzió hibáját azonnal javítottuk, de családommal nyaralás és bevásárlás közben is azon gondolkodtam, hogy akkor milyen indexeket kell létrehozni “úgy általában”. A programozás inkább hasonlít az orvoslásra, mint a marketingre, próbálkozni nem lehet, de mi most mégis ki fogunk választani 2-3 speciálisan előkészített adatbázist, hogy teszteket hajtsunk végre rajta.

Minden bizonnyal a megoldás az lesz, hogy a leggyakoribb lekérdezések (a Symbol Ügyvitelbe beépített  lekérdezésfordító ebben segíteni fog nekünk) esetén létrehozunk olyan “furcsa” indexeket, amelyek nem logikusak, de nagy értékkészletük miatt az adatbázis kezelő mégis használni fogja őket.

 

 

Eközben nyugaton…

Tengerentúli példákkal jönni sikkes, nem is szeretem, de mégis hadd álljon itt egy amerikai példa. Ott jellemzőbbek a saját fejlesztőcsapattal rendelkező cégek (nálunk a bankoknak/pénzintézeteknek sincs ilyen, egy kivételt ismerek a Concorde Értékpapír Zrt-t, amelynek van egy saját, profi csapata), ahol a DBA (adatbázis adminisztrátor) feladata, hogy a lassú lekérdezéseket (1mp helyett 90-120mp) optimalizálja és indexekkel támogassa. Nekünk, dobozos szoftver szállítóknak ezt helyi rendszergazda nélkül kell tudnunk megoldani. Eddig sikerrel!