Téma: Nagy latogatottsagu portal fejlesztese

Redundáns adat tárolás:
Fórumokban látványos például:
- topics tábla: topic neve, sorszáma, létrehozás dátuma
- posts tábla: postoló neve, topic száma, idő, post tartalma.

Ez lenne a 3-ik normál forma alak. ekkor ha ki kell iratnod, hogy mikor és ki irt utoljára a táblába akkor a topicok száma + 1 query kell hogy ezt meg tudd tenni. (összes topic listázása, utána minden topichoz egy select a post táblára.)

Tehát ha tudod, hogy van ilyen igény akkor az elején már igy kezded el tárolni az adatokat:
- topics tábla: topic neve, sorszáma, létrehozás dátuma, utolsó post dátuma, utolsó post irójának neve.
- posts tábla: postoló neve, topic száma, idő, post tartalma.

Igy 1 query -ből ki tudod iratni a szükséges adatokat.

Ezt értem redundáns adat tárolás alatt. Ez viszont már nem 3-ik normálforma, és csak kis jóindulattal nevezhető 2-ik formának.

Arra azért figyelj, hogy egy myisam táblába ne tolj pár milliónál több sort, mert nem szereti

memcache: a php modul mellé jár egy szerver is. Arra van, hogy mondjuk a nagynehezen kiszámitott hosszabb távon jó értékeket belementsd. Tisztán memória alapú, tehát tárolni csak olyan adatot aminek az elvesztése nem fáj (Cache). Ilyen adat lehet például az általános statisztika blokkod adatai. van 12000 felhasználó irtak 184200 postot, eltöltöttek a site-on 1234 évnyi időt, bla bla. Ezt tipikusan sokszor kiiratod, viszont jellemzően nem nagyon változik. Igy akár egy órára is berakhatod a cache-be.

a memcache ha jol ertelmeztem 2giga memoriat es minel tobb virtualis memoriat igenyel. az adatbazistervezesnel megfogadom a tanacsodat. de felmerult bennem egy kerdes: mennyivel lassabb egy tobb tablas lekerdezes egy egytablasnal, ha az egy queryn belul van?

ket dolog amirol kivancsi lennek meg a velemenyedre.
az elso:
a mysql_query chache hxxp://dev.mysql.com/doc/refman/5.0/en/query-cache.html.
a masodik:
hxxp://mysqldatabaseadministration.blogspot.com/2005/11/mysql-5-optimization-and-tuning-guide.html

es koszonom az eddigieket.

Arra azért figyelj, hogy egy myisam táblába ne tolj pár milliónál több sort, mert nem szereti

Ehhez annyi kiegészítést tennék, hogy akkor, ha sok az írási, illetve update művelet, mert MyIsam ilyenkor a teljes táblát lockolja. innoDB viszont row level lockingot alkalmaz így egy udate nem akaszt le mindent . Szóval, ha csak olvasol, akkor nem para a MyIsam.

Érdemes a statikus tartalmak (kép, video, css.... ) kipakolni egy lighthttpd -re, ne az apache szüttyügjön ezekkel.

kedvenc blogom, nagy portál tervezése előtt kötelező darab:
http://www.mysqlperformanceblog.com/
és ezis kötelező:
http://developer.yahoo.com/performance/rules.html

A query cache-el vigyázz! Az esetek nagy többségében nagyon jó szolgálatot tesz, de tipikus példa, amikor egyszerre nagyon sok látogató van a siteon és a sok lekérdezés megy egyedileg. Ami nem feltétlenül kesselhető. Szóval figyelni kell nagyon ilyen queryknél a SQL_NO_CACHE opciókra. Illetve ha sok az írási művelet akkor lassít. Szóval, jó hasznos, de az eredményt mérni és tesztelni kell.

TLoF eredeti hozzászólása

Redundáns adat tárolás:
Ez lenne a 3-ik normál forma alak. ekkor ha ki kell iratnod, hogy mikor és ki irt utoljára a táblába akkor a topicok száma + 1 query kell hogy ezt meg tudd tenni. (összes topic listázása, utána minden topichoz egy select a post táblára.)

nem akarok kotozkodni, de szerintem a cacheles mellett a legfontosabb a jol megirt sql-ek, es jol megvalasztott indexek hasznalata.

a fentebb irtakat 1 sqlbol is megirhatod, sima join, vagy subselectel. ha ezt valaki plusz queryvel szedi le az eleg nagy problema.

a redundans adattarolas sem mindig megoldas. valoban vannak olyan esetek, amikor erdemes hasznalni, de en egyaltalan nem ajanlom, hogy mindent osszevissza tarolgasson az ember.

en nagyon keves helyen hasznalok ilyet, es megis vannak olyan lekerdezeseim, amik tobbmillios rekordsetbol is lefutnak kevesebb mint 1 masodperc alatt. es nem sima sqlrol beszelek, hanem sokszoros joinokrol es subselectekrol.

peldanak mutatom ezt az oldalt

nagy terhelesnel is jol vizsgazik, es igaz, cachelve van minden, amit csak lehet. vannak olyan panelek, pl a top10, ami a statisztikabol all elo. na az pl egy durvan eroforras igenyes muvelet lenne, ha nem lenne megtamogatva vagy 8 indexel, es optimalizalt lekerdezessel. igy lefut 1 sec alatt.

mza8202: Az egy dolog hogy egy query lefut 1 sec alatt. A másik dolog, hogy közben mekkora terhelést ró az adatbázist kiszolgáló szerverre.

A jól felépitett redundás adattárolás rengeteget tud segiteni, ha a fejlesztés elejétől, célirányosan tudod alkalmazni / tervezni.

A subselect / join mint olyan megfelelően alkalmazva, tényleg számos kissebb query összevonására jó lehet, ugyanakkor találkoztam már olyan esettel is, amikor a subselect / join -ok felbontása után 3-4-5 kissebb query futot, a stopper szerint kb 2x annyi ideig, viszont a szerver terhelése 1 alatt volt, mig változatlan látogató szám, és db rekord szám mellett a join-os megoldással 10 fölött volt.

Ezért mondom mindig azt, hogy a konkrét probléma ismerete nélkül nehéz egy ilyen kérdésre jó választ adni.