Fórumok
Sziasztok.
Láttatok/üzemeltettetek már olyan adatbázist MySQL-el, amiben sok rekord (2-3M) volt tablankent es esetleg 50 tabla volt legalabb a rendszerben, mondjuk percenkent tobb szaz kapcsolodassal/lekerdezessel?
Ha igen, mik a tapasztalatok?
Hozzászólások
Szia,
Használtam olyan rendszert, ahol minden tábla myisam volt, és az egyik tábla 5-6 millió sort tartalmazott. Ebbe írtak a progik, az aktuális sorukat update-elték, illetve mentek ebből lekérdezések. Addig nem volt baj, amíg egyszerű lekérdezések voltak, de bonyolultabb join-ok esetén a mysql addig fogta a táblát, amíg le nem futott a query. Tehát célszerű volt a szükséges adatokat kicsapni temp táblába, mert különben 10-20 másodpercig nem dolgoztak a kliensek.
Másik probléma: ilyen adatmennyiségnél nagyon nem mindegy, hogy mire teszel indexet. Mert egy table scan elég erőforrásigényes. Az insert és az indexben szereplő mező upadte-elése esetén szintén, tehát túlzásba sem érdemes vinni.
vas: 2x3,6 xeon, 2g ram, 2x73 10k rpm scsi.
x
:DDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD
muhahah
--
"en csak hupot olvasok" al3x
http://litch.eu/blog
ez gáz. na ezért nem használunk mi mysql-t sehol, ha nem muszáj. Ha az ügyfél kéri, akkor igen, de akkor is szoktunk szólni... :)
--
Gabriel Akos
Na, ez a tipikus rossz hasznalat peldaja. Myisam nem valo nagy join-okhoz. Ott az innodb, tessek azt hasznalni, ha barmi bonyibb kell, mint hattertar egy uzenofalnak/forumnak.
Igazad van, erre tényleg nem való a myisam. Monnyuk és csak select-eket írtam rá, az egész struktúrát nem én találtam ki. Monnyuk a pármillió rekord nagy része fölösleges is volt, de trükközésekkel elég jól elvitte.
ugyan nem gondolom hogy soknak/nagynak számítana, de az általad kérdezett nagyságrendbe belefér egy win32 és egy debian backendünk:
~350mio rekord körül (vegyesen kis szótártáblák és többgigásak is, csak myisam), alacsony load (15-30 qps hosszútávon) mellett lowend kiszolgálónak (dual p3 1000, 2G ram) meg se kottyan (mysql 4.1, win32, debian)
ha esetleg olyan _nem_ fixed row lenghtes táblát/indexet is tervezel, ami méretben 4G fölé mehet, előtte mindenképpen olvasd el a doksi idevágó passzusait
Nincs különösebb tapasztalatom a dologban, de ekkora adatbázishoz inkább MaxDB.
Ez anno SAPDB néven futó opensource DBMS volt, amit átvett a MySQL, mai napig az egyetlen SAP minősítéssel rendelkező opensource DBMS.
A felhasználói közt olyan cégek vannak mint: Toyota, DaimlerChrysler, Intel, Deutsche Post
Ha jól tudom mióta a MySQL átvette az adatbázisok átvitele sem jelent túl nagy gondot.
Azt hiszem sebességben sok nagy DBMS-t ver.
a sapdb az egy (régi) mysql, csicsa felülettel...
--
Gabriel Akos
Akkor nézz utána megvette a MySQL, mert mint már vki írta a MySQL egy táblakezelő sql ficsörökkel.
Érdekes módon a MySQL-ben az átvétel után lett hirtelen trigger, eljárás stb. Nagyon nem figyelem az eseményeket, mit implementáltak még belőle.
A SAPDB teljesen külön project volt, úgymond igazi DBMS. A kezdetektől fogva komoly lehetőségekkel felhasználók kezelése ésbackup terén. A MySQL a SapDB 7.4-et vette át MaxDB 7.5 néven. Ha jól tudom gyakorlatilag semmit nem csináltak vele talán PHP interface-t hozzá, meg GUI-t. Viszont mint fentebb irtam a MySQL azóta erősen bővűlt funkcionalitásai terén
Olvass egy kicsit mielőtt írsz.
http://www.sapdb.org/
Migráltak postgres-re. ;-D
postgresql
SZERK: most latom feljebb irtak mar
Minél korszakalkotóbb ötlettel állsz elő, annál több hülyén kell átverekedned magadat.
Ez annyira nem nagy adatbázis, és terhelés szempontjából megfelelő vassal és tuninggal a mysql elbirja. Viszont mielőtt elkötelezed magad emellett, nézd meg a backup lehetőségeket, mivel arra szükséged lesz, és ez szerintem sokkal nehezebben megoldható leállás nélkül mysql esetében, mint más esetekben.
Huh? Mert a mysqlhotbackup nevu script futtatasa (benne van a mysql csomagban) aztan tenyeg a "bonyolult" kategoria :))
ha megengeded százmilliós rekordszám mellett nem használom ezt a többnapos mentési/visszatöltési módot (finom lockkal fűszerezve)
(de egy egyszerű master/slave felállás kialakítása bacukphoz valóban nem kellene hogy gondot okozzon)
Nézd meg, hogy közben mi történik a rendelkezésre állással :-) Hint: ez is és a többi egyszerű mysql backup megoldás sokmindent lockol működés közben. Ez nem jó akkor, ha egy folyamatos terhelésnek kitett szervered van...
Lehet... Akkor meg:
- innodb + mysqldump --single-transaction
- siman lehet hasznalni a mysql binlogokat, azzal tenylegesen percre pontos allapotot vissza lehet allitani
- mysql replikacio is egyfajta backup; egy gepen meg lehet akarmennyi mysql instance
Ha a replikációt időben el tudod tolni akkor, OK, de ha szinkronban megy akkor egy rosszul kiadott select ellen nem véd.
MySQL 4.1, Linux 2.4, Celeron 2.66, 256MB RAM.
adatbázis: myisam, 84 tábla, néhány táblában tízmillió feletti rekord.
másodpercenként 2500-3000 lekérdezés, 350-650 szimultán kapcsolat (távoli hostról, PHP-val)
jó, mondjuk a lekérdezések legnagyobb része SELECT, beágyazott sub-SELECTekkel. (web portál)
megy...
"másodpercenként 2500-3000 lekérdezés"
Nincs ez elírva?
Jóóóó nagy sávszél, null response-okkal... :D
nincs elírva :)
nem null response-ok... news rovat cikkek, film- és kép adatbázis adatok, fórum hozzászólások, stb.
;) Csinos adat.
ehm. most néztem meg a statisztikát. azóta 3800 query/sec :)
(utoljára akkor néztem, amikor az adatbázist külön gépre tettük, levettük a webszerverről frontend-backend elven)
egyébként, igen sokat köszönhetek a query cache-nek. ritkán változó tartalmak (pl újságcikkek) esetében rengeteget lehet vele nyerni.
Borzasztó gyors, nem gondoltam volna :)
Mondjuk utoljára vagy 6 éve mértem mysql-t, de már akkor is megdöbbentem, hogy session-kezelőként is sokkal gyorsabb volt, mint file-ba mentegetve.
hat, hat ezt nehez elhinnem..
2x2.8 xeon, 4g ram, 2db 18as 15krpm diszk, raid1. egy tabla, egy varchar(32),
random md5okkel megszorva, 3M rekord.
az insert doglassu, 700 insert/s fole nemmegy;
random selectekkel is doglassu, 600-700keres/s fole nemmegy..
memcached birt 11k/s requestet, de aztis nyogvenyelosen.
most irtam helyette sajat kiszolgalot, nyilvan nagyon specialis,
de ez felment 90k req/s korulre (random request), es ~40k insert/s -re... ;)
"hat, hat ezt nehez elhinnem.."
Akkor meg van mivel ismerkedni. :-)
Minél korszakalkotóbb ötlettel állsz elő, annál több hülyén kell átverekedned magadat.
care to elaborate?
Milyen tabla, konyorgom? Mysql-nek kurvasok storage engine-je van, es nagyon nem mindegy, melyiket hasznalod!
default.
a defaultra voltam kivancsi, mindenfele extra hergeles nelkul.
_nemhiszem_, hogy tuninggal ki lehet hozni meg 200%ot.. :)
"default"
Gondolom, ha veszel egy TV-t, azon is csak a gyárilag beállított csatornákat nézed...
na ez is egy speciális eset, ugyanis a lekérdezések nagy része tökegyforma, minden válasz be van cachelve, gyakorlatilag a memóriából dolgozik az egész. Erre (még) pont jó a mysql, a párhuzamos kapcsolatok száma se túl sok még neki.
--
Gabriel Akos
Nem a valaszok vannak becache-elve, hanem az indexek.
A query cache -t minden ertelmesebb helyen kikapcsoljak, es a felszabadulo memoriateruletet meghagyjak az indexeknek.
Ennyivel gyorsabb lenne mindig kiértékelni a queryt, indexet nézni hozzá (ha éppen van) és az OS VM cache-éből kiszolgálni az adatot, mint rögtön odaadni cache-ből?
Nem. De a query cache egy irtozatosan primitiv szerkezet: siman odab***tak egy ellenorzest a query feldolgozas ele, ami megnezi, hogy van-e pontosan ugyanilyen query string a cache-ben, es ha van, visszaadja, ha nincs, lefuttatja es cache-eli. Ha irtak _barmelyik_ erintett tablaba, az egeszet invalidalja.
Na ezt az izet en nem eroltetnem. Rohejes "megoldas".
Világos, viszont sztring egyezőséget keresni, majd a választ bután visszaadni még mindig fényévekkel gyorsabb, mint SQL-t parse-olni, indexekben (jó esetben) keresni, egyéb dolgokat csinálni majd a választ visszaadni.
Tehát összességében nem látom, hogy miért kellene kikapcsolni.
ez ___kis____ terheles
meg a mysql is elviszi
ami amugy egy tablazatkezelo nemi sql ficsorrel felvertezve
--
"en csak hupot olvasok" al3x
http://litch.eu/blog
Van esetem olyan adatbazissal, ahol 170+ tábla van, 15 millios nagysagrendu sor, nemely tabla >>1giga. Mind elegge vastagon van select-elve, insertelve folyamatosan, neha batch update is megy ra, az is ~100k sorokat egyszerre. Ez midnen tablara.
Bírja. Csak figyelni kell a részletekre.
--
"SzAM-7 -es, tudjátok amivel a Mirage-okat szokták lelőni" - Robi.
A karakterkódolásra is figyelni kell hogy ne menet közben konvertáljon a mysql. Meg csak azt szoktam selectelni amit muszáj, nem *-t.
Mamaaaaaaaaa!!!!!!
:)
csondesebben! vannak helyek ahol ez a technika csucsa! ;-)
Nekem az a tapasztalatom, hogy a programozók többsége "select *" okat ír mindenhova. A mostanában végzett programozók nagy része meg már where-t sem használ, hanem az eredménytáblában keresgél kliens oldalon for ciklusokkal meg foreach-csel.
Nem tudom, miért tanítanak mostanában ilyen szörnyűségeket, de nagyon hígul a szakma és így a hardverek teljesítménye sosem lesz elég, hiába is modják ezek az okosok, hogy olcsóbb a hardver, mint optimalizálgatni...
Tudod, a vastag kliensek...
Ja, anno java gyakon futott le a következő szösszenet, érdemes szörnyülködni.
* Tanár, táblára elkezd felvésni java kódot, sakktáblás móka, int x, int y. Valaki jelentkezik:
- Detanárúrkéremtisztelettel, minek int, ha char is elég 1..8 értékhez?
* Erre a többi, épp végzős, ugyancsak informatikus(?) lehurrogja:
- Ugyanmár mit balf@szkodsz, a p4-esek korában...
Aki magára ismer ebben a megtörtént esetben, szégyellje magát ezúton is.
--
"SzAM-7 -es, tudjátok amivel a Mirage-okat szokták lelőni" - Robi.
Szerintem is szégyellje magát az, aki a chart ajánlotta. Java-ban a char unicode karakterek ábrázolására való (és nem számokéra). Ha valakinek mindenképp túl nagy az int, használjon short-ot (ami egész, előjeles számok ábrázolására való). Főleg, hogy Java-ban a char is meg a short is 16 bites.
Nem ezen volt a hangsúly, de ez is jogos.
A "fasznakoptimalizáljunk, úgyisvanprocidögivel" mentalitásra kéne koncentrálnod.
Mellékesen tök jól lehet char-t használni számoknak tárolására. Kreativitás, emberek. hiszen a java egy nagyon jó nyelv, nemdebár? :P
--
"SzAM-7 -es, tudjátok amivel a Mirage-okat szokták lelőni" - Robi.
Es egyebkent nativ kodban is gyorsabb gepi szo meretu valtozokat (32/64 bit, attol fugg) hasznalni.
--
Fontos feladatot soha ne bizz olyan gepre, amit egyedul is fel tudsz emelni!
láttunk. a 2-3M rekord amúgy a "nem sok" kategória. A 10M fölöttiek már izgalmasak, 100M fölött meg pláne. De persze ez is attól függ, hogy mi a "usage pattern". Mert ha mindig ugyanazt az 1000 rekordot kérdezed le, akkor érdektelen, hogy mennyi van még mellette a diszken. Ha viszont általábanm összevissza kellenek az adatok, na az már izgi.
A több100 kapcsolódást pedig abszolút feleslegesnek tartom, régen feltalálták már a connection poolingot meg a 3 rétegű architektúrát.
A mi legnagyobb rendszerünk csúcsterhelésen sem használ 50 connection-nél többet, és értelemszerűen a kapcsolódások száma is minimális.
--
Gabriel Akos
Koszonom az eddigi tanacsokat, javaslatokat.
BTW: a RIPE NCC whois-servere, amit tobbek kozott en is butykolok, mysql-t hasznal. kb. 60 tabla, ebbol 2 nagy, 8-10millio rekordos, kb. 10-20 darab 2-5 millio rekordos, a maradek "pici".
Az egesz whois.ripe.net 2 fizikai vason megy, dual 3GHz-es p4 xeonok. Terheles tipikusan <30% ...
Konkluzio: nincs rossz szoftver, csak rossz programozo.
A későbben idetalálóknak:
Szeretném figyelmetekbe ajánlani a következő cikket:
[url="http://royal.pingdom.com/?p=95"]What the Web's most popular sites are running on[/url]
[url="http://royal.pingdom.com/royalfiles/0702_infrastructure_matrix.pdf"]Az érdekes mátrix[/url](PDF)
A site-okat meglátogatva kiderül, hogy milyen jellegú lehet az adatbázisok terhelése. Azokra a feladatokra úgy látszik jól helyt áll a MySQL. Ha más nem is, de elgondolkodtató hogy ők miért választottak MySQL-t.
--
- Miért jó a mazochistának?
- Mert ha rossz, akkor jó. Ha meg jó, akkor rossz, tehát jó.
Ez biz meggyőző, de jó lenne ha lenne pár trükk leírva (link) amivel gyorsíthatunk adatbázisokon.
Bár én "kommunista" vagyok, de nekem azt súgta valaki, hogy ha írsz levelet ezeknek a site-oknak, akkor szívesen fogadnak. Sosem próbáltam, a madarak csiripelték.
--
- Miért jó a mazochistának?
- Mert ha rossz, akkor jó. Ha meg jó, akkor rossz, tehát jó.
Akkor alighanem rákeresek ezekre a madarakra, elvtárs.
Lehet, hogy off, de nem tudom, miért pont mysql. A halmazműveleteket a mysql5 még mindig nem tudja rendesen, és pl. a halmazkülönbség nagyon nem megy neki még mindig...
--
hup.user.js
Amit leirsz, az altalanos adatbazisra utal, nem minosul "nagy"-nak. A sorok meretetol, a select/insert aranytol, es a lekerdezesek minosegetol fog fuggeni a mukodes, A mysql is siman megbirkozik vele.