re: mysql gyorsra tervezés
Idézet:
lauda eredeti hozzászólása
Szeretnék csinálni egy egy apróhirdetési oldalt. Jó lenne ha majd amikor sok adattal lesz feltöltve akkor is gyors lenne, ezért már most el kell döntenem hogy kezdjem. Pl. a kategóriáknak új táblákat csináljak-e vagy minden adat menjen 1 táblába és a kategória mezőt indexbe tegyem (vagy key ? :confused1:).
praktikus külön táblával kezelned a kategóriákat, mert valószínűleg nem csak a kategóriák neveit tartalmazza, hanem:
katid, kat_szulo, katnev, kat_seonev, kat_leiras, ...
re: mysql gyorsra tervezés
Nomeg külön layerbe rakni az adatbázis közvetlen elérését, valamint az alkalmazás adatbázis kezelését, hogy könnyebben lehessen partícionálni, pl. vagy több db szerverre küldeni a lekéréseket.
re: mysql gyorsra tervezés
Igaz, nem vagyok programozó, tehát sok sejtésem nincs a dologról. De azért egy nagyobbfajta apróhirdető oldalnál megnézném az óvatlan delikvens arcát, mikor rácsodálkozik a pár száz, esetleg 1-2 ezer táblára, amit a kategóráknak hozott létre a drága ember. :)
A kérdésre válaszolva (továbbra sem programozóként): Először fundáld ki, hogy milyen lesz az oldalad, mennyi kategóriád lesz, lesznek-e kategóriánként más-más űrlapok/tulajdonságok, ha lesznek, hogyan kezeled azokat, stb. És máris tudni fogod, hogy melyik lesz számodra előnyösebb. ;)
re: mysql gyorsra tervezés
Ha gyorsra akarod csinálni, akkor az oldallekéréseknél már nem használod az adatbázist és a PHP-t, hanem előre generálod, nginx-t futtatsz, és a statikus tartalmat memóriából szolgálod ki, amikor frissülés van, akkor pedig rsync-el berakod oda.
re: mysql gyorsra tervezés
Idézet:
gzoli eredeti hozzászólása
Ha gyorsra akarod csinálni, akkor az oldallekéréseknél már nem használod az adatbázist és a PHP-t, hanem előre generálod, nginx-t futtatsz, és a statikus tartalmat memóriából szolgálod ki, amikor frissülés van, akkor pedig rsync-el berakod oda.
Igy van, az adatbazis lekerdezesek szamat minimalizalni kell. Memcached es mas cache technologiakat hasznalva ez jol ki is vitelezheto - mindaddig amig a lapjaid cachelese belefer a memoriaba (mondjuk diszkre is cachelheto a tartalom, de akkor a sok IO lehet szuk keresztmetszet). Persze a jol megtervezett adatbazis is fontos, de valamennyire a tervezesi hibakat lehet cache segitsegevel foltozni.
re: mysql gyorsra tervezés
Imot, ez így kicsit furcsán cseng:
"Persze a jol megtervezett adatbazis is fontos, de valamennyire a tervezesi hibakat lehet cache segitsegevel foltozni."
Egy rosszul tervezett mysql db pláne nem kellően optimalizált querykkel már önmagában is képes padlóra küldeni a szervert... Pláne mert itt arról beszélünk, hogy látogatott honlapot fog kiszolgálni hatalmas mennyiségű adat felhasználásával. Arról nem is beszélve, hogy a cache-nek is le kell egyszer járnia hiszen frissülnek az adatok... Ráadásul ebben az esetben rengeteg különféle lekérés lesz a menük, submenük, stb. alapján!
re: mysql gyorsra tervezés
Én használnék memcache-t és smartyt, ez lenne az alap. Aztán összeírnám, hogy milyen adatok kellenek a hirdetésekhez, milyen mélységű menüt használnék, barátságos url navigáció lesz e, meg mindent átgondolnék.
A fentiek alapján megtervezném a mysql táblákat, majd valós adatokkal tesztelném, tesztelném, tesztelném és közben finomítanám a querykkel együtt. Különös tekintettel a fulltext-re.
A következő a memcache lenne. Mi kerüljön bele, mennyi ideig kerüljön bele, a teljes adatokat bele rakjam vagy csak id-et, stb.
Itt figyelembe venném, hogy egy feladott hirdetés adatai nem változnak állandóan, így tokkal vonóval bele raknám a memcache-be úgy 15 percre, aztán replace ha közben megnézte valaki. A szabad szavas keresés eredményét egyáltalán nem raknám bele, viszont a kategória keresés eredményének az id-jeit igen, úgy 24 órára mert ez nyilván akkor változik csak ha új hirdetést vittek fel. Persze itt figyelni kell arra, hogy mekkora memória használati limit van beállítva a memcache-hez, mert alapban elég kicsi. A másik fontos dolog amire figyelni kell, hogy az új elemek memóriába kerülése érdekében a rendszer nem töröl e egyébként még érvényes elemeket. Ha igen akkor az érvényességi időket át kell gondolni, mert egyébként értelmetlenné válik a memcache.
És a végén jöhet a smarty... Mit kell cachelni, mennyi időre, stb.
Persze ez így csak nagyon általános megfogalmazás, de szerintem a lényege érthető... :)
re: mysql gyorsra tervezés
A mysql kérdést így elsőre nem bonyolítanám túl.
A következő táblák lennének: menü adatok, megjelenő hirdetések alap adatai, megjelenő hirdetések komplett adatai, user adatok, user komplett hirdetések (random szétosztva kb. 10 táblába userenként), statisztika, egyebek amit esetleg még bele tervezel.
A mezőkre nehéz bármit mondani amíg nem látni, hogy pontosan mit akarsz eltárolni.
De nyilván a dátum az timestamp, a menük int commentezve, a cím esetleg bevezető legyen 255 karakterre maximalizálva, auto increment használata minden táblán, stb.
re: mysql gyorsra tervezés
Sziasztok!
Úgy érzem nagyon elmentetek a dolgok részleteibe, mig a körvonalakat nem definiáltátok elég pontosan.
Előszőr is meg kell határozni, hogy pontosan mit szeretnétek, ha tudna az oldal stb stb. Ha megvan
a végső cél, akkor már céltudatosan tudtok fejleszteni. Nagy előny, hogy saját magatok fejlesztitek
a rendszert és nem egy többcélú rendszert kell foltozni, például joomla, stb stb...
Általános tervezési szempontok szerint a következőket vegyétek figyelembe:
- Minden kérés legyen annyira egyszerű, amennyire csak lehet. Egyes kéréseknél sokszor az összehasonlítás
módja is terhelési különbséget okozhat például adddate(datummezo,interval 15 minute)>now() vagy
datummezo<subdate(now(),interval 15 minute) közötti különbség.
- A lehető legkevesebb left joint használjátok
- a korrekt index sok erőforrást sporol meg, egyúttal érdemes figyelni arra, hogy a blob, text mezőtípusokat
lehetőség szerint ne használjátok összehasonlítás alapként, kifejezetten, ha regexpek alapján is kerestek.
- A lekérdezések megfogalmazásakor ellenőrizzétek azt, hogy alkalmazható-e rajta a query cache, tehát
nem ellentétes a lekérdezés a qc feltételeivel. Részemről a memcached termék szinten való lekérdezéséhez
való használatát nem erőltetném.
-A qc nagyon jól használható a legtöbb esetben, igaz praktikus rutin az, ha igyekeztek a lassabb lekérdezést
eredményező táblák esetén a táblák módosításának mennyiségét is redukálni.
Nem látom értelmét annak, hogy sok kis táblára bontsátok az adathalmazt, mivel a fejlesztés idejét drasztikusan
növeli és nem feltétlenül jelent akkora előnyt, ráadásul a szükséges cache mérete sem biztos, hogy optimális lesz.
Az olyan adatokat, amik legtöbb esetben csak időszerűek, (például session adatok) érdemes
memcached-ben tárolni, a file tárolást az i/o és az fs overhead miatt inkább hanyagoljátok.
Lényegében, ha tiszta és nem összevágott kódot készít a fejlesző, a mysql szerver sokat kibír, ha pedig kevésnek
kezd bizonyulni, akkor igyekezzetek külön szerveren üzemeltetni a mysql-t! A CPU effektív teljesítményének
összehasonlítása helyett sokat számít az, hogy hány CPU magot biztosít az adott konfiguráció. Esetekben egy
4 mag x 2GHz-es konfiguráció kisebb teljesítményű lehet a mysql számára, mint egy 8x1GHz... A számokat csak
viszonyításnak írtam. (nem megyek bele a részletekbe, de a kernel processz kezelése miatt...)