Oldal: 1 / 2 12 UtolsóUtolsó
Eredmény: 1 - 10 (19) összesen

Téma: mysql gyorsra tervezés

  1. #1
    Mentor lauda logója
    Csatlakozott
    09-02-23
    Hely
    .
    Hozzászólás
    463
    Begyűjtött 3 köszönetet
    2 hozzászólásával

    Alapbeállítás mysql gyorsra tervezés

    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 ? ).



  2. #2
    Bölcs benedictus logója
    Csatlakozott
    10-04-23
    Hozzászólás
    1.578
    Begyűjtött 5 köszönetet
    5 hozzászólásával

    Alapbeállítás re: mysql gyorsra tervezés

    Idézet lauda eredeti hozzászólása Hozzászólás megtekintése
    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 ? ).
    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, ...


    Linkeld.be Linkmegosztó
    Indexeld.be - Linkgyűjtemény prémium funkciókkal!

  3. #3
    Bölcs charlie logója
    Csatlakozott
    09-11-23
    Hely
    Budapest
    Hozzászólás
    1.397
    Begyűjtött 340 köszönetet
    270 hozzászólásával

    Alapbeállítás 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.



  4. #4
    scs
    scs nem elérhető
    Meridian scs logója
    Csatlakozott
    09-01-31
    Hozzászólás
    3.032
    Begyűjtött 390 köszönetet
    233 hozzászólásával

    Alapbeállítás 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.



  5. #5
    Bölcs
    Csatlakozott
    09-08-20
    Hozzászólás
    523
    Begyűjtött 47 köszönetet
    39 hozzászólásával

    Alapbeállítás 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.



  6. #6
    Szerkesztő
    Csatlakozott
    11-11-28
    Hozzászólás
    241
    Begyűjtött 21 köszönetet
    21 hozzászólásával

    Alapbeállítás re: mysql gyorsra tervezés

    Idézet gzoli eredeti hozzászólása Hozzászólás megtekintése
    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.



  7. #7
    Bölcs
    Csatlakozott
    11-12-21
    Hozzászólás
    749
    Begyűjtött 116 köszönetet
    100 hozzászólásával

    Alapbeállítás 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!



  8. #8
    Bölcs
    Csatlakozott
    11-12-21
    Hozzászólás
    749
    Begyűjtött 116 köszönetet
    100 hozzászólásával

    Alapbeállítás 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ő...



  9. #9
    Bölcs
    Csatlakozott
    11-12-21
    Hozzászólás
    749
    Begyűjtött 116 köszönetet
    100 hozzászólásával

    Alapbeállítás 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.



  10. #10
    Bölcs
    Csatlakozott
    09-12-19
    Hely
    Budapest
    Hozzászólás
    684
    Begyűjtött 89 köszönetet
    58 hozzászólásával

    Alapbeállítás 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...)



Oldal: 1 / 2 12 UtolsóUtolsó

A téma címkéi:

Könyvjelzők

Hozzászólás szabályai

  • Új témákat nem hozhatsz létre
  • Válaszokat nem küldhetsz
  • Fájlokat nem csatolhatsz
  • A hozzászólásaidat nem módosíthatod
  •