Maradjunk a kézenfekvő és elterjedt PHP-MySQL példánál. Ha kevés a teljesítmény, betolunk még egy PHP-s szervert és máris minden oké. Lenne, ha nem kellene továbbra is ugyanattól az adatbázis-szervertől lekérdezni a zadatokat.

Fürtözés

Ugyan van a MySQL-nek fürtözött (cluster) módja, de sajnos nem ilyen rózsás a helyzet. Az nem úgy van, hogy beállítok egy kapcsolót - fürtözés múkodj now! - és hátradőlök. A MySQL fürtözött változatának korlátozott képességei vannak, nem egy, nem kettő: a saját dokumentációjában is több oldalt szentelnek a témának. Nem kell elolvasnod, összefoglalom a szerintem legsúlyosabb hiányosságokat:

• Nem lehet indexelni a TEXT és BLOB mezőket és nincs FULLTEXT index sem. Laikusoknak: nem lehet keresni nagyobb szövegekben.
  
• Az adatbázis mérete mindennel együtt maximum akkora lehet, hogy elférjen a fürt bármelyik masinájának a memóriájában. Ha már akkora az alkalmazásod, hogy fürtözni kellene az adatbázis szervert, akkor általában nem fog elférni az egész adatbázis abban a pár gigában. Ez a korlátozás a még béta 5.1 verzióban sem lett teljesen feloldva, ott "csak" az összes indexelt adatnak kell elférnie.
  
• Ha új szervert kell betolni a fürtbe, akkor az egész fürtöt újra kell indítani. Az újraindítás alatt nyilván nincs semmilyen adatbázis-kapcsolatod és ha gáz van, akkor nem néhány másodpercről van szó. Dinamika nélkül pedig nem fürt a fürt.
  

Replikáció

Kilőttük a fürtözést, nézzük a (régebbi) alternatívát, a MySQL replication-t. Gyakorlatilag ezt használja mindenki, még nagyon nagy szolgáltatások (pl. Flickr) is. A replikáció úgy működik, hogy egy master szerverről automatikusan átszinkronizálódik a tartalom egy vagy több slave-re.

A slave-ekre írt tartalom viszont nem megy vissza a master-re, tehát ez az egész arra szolgál, hogy a master szervert ne terheljük olvasással, csak írással (insert/update/delete). Egész vad lehetőségek is vannak, pl. több master körbe-körbe replikálva, de a lényeg ugyanaz marad.

Ez a módszer egészen addig kiválóan működik, amíg a master bírja az adatbázis-módosításokat. Ha kevés az olvasási teljesítmény, indítunk egy új replikát és kész. Itt is van egy kis bibi, mert bár nem kell a mastert vagy a többi slave-et újraindítani, de a teljes adatbázis átrántása nem kis terhelést okoz. Erre vannak ügyes technikák, pl. egy erre a célra fenntartott master-replikáról másolunk.

MySQL replication-nel egészen magas szintig, napi több millió látogatóig is elmehetünk, ha jó alkalmazást írtunk. De ha nem lennének korlátozások, a fürtözés lenne az ideális megoldás. A MySQL replication erősen hack szagú megoldás.

Más adatbázis-kezelők?

Nem véletlen, hogy a legtöbben MySQL-t használnak. Az adatbázis-kezelők legjobbika, az Oracle lenne a legjobb, leggyorsabb, rendes fürtözéssel, satöbbi... viszont marha drága, webes projektek költségvetésébe (még az usákok millió dollárosába) se fér be. Nem is értem miért csinálják ezt, de biztosan elemezték a pénzeket és így jó nekik, pedighát.

A többi alternatíva, pl. PostgreSQL/EnterpriseDB sem tud többet, jobbat a MySQL-nél, egyelőre, ezt gyorsan elintéztem.

BigTable, DataStore, HBase?

Nem. Ezek a nagy dögök valóban igazi fürtözést és brutális teljesítményt ígérnek, azonban nem hagyományos relációs adatbázis-kezelők. Egy eltárolt sorban (egy rekordban) ugyanis csak egyetlen kulcsmeződ lehet és csak az alapján lehet keresni. Ez olyan, mintha az Excel tábládat csak az A oszlop szerint rendezhetnéd sorba és kereshetnéd.

Értelemszerűen nem lehet így tetszőleges lekérdezéseket és kimutatásokat futtatni, a teljesítmény oltárán beáldozod a rugalmasságot. Hiába jön majd a főnök, hogy csinálj egy gyors kimutatást a kékhajú 23-48 éves felhasználókról, nagy valószínűséggel nem lehet majd megcsinálni.

Megoldás?

Vannak próbálkozások, sőt sokan a hagyományos relációs adatbázis-kezelők halálát, komplett gondolkodásmód-váltást (paradigmaváltás) jósolják, javasolják. Hát-hát...

Ők azt mondják, hogy oldjunk meg mindent a kulcs-érték alapú BigTable szerű megoldásokkal. Meg hogy a relációs dolgot a 70-es években találták ki tök más erőforrás-összetételre, pl. akkor a cpu és ram nem volt ilyen olcsó (ebben igazuk van, általában a diszk elérésen hasalunk el miközben a cpu és a ram még bírná).

Sok-sok doksit olvastam már de egyikben sem volt megoldás a kékhajú problémára.

Egyelőre nincs mindenkire jó és tetszőlegesen felskálázható megoldás. Ha belefutsz az egy szem MySQL szervered korlátaiba, utána át kell tervezned és írnod a webes alkalmazásod egy (nagyobb) részét. A fenti megoldások valamilyen egyedi kombinációja lesz az eredmény az alkalmazásod egyedi jellegzetességeitől függően és sok pénzt fogsz fizetni a programozóidnak. Ez van.

0 hozzászólás - Te lehetsz az első!

Legutolsó hozzászólások

DJ PLAYER Blue Edition: Gábor: Ja, és természetesen megy iPad-en is, hiszen _minden_ iOS app megy iPad-en.

DJ PLAYER Blue Edition: Gábor: Bug report-okat itt fogadunk: http://djplayer.net/page/bug_report_fixes

DJ PLAYER Blue Edition: hohand: Hello!A dj player mukodik iPad-on is?Tegnap feltettem, wifi-n athuztam ra zeneket,de amikor ranyomtam egy zeneszamra,error-t dobott es valami is!...

Uzsidoboz LED!: zo via Google Reader: vicces dolog, csak nem értem mire való

Uzsidoboz LED!: Gábor: @Benjamin Minek forogjanak? Egy falszínezőnek olyat nem kell tudnia, így is épp elég hatásosak.