Bejegyzés

Megfürödtünk a Firebird tóban – megúsztuk szárazon

Szeretek adatbázisokról vitatkozni. Szeretek olyanokkal vitatkozni, akik olvasták az “Adatbázis-rendszerek tervezése” könyvet. Valahol a szakma ott kezdődik.

 

Az Ügyfél

Egyik nagy ügyfelünk (a kép nem véletlenül került ide) részére fejlesztett szoftver nagy mennyiségű adatot kezel, precízen, pontosan. 1.45 millió vevőből tud(t)unk gyorsan válogatni. Valami azonban most egy kicsit belassult. Bármilyen terhelés mellett 4.5 mp volt a válaszidő. És egy rendes programozó érzi, ha valami nincs rendjén. A vevőtörzset átszippantottuk és egy teljesen szűz operációs rendszeren is 4.5 mp-re jött ki a lekérdezés. Minden index rendben volt. És a problémát pont ez okozta….

horstfuchs_firebird

 

Az index néha probléma?

Igen. Az index tartalmazott 9.000 valós, nem NULL értéket, ami 1.45 millió vevőre vonatkozóan pont megfelelő eloszlást jelentett (index stat), emiatt a lekérdezésekben a rendszer használta. De nem kellett volna, mert az eredmény csak ennek az indexnek a használata lett. A 9.000 vevő kiszűrése után 1.44 millió vevőn FULL-SCAN-t (!!!) végzett. Fogta a “rekordokat” és merevlemez hozzáférést is indukált. Nem keveset. Van megoldás?

 

Megoldás?

Az indexet eltávolítva a probléma megoldódott. Volna. De ez nem egy index volt, hanem egy foreign key (idegen kulcs) által létrehozott belső index. Nem törölhető. Az index használata PLAN kézzel való megadásával befolyásolható. De nem szeretnék az adatbázis szerver helyett gondolkodni (pedig talán menne, lásd: Adatbázis-rendszerek tervezése). Akkor valahogy el kellene érni, hogy az indexet a rendszer NE használja. Eltelt pár óra, majd még pár… és megszületett a megoldás. Nem írom le a megoldást, de büszke vagyok rá. 

A megoldás pedig beépítésre került az SQLManager-be, minden lekérdezés bizonyos mezőket kihagy az indexből. Automatikusan. A végeredmény egy állandóan 65-70 ms (!!!) alatt lefutó lekérdezés és egy nagyon alacsony terhelés. Örülünk Vincent?

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!

 

A Vista adatbázis is szép csendben készülget

Az adatbázis megoldásokat szállító cégek  régen beleülhettek a kényelmes fotelükbe, nem nagyon volt újdonság. MySQL ha ingyenes kell, ha kis tranzakció kell, akkor InnoDB. Ha Delphi/MicroSoft-os vagy, akkor MsSQL/MSDE. Ha bankod van, akkor úgyis van Oracle. Ha nagyon Delphi-s vagy, akkor Interbase/Firebird.

(Symbol Ügyvitel is FB 2.1 alapokon fut, ennek architektúrális okai vannak, a Delphi-s indíttatás elenyésző – a szerk.)

És közben magát nagyon jól pozicionálva megjelent a VistaDB4. http://www.vistadb.net/vistadb

Talán régebben választották neki a nevet, mint ahogy a Microsoft operációs rendszere megszületett.

 

Mit is tud általában?

Beépített. Ez azt jelenti, hogy nem kell szervert telepíteni, minden művelet, megoldás az applikációban kap helyet.

T-SQL-t érti. Az MsSQL tárolt eljárás nyelvét egy az egyben futattni képes, sőt a CLR-t is fel tudja használni.

MSSQL funkciók. Számos olyan funkció beépítésre került, amely a “nagy” MsSQL-nek része, de a CE (compact edition) változat nem tatalmazza: triggerek, tárolt eljárások. Így alternatívája lehet az MSDE/MsSQL-CE-nek.

 

Mi egyebet kapunk?

  • Visual Studio integráció
  • Adatmodellező eszköz
  • .NET framework teljes integráció

 Mibe kerül ez nekünk?

  • Természetesen ára van, mert semmi nincs ingyen.
  • $59 az alapértelmezett, Light csomag, ebben sajnos kevés a funkcionalitás.
  • $359 az ideális választás /fejlesztő.
  • A runtime komponensek felhasználókhoz való eljuttatása természetesen ingyenes.

Jó választás, jó a verseny, egy kiforrott alternatíva lehetősége a korábbiak mellett, amelyek már kinövik saját méretüket. Lásd MsSQL 200MB-os telepítő!

VistaDB

VistaDB