MySQL nagy abatbázisokhoz?

Adatbázis: SQL, XML DB

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?

  • 3257 megtekintés

( xclusiv v | 2007. 03. 01., cs – 16:38 )

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

( snq- | 2007. 03. 01., cs – 16:46 )

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

( hop1 v | 2007. 03. 01., cs – 16:58 )

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.

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

( rigidus | 2007. 03. 01., cs – 19:11 )

postgresql

SZERK: most latom feljebb irtak mar

Minél korszakalkotóbb ötlettel állsz elő, annál több hülyén kell átverekedned magadat.

( uid_4656 v | 2007. 03. 01., cs – 19:16 )

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.

( mauzi v | 2007. 03. 01., cs – 21:35 )

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

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.

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

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.

( drastik | 2007. 03. 02., p – 00:37 )

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

( Jason v | 2007. 03. 02., p – 09:37 )

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.

( ng | 2007. 03. 02., p – 11:03 )

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.

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.

( gabrielakos v | 2007. 03. 02., p – 12:02 )

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

( hgy | 2007. 03. 02., p – 12:19 )

Koszonom az eddigi tanacsokat, javaslatokat.

( hory v | 2007. 03. 02., p – 13:07 )

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.

( tolmi | 2007. 03. 02., p – 14:35 )

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ó.

( Panther v | 2007. 05. 13., v – 09:08 )

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

( willy v | 2007. 05. 13., v – 09:12 )

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.