Nagy latogatottsagu portal fejlesztese
Ki milyen cache megoldasokat alkalmaz egy olyan oldalnal ahol a varhato latogatoszam esetleg 100-es nagysagrendu?
a nem tul gyakran frissulo tartalmat nem tul bonyolult cachelni, de mi van peldaul egy forumnal, vagy hasonlo oldalnal ahol a tartalom is folyamatosan valtozik?
re: Nagy latogatottsagu portal fejlesztese
Hát igazából erre a lap struktúrája folytán számtalan jó válasz adható.
Én a livejasmin.com fejlesztési tapasztalata alapján azt mondom, hogy fel kell mérni, hogy milyen arányban történik írás/olvasás a db-be.
Ez alapján kijön, hogy valószínűleg egy ilyen lapnál mondjuk 10:1 vagy még nagyobb arányban olvasol a dbből tehát a látogatottság növekedésével a mysql replikák igen sokat segíthetnek a kiszolgálásban.
Így igazából a cache-elés mint olyan másodlagossá válik. Hiszen normál db-ből ki tudod szolgálni a kéréseket.
Természetesen a 3-ik normál forma itt a db struktúra tervezésekor nem játszik, egy erősen redundáns adattárolásra kell rá állni. Az írás műveletek nehezebbek lesznek, de az olvasáskor jelentkező hatalmas terhelés csökkenés miatt megéri bevállalni.
Meg nem utolsó sorban ott van a memcache nevű rendszer ami nagyon sokat könnyíthet a db terhein.
Azonban a lap részletes ismerete nélkül többet mondani nem igazán lehet.
re: Nagy latogatottsagu portal fejlesztese
koszonom.
igazabol a te valaszodat vartam a legjobban, mert gondoltam hogy a livejasmin -nal szerzett tapasztalatot megosztod velunk.
a laprol egy kozossegi portalnak keszul, tehat itt is inkabb olvasas lesz a db-bol tobb, es kevesebb iras.
a redundans adattarolast hogy erted? tobb tablaban is taroljam ugyanazokat az adatokat, vagy tobb db-ben? bar gondolom az elso a megfelelo megoldas.
a memcache-el a php modulra gondoltal?
re: 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.
re: Nagy latogatottsagu portal fejlesztese
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.
re: Nagy latogatottsagu portal fejlesztese
Idézet:
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
re: Nagy latogatottsagu portal fejlesztese
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.
re: Nagy latogatottsagu portal fejlesztese
Idézet:
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.
re: Nagy latogatottsagu portal fejlesztese
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.
re: Nagy latogatottsagu portal fejlesztese
kozel sem mindegy, hogy mit es hogyan joinolsz. es rettentoen fontosak az indexek.
ha ezek rendben vannak, kicsi a terheles, es a futas ido is.
de valoban, ha nincs rendesen tamogatva megfelelo indexelessel, a sokszoros joinok igen eroforras igenyesek. epp ezert kell az index:)
en is lattam lassu joinolt queryket, amik perces! sebessegel futottak a megfelelo indexelesig, miutan sec alatt lefutottak. tarhely van, az indexekkel nem kell sporolni. csak vigyazni, ne olyat hozz letre, ami keresztbevaghat masnak.
a sok adatbazishivas is megterhelo tud lenni, mind a webszervernek, es az adatbazisszervernek is (kapcsolatepites, a kom letesites, stb..stb.). annal jobb szerintem, minel kevesebb nyulsz ki dbbe, minnel kevesebb parhuzamos kapcsolat fut egyszerre.
Idézet:
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.
ebben tokeletesen egyetertunk:)