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?