[BSD] I/O sebesseg merese

[Kovács János]

Szia!

Több dolgot is rossz szemszögből nézel. Az adatbázis kezelő szempontjából a diszkek rendszere a legritkább esetben mérvadó. Az, hogy mennyi a diszk elméleti átviteli teljesítménye, mennyi a cache mérete, az adatfile(ok) milyen clusterszervezésben kerülnek a lemezre, mind-mind olyan információ, melyel a legritkább esetben foglalkozik az eszköz. Ezek az adatok akkor mérvadóak, ha a másik leveledben említett grep "Mug" megoldást választod.

Az adatbázis kezelőd az adatokat valamilyen leíró halmaz alapján tartja karban. Egy lekérdezés mire az adathoz férne tucatnyi címfeloldás történik. Nem ismerem a pg-t, de gondolom a vacum szolgál arra, hogy az adatok és adatleírók minnél rendezettebb formába kerüljenek (leíró fa és adatfolyam újrarendezés). Amikor te adatot olvasol ki egy táblából, az éppúgy távol áll a file szekvenciális olvasásától, mint a diszkterület folyamatos olvasásától.

A file letárolás mellett ott van továbbá az a különbség, hogy az adatbázis kezelő nem szimpla fileokat tart karban. Amíg a grep a teljes fileod minden sorában annak minden attribútumában keres, addig te a motornak megmondod, hogy csak a name attrib érdekel. Ez azért egy alapvető és mérföldekkel távolabbi adatkezelés, mint a file, pont ezért az erőforrás igénye is nagyságrendekkel nagyobb.

Ráadásul problémáid során leírt leveleidben te nem is nagyon mondasz semmit, hogy megpróbálnád elősegíteni az adatbázis keresődet a kveri végrehajtásában. Itt pár dolog ami fontos:
- Ne használj select * from kveriket. Igy a parser és az első és második vonali értelmező és optimalizáló sem tud mit kezdeni a lekérdezéseddel. Sorold fel az attribútumokat, amikre szükséged van. Még akkor is jobban jársz, ha mindet felsorolod.
- A like '%Mud%' nem egy egyszerű kiválasztás, gyorsítani leginkább teljes szöveges indexel lehetséges. Ha nem csak statisztikához alkalmazod a lekérdezést max napi egy alkalommal, akkor mindenképp készíts ilyen indexet!
- Vigyél logikát a rendszerbe. A rendszert és az adatbázis együtt kell megtervezd, hogy az üzleti logika egyszerű átalakításával elkerülhető legyen a like '%Bla%' típusú lekérdezés. Nem mindig oldható meg (pl tartalom keresés funkciók támogatása), de legtöbb esetben igen!
- Legyen elég memóriád! Egy adatbázisnak, ahol egy tábla mérete 3G, elkell a RAM!!
- Tuningold az adatbázisod. A jól beállított buffer és cache értékek a grep-nél nagyságrendekkel gyorsabb eredményt produkálhat.


Ha ott tartasz, hogy az adatbázis motorod buffer, cache, index és egyéb gyorsaség növelő eszközeinek használati/találati aránya/hasznossága megközelíti a 100%-ot, akkor kell elkezdened a filesystem és a diszkek témakörét boncolgatnod. Egy jó filesystem, egy hatásos diszk, egy gyors raid szervezés és kivitelezés tovább tudja növelni a teljesítményt, de semmit sem tehet, ha az adatbázis kezelő nincs megfelelően beállítva.

KOko