nagy méretű SQL kezelés

**ARTidas** · 2009-11-24, 12:01

@Geri

A legelején rossz adatokkal számoltam, de ez szerintem már jó számítás.

Szóval összegezve az eddigieket, ha nagyon sok szövegem van akkor azt az adatbázisba kell nyomnom, és nem tehetek semmit se a mérete ellen?

Köszönöm az eddigi hozzászólásokat,

Respect, Cheers,

**AlBrown** · 2009-11-24, 12:06

Fontos a szövegek későbbi felhasználási módjának meghatározása. Kell-e keresni bennük vagy nem. Ha igen realtime vegy nem. Van olyan db-m ahol simán a texteket gzippelve tolom db be, mert miért ne?

HA ELÉRI a 4 gigát , azután mit lehet csinálni ezzel az adathalmazzal, mert semmilyen sql motorról nem tudok, mely 4 giga fölött kezel adatbázist. Ezt szeretném előre látni és tervezgetni.

táblákat nagyon ügyesen lehet particionálni, néha jobb is.

Hangsúlyozom, a felhasználási módnak kell meghatároznia a DB szerkezetet, és a tárolási módot.

**ARTidas** · 2009-11-24, 12:10

Mivel egy elég nagy méretű hírtároló lesz, és a hírek között jó dolog a keresgélés, ezért kifejezettem kereshető formátumúnak kell lennie. Itt ugyanúgy közbe szól az, hogy milyen gyorsan lehet keresni több 100 megás .sql ekben...

**AlBrown** · 2009-11-24, 12:52

szerintem ne félj a nagy (több gigás) adatbázisoktól se. Inkább nagy legyen, mint rossz szerkezetű. 100 megás táblákról beszélsz, ami azért nem vészes ám. Persze ha egy gigás adatbázisban keresel mondjuk like "%VALAMI%" kifejezéssel, akkor bajok lesznek. A full table scan nagy méretnél okozhat problémát. Az indexek, a memóriaméret, bufferméret, irás, olvasás lockok amikk inkább szűk keresztmettszetek.

Van nekem 5 gigás, 2 gigás, sok párszáz megás adatbázisom, semmi baj velük.

A redundancia pedig nem feltétlenül baj. Sőt. Sok esetben olyan szinten egyszerűsitik, gyorsítják a lekérdezéseket, hogy többet hoz, mint visz.

Pl. ha a keresés a fontos, lehet csinálni olyat, hogy elkészítesz előre egy mezőt, amiben eleve úgy pakolod az adatokat, amire a kereséshez szükséged van. PL, minden szó csak egyszer szerepel benne, kidobálod a stopwordoket belőle stb, és a keresést csak ezen futtatod.

De nagy DB nél javaslom inkább az InnoDb-t MyIsam helyett, kereséshez mondjuk a sphinx-et http://www.sphinxsearch.com/

Na szóval azt igyekeztem összehadoválni itt, hogy a nem a méret a lényeg

**gzoli** · 2009-11-24, 19:18

Tapasztalatom szerint 80-100MB-os táblánál az InnoDb update esetén lassabb mint MyIsam. Furcsa volt látni, de ez volt, és a slow-query is kihozta, pedig minden fórum a sebességét írja ennek a motornak. A gyakorlat pedig MyIsam-nak kedvezett... amint átállítottam a típusát, nem volt semmi gond vele.

**AlBrown** · 2009-11-24, 19:51

az InnoDb update esetén lassabb mint MyIsam

ez tény. Az innodb lassabb. Viszont valahol már említettem is. Hogy a myisam table level lockot, míg az innodb row level lockot alkalmaz, így a nyers sebesség általában csak akkor érvénysül, ha a nincs konkurens olvasás, és írás. Ha van a myisam-mal eléggé rá lehet pacsálni

Ezért is mondom mindig, hogy a feladat részletes ismeretében érdemes nekiállni a tervezésnek

és az általam sokat emlegetett számomra bibliaként kezelt oldal: http://www.mysqlperformanceblog.com/

**sZeKo** · 2009-11-25, 00:14

Akkor optimalizálj másképpen, mint egy tömörítő algoritmus.

Tegyük fel, hogy szövegeket tárolsz a táblákban. Írj egy scriptet ami kikeresi neked - offline, gyors gépen - a leggyakrabban használt 1000 szót. Ezeket helyett vezess be egy alliast.

Például:

Jelenlegi tartalom tábla:
1. Az alma piros, de nagyon finom gyümölcs.
2. A körte egész jó gyümölcs, de az alma nem.
3. Minden gyümölcs egyforma, kivéve az alma és a körte.

Allias tábla:
1. alma | #aa
2. körte | #bb
3. gyümölcs | #cc

Új tartalom tábla:
1. Az #aa piros, de nagyon finom #cc.
2. A #bb egész jó #cc, de az #aa nem.
3. Minden #cc egyforma kivéve az #aa és a #bb.

Az #aa, #bb, #cc helyett olyat is használhatsz, hogy #ALLIAS_ID#, lényeg hogy egyedi legyen a kódban és jól elkülöníthető a szövegtől, meg persze olyan kinézetű amit biztos nem ír senki, nem kreál a rendszer stb, attól függően honnan jönnek az adatok.

Persze mielőtt ennek vadul neki esnél teszteld sokféle módon a lehetőségeket és ennek a lehetséges megoldásnak is a kivitelezését. Mert ez a méretet látványosan redukálni fogja, de az adatbázis műveleteket viszont lassítani.

sZeKo

**edem** · 2009-11-25, 08:40

ARTidas eredeti hozzászólása

VISZONT!!! A MyISAM letároló 32 bites méretű pointerrel rendelkezik, mely csakis 4 gigányi adat indexelésére elegendő. Ennek az átállítása erősen nem kívánt eredményeket eredményezhet...

Innodb-t nem tudsz használni myisam helyett?

**edem** · 2009-11-25, 08:45

Azt hiszem témába vágó a kérdés. Épp egy adatbázist tervezek, ebben segítségemre van a MicroOlap Database Designer for Mysql nevű programocska. Arra gondoltam, hogy ha elkészülök a tervvel, akkor felteszek ide egy képet, hátha valaki tapasztaltabbnak lesz valamilyen hozzászólása, hogyan tudnám optimalizálni. Ez egy jutalékszámítási rendszerhez lesz, csak számok lesznek benne szinte, illetve a hozzájuk tartozó munkatársak. Ha már itt tartunk a DD for Mysql-t ajánlom mindenkinek, aki dolgozik adatbázisokkal, nekem NAGYON leegyszerűsíti a munkámat

Kód: