'webadmin' kategória archívuma.

Mi a baj a Twitterrel?

Mármint techikailag: miért van ennyi leállás, milyen problémák vannak a háttérben? A választ elég jól összefoglalja a ReadWriteWeb, ebből kiinduló, de saját hasonló jellegű tapasztalatokkal fűszerezett összefoglaló következik.

Nos, az első és legnagyobb gond az, hogy a Twitter nem arra lett tervezve, mint amire ma használjuk. Egy CMS szerű felépítésben gondolkodtak a fejlesztők, ahol a skálázhatóság megoldása a cache volt – kb.: egy hozzászólás után töröljük a cache-t, majd generáljuk le az oldalt megint. A Twitterből azonban nem CMS nőtt ki, hanem egy üzenetküldő platform, a gyakori frissítések használhatatlanná tették ezt a cache-elési módszert (ugyanis nem csak a saját oldalunk cache-ét kell törölni, hanem minden olyan oldalt, ahol “követ” minket a tulajdonos). A probléma nem kis látogatottságnál, hanem extrémnél van – de ez az amivel a Twitter ma küzd, ráadásul nem beálló, hanem folyamatosan növekvő látogatottságról van szó. És ez az architektúra sajnos nem igazán skálázható ezzel a felhasználási körrel – egyáltalán.

A skálázhatóság problémája ott kezdődik, hogy vajon hogyan tároljuk le ezeket az adatokat. Itt hozom be a személyes tapasztalatokat, konkrétan a Miner.hu-t mellékleteket. Mind a Twitter, mint a mellékletek esetében egy jó nagy adatbázisról beszélünk (Minernél ez 8 millió sor, Twitternél inkább ne is akarjuk tudni). melyből ki kell válogatni bizonyos tulajdonságú elemeket (Twitternél adott felhasználó és barátai csiripjeit, Minernél az adott melléklet blogjaihoz tartozó bejegyzéseket). Ha a lekérdezés eredményét illetően nincs sok elemről szó, akkor nincs hatalmas gond, az adatbázisszerver gyorsan összemixeli az elemeket (felhasználónként, blogonként), és kiköpi magából. A Minernél a film melléklettel indult a gond, aholis bár viszonylag kevés bloggal indultunk, de az egyes blogokban (comment:com, sorozatjunkie) rengeteg bejegyzés szerepelt visszamenőleg, melyek (indexei) már nem fértek bele a memóriába a lekérdezéskor, és elkezdett diszket használni a MySQL. Ugyanez a jelenség a Twitternél is fennáll – memóriaigényes összefésülni különböző felhasználók csiripjeit. Míg a Minernél viszonylag kevés melléklet van, ezért megoldást jelentett az, hogy egy külön táblában is indexeljük a mellékletek bejegyzéseit (így direktben használhatóak indexek, nincs több blog összefésülése), a Twitternél ez nem jó megoldás, hiszen rengeteg felhasználónál, rengeteg fajta leválogatást kell összehozni. Vagy mégis?

Erre a problémára az adatok duplikációját, az adatbázis denormalizációját szokták megoldásként felhozni, avagy egy olyan megoldás jöhet szóba, mely amikor hozzászól valaki egyet, akkor az adott felhasználó adatbázisába történő bejegyzés mellett a többi, őt követő felhasználó adatbázisába is felveszi a hozzászólást. Ez elsőre gyilkosnak tűnhet, de egyrészt ugye a hozzászólás maximum 140 karakter környékén lehet, tehát nincsen szó hatalmas adattárolási igényekről, másrészt pedig az egyes felhasználók adatbázisát jópár különböző szerverre szét lehet szórni, így párhuzamosítható a művelet. Másrészt mostanában divatos nem relációs adatbázisokra építő, jól skálázható elosztott adatbázisok (cloud computing – ismerős?) pont kiválóan használhatóak így.

Persze nem tudom, hogy a Twitter valóban ilyen megoldást választ-e, s hogy pont ilyen problémákkal küzd-e éppen, de valószínűleg – s ebben a belinkelt RWW-s bejegyzés is megerősít – nem olyan messze áll a fentiektől a valóság.

MySQL 6.0 online backup

A MySQL 6.0 online backup lehetőségéről már írtam (Webadmin rövidhírek #2), most viszont napvilágot látott egy részletesebb bemutatója is, amit be kell linkelnem. A 6.0 verzió egy olyan újdonságáról van ugyanis szó, ami miatt mindenképp érdemes lesz átállni. Mondom persze ezt akkor, amikor még az 5.1 sem jelent meg, de hát…

A lényeg:

The word “online” means “without blocking”. So, unlike earlier backup solutions which could make all other jobs hang, the Online Backup statements will allow certain Database Manipulation Language statements to go on concurrently. Some locking still occurs, but it’s minimal.

Avagy úgy lehet backupolni, hogy a backup folyamat nem fogja megakasztani az SQL műveleteket. Aki kis adatbázis táblákkal dolgozik, annak ez nem olyan hatalmas előny, de a miner.hu kapcsán folyamatos szívást jelent a több 10 GB-nyi adat megnyugtató mentése. Alapból ha “simán” backupolnánk, a legnagyobb, 10 GB-os táblánál negyed óráig is blokkolva lennének a kérések, és ez bizony nem jó. Bár ezt meg lehetett oldani egy slave adatbázisszerver beállításával, aminél egyáltalán nem baj a blokkolás backup közben, de sajnos ez sem fenékig tejfel, mert ha inkonzisztens lesz a slave, akkor az egész mehet a kukába. Az online backup ebből a szempontból sokkal tisztább és szárazabb érzésnek tűnik, és lehetővé teszi például azt is, hogy legalább a slave-nek életet lehet adni úgy, hogy nincs leállás.

Szóval instant get lehet, majd amikor megjelenik. Év végére ígérik.

Webadmin rövidhírek #3

Aktuális webadmin rövidhírek, szokás szerint megint főként MySQL témakörben, kiegészülve egyebekkel.

MySQL vs symlinkek

A MySQL MyISAM táblatípusának előnyei között emlegetném, hogy minden tábla külön fájlként szerepel, s minden adatbázis egy külön könyvtár a háttértáron történő reprezentációt illetően. Nem mindig jut az ember eszébe egy apró trükk, miszerint symlinkekkel “mozgathatóak” ezek a fájlok, így akár másik fizikai meghajtóra is át lehet helyezni azokat. Főként akkor jön jól a dolog, amikor éppen helyszűkébe kerül az ember.

SQL tuning

Az adatbázis optimalizáció témáról sohasem lehet eleget olvasni. Egy elég jó prezentációt rakott össze Jay Pipes (MySQL-es fazon) ebben a témában, mely nem csak MySQL-es szemszögből lehet érdekes.

MySQL Konferencia videók

Pár hete zajlott le a 2008-as MySQL konferencia, ennek videói lett elérhetőek – jópár érdekes téma volt, érdemes átnézni ezeket.

SimpleDB

Múltkor a CoachDB-ről írtam, most pedig egy SimleDB-s írást linkelek be, mely a hagyományos RDBMS – SimpleDB összehasonlítás témakört járja körül.

HScale – sharding MySQL Proxy alapokon

Magas rendelkezésreállás megoldások között az egyik menő téma a sharding, avagy nagy táblák bizonyos tulajdonságok mentén külön szerverekre történő széttördelése. Ezt a megoldást jellemzően alkalmazás szinten szokás megoldani, de van megoldás az adatbázisszerverek közelében is, a MySQL Proxy-t használó HScale kapcsán.

Dormando’s Proxy for MySQL

A fenti névvel illetett DPM nevű SQL proxy hasonlóan működik a MySQL Proxy kezdeményezéshez, ugyanúgy Lua-ban programozható, de lehet hozzá C modulokat is írni ha a sebesség fontos szempont (ezek a proxy-k szignifikánsan, több 10%-kal képesek az adatbázisszerver sebességet csökkenteni, valaki csinált egy mérést erről). Fontos szempont lehet még, hogy a MySQL körüli licenc kavarásoktól független, BSD licencelésű projektről van szó, szóval tutira szabad és ingyenes.

Webadmin rövidhírek #2

Egyszer már írtam rövidhíreket webadminisztrátori (értsd weblapok hátteréül szolgáló szerverek rendszergazdáinak, adminjainak szóló) hírekről, ha minden jól megy, ebből folytatásos sztori lesz, főként MySQL témákban, de semmiképpen sem kizárólagosan. Következzenek hát rövidhíreink.

MySQL 6.0+ újdonságok

A MySQL 5.1 széria lassan, de biztosan éles környezetben is ajánlott verzióvá válik. Ha minden igaz, és a négynapos ünnep alatt nem változott a helyzet, most release candidate szerű állapotban leledzik, s egy olyan könnyelmű vélemény is elhangzott, hogy nincs benne hiba (ami persze nem igaz, de legalább jól hangzik). Ennek fényében ideje előretekinteni a következő MySQL verzióra, a 6.0-ra.

Ha valaki szeretné folyamatosan követni a MySQL 6.0 újdonságait, mindenképpen ajánlom figyelmébe az erről indult blogot, most pedig konkrétan a jövőt összefoglaló bejegyzést, The Roadmap címmel.

Legfőbb újdonságként a kisebb-nagyobb változások mellett kiemelném a Falcon adatbázismotort (igazi tranzakcióképes, modern motor) és az új backup mechanizmust, mely lehetővé teszi az adatbázis műveletek blokkolása nélküli backupolást (mindegyik adatbázismotorral). A MySQL 6.0 a tervek szerint az év vége fele várható.

MySQL optimalizálás

A MySQL a lekérdezéseket optimalizáló stratégiája – ahogy más adatbázisoké is – becslések alapján végzi a munkáját, választja ki a használt kulcsokat, stb. Ez a stratégia nem mindig jön azonban be, van amikor nem árt a rásegítés. Egy konkrét optimalizálással kapcsolatos példát olvashatunk az operációs rendszer cache és a lemezműveletek kapcsán a MySQL Performance Blogban.

Magas rendelkezésre állású MySQL

Több magas rendelkezésre állással kapcsolatos projektet gyűjtött össze a közösség pozitív tevékenységét bemutatandó a MySQLHA blog, melyek mind hoszting cégeknek, mind pedig a nagy rendelkezésre állásra törekvőknek érdekesek lehetnek.

Apache CouchDB

A CouchDB projekt, mely nemrégiben került be az Apache Software Foundation által gondozott projektek közé, egy olyan adatbázismotor, mely nem relációs adatbázisműveletek, hanem sokkal inkább dokumentum jellegű adattárolásra és lekérdezésekre szolgál. A projekt azért is érdekes, mert a Google és az Amazon is hasonló adatbázisokat kínálnak hoszting projektjeik keretében – a cél egy igazán jól skálázható, gyors adatelérést biztosító háttéradatbázis létrehozása. Az adatbázis sémáját (oszlopainak nevét, típusát) nem kell előre meghatározni, egy adatbázis elem (”sor”) szabadon tartalmazhat “oszlopokat”. Másik nézőpontból: egy adatbázis elem gyakorlatilag egy sztringekből, számokból, dátumokból, tömbökből, hashekből álló hashként (asszociatív tömbként) letárolt adathalmaz.

Az adatbázis REST kérésekkel írható, olvasható, az adatok JSON formátumban közlekednek. Mind emiatt, mind pedig a jó skálázhatóság miatt Web 2.0 barát megoldásnak nevezhető adatbázisról van szó, de ne számítsunk összetett, az SQL adatbázismotoroknál megszokott lekérdezhetőségre, amikor nem egy konkrét elemet kérdezünk le, akkor össz-vissz úgynevezett nézetekre támaszkodhatunk csak, melyek függvényszerűen leírt szűrőként működnek.

Webadmin rövidhírek

Webadmin jellegű rövidhíreink következnek.

MySQL 5.1 Load Balancer

A MySQL hamarosan megjelenő 5.1-es verziója load balancerrel érkezik. Bár jelenleg még csak olvasásra képes eszközről van szó, az irány ígéretes. A fejlesztés abból a szempontból is érdekes, hogy a MySQL Proxyra épül.

10.000 szerver a FaceBook infrastruktúrájában

Az InsideFacebook szerint 10.000 feletti számú szerver szolgálja ki a FaceBook oldalait. Konkrétan:

  • 1800 db MySQL szerver
  • 10.000 db webszerver
  • 805 db memcached szerver

Elég impresszív számok, ezek után az iwiw szervereinek számán ne csodálkozzunk.

Lassan teljesen nyílt forrású lesz a Java

A Yahoo News ír róla, miszerint a Sun a Java további részeit is nyílt forrásúvá teszi. Ez azt fogja jelenteni, hogy a Linux disztribúciók alapból fogják tudni szállítani, a Java futtatására képes gépek (mind a szerver, mind pedig az asztali masinák terén) még nagyobb teret nyernek. Nem tudom, hogy a nyílt forrásnak köszönheti-e a Java, de egyre inkább érett, és a magamfajta scriptnyelv fan számára is elfogadható nyelvvé alakult át az utóbbi időben.

Drupal vs. nagy látogatottság

Indul, vagy kimondhatjuk hogy már el is indult a zoom.hu portál, mely nem kisebb célt tűzött ki maga elé, mint az Index.hu és Origo.hu oldalakkal felvenni a hírversenyt. Úgy tudom hogy szép nagy szerkesztőséggel, nem kis (de nem is olyan nagy mint amiről eddig szó esett) pénzzel vágtak bele a dologba. Szerkesztőségi rendszernek Drupalt választottak, amit eddigi tapasztalataim és a magyar Drupalos/rendszergazdai ismereteket ismerve rossz választásnak tartok. Nem azért, mert a Drupal rossz lenne, hanem mert már a mostani indulásból is az látszik, hogy nem tudják hogyan kell üzemeltetni egy ekkora oldalt.

Zoom.hu

Drupal alapú portált üzemeltettem már jómagam is: a Weblabor és a Drupal.hu is volt már a szervereimen. A Weblabor magában kb. 5000 napi látogató kb. 10.000 oldalletöltésének a kiszolgálását jelentette. Kezdetben ez egy szerverrel volt megoldva, majd a későbbiekben két szerverre lett szétrobbantva a dolog (webszerver és adatbázisszerver), de összességében így is kb. 1 szervernyi erőforrást vitt el a kiszolgálás. A Zoom.hu az Index és az Origo nagyságrendű látogatottságot célozza meg, az Index esetén ez 850.000 látogatás 3.200.000 oldalletöltését, az Origo esetén pedig ennek kb. háromszorosát jelenti. Nagyon durva és buta egyszerűsítéssel ez 32-100 szervert jelent. Ezzel a számítással két gond van, az egyik hogy az alap Drupal kód amit látni lehet az oldal mögött az nem többszerveres környezetre van tervezve így nem skálázható automatikusan ilyen megoldásban, másrészt pedig hogy azért lehet optimalizálni a Drupal üzemeltetésén is, ha valaki ért hozzá. Így is nem kicsi pénzkidobásnak tűnik első ránézésre a dolog.

A hazai Drupal közösségben vannak olyan emberek, akik láttak már hasonló méretű oldalakat kiszolgáló szerver környezetet (hasonló a véleményük mint az enyém), jómagam is ismerem mind a Netvibes, mind pedig hazai vonalról például a Nemzeti Sport Online, vagy a Blikk oldalainak mögött levő architektúrát, illetve azokat a kódokat és megoldásokat, melyek az ilyen környezetekben életképesek tudnak lenni. A Drupal kódját ismerve egy az egyben biztosan nem alkalmas erre a működésre: üzemeltetési szinten nincsen tartalom publikálási folyamat, az újságírók az éles adatbázissal dolgoznak (nem az van, hogy megírják a cikket, majd az kikerül az éles szerverekre), a felhasználók sokáig be vannak léptetve és ez a működtetés nincsen különválasztva az oldal kiszolgálástól, ergo a belépett felhasználók számára a személyre szabott oldalt kell kitenni, továbbá alapból nincsen megoldás a statikus tartalmak külön erre optimalizált szervereken történő hosztolására (átszinkronizálására) sem. És számos ilyen jellegű kisebb-nagyobb probléma van a Drupal kódjával, melyekről tudom hogy megkerülhetőek, de azt is, hogy akik meg tudják kerülni, azok profi Drupal szakemberek (nem olyanok, mint én :) . A szép nagy látogatottságú Drupal.org vagy SpreadFirefox is Drupal alapokon fut – tehát a feladat semmiképpen sem lehetetlen, csak nem egyszerű. A felsorolt gondok közül pár megoldása nem lesz elegendő, egy jól használható rendszerhez még ezen problémák megoldásánál is több kell (van már szerkesztőségi tapasztalatom is Magyarország.hu és kisebb oldalak kapcsán).

A Zoom.hu üzemeltetői és fejlesztői több hibát is elkövettek, melyek azt mutatják számomra hogy a kellő üzemeltetési tapasztalattal nem rendelkeznek. Nagy hiba például a címlapra kihelyezett szavazás, mert ez azt jelenti, hogy a belépett, már szavazott felhasználóknak más tartalmat kell kiszolgálni, mint amit a nem belépett, vagy még nem szavazott felhasználóknak. Persze így is van cache a dolog mögött, de az ideális az lenne ha a címlapot boldog-boldogtalan mindenféle PHP közreműködés és testreszabás nélkül kapná meg. Kb. tizednyi architektúra kellene. Az olyan alapvető és statikus tartalmak kiszolgálására optimalizált szerverekért ordító dolgok, mint a JavaScript és CSS fájlok, logó kiszolgálása is a Drupal-t futtató szerverről van kiszolgálva, az oldalak tartalmának cache-elése teljességgel le van tiltva, arról nem is beszélve, hogy 17 CSS és 15 feletti JavaScript fájl töltődik le külön-külön, ami még ha már böngésző cache-ből szolgálódik is ki, kb. 30 felesleges, darabonként kb. tized/huszad másodpercnyi (összességében másodpercek!) extra várakozást és szerver terhelést jelent.

A design egyébként alapvetően nem rossz, de a logó még ha ötletes is, alapvető problémákkal küzd (a fejléc billeg a megemelt M betű miatt). A kategóriákat kiemelő túl hangsúlyos sávnak funkcionalitása nem nagyon van. A rovatoldalakon lehetne még bőven csiszolni, helypazarlóak és kiegyensúlyozatlanok. Van egyébként egy kis Indexes designbeli utánérzés, de az alap Drupal design is egész jó, így lehet, hogy ezek a design elemek részben onnan származnak.

A tartalom fő váza teljesen ígéretes, de például a kevésbé fővonalnak számító sport és IT/tudomány rovarok egyelőre nem túl erősek – ezeket illetően valamilyen erősítés nem ártana, ha tényleg az Index és Origo vonal a cél. A blogok bevonása az oldalba még nem tökéletes: a gond az hogy nagyon el lettek dugva az egyes blogok, és hogy nem képeznek különálló egészet. Szerencsésebb lenne egy önálló, erre a célra optimalizált blogrendszer használata, mely mind megjelenésükben elkülönítenék egy kicsit az oldaltól a blogokat, mind pedig jobban ki tudná szolgálni a blogoktól elvárt igényeket. Az Index nagyon-nagyon erős ezen a vonalon, és mivel úgy gondolom hogy ez egy hangsúlyos irány a jövőt illetően, ezért valószínűleg ezen is jó lenne változtatni, ha komolyan gondolja a főszerkesztő a dolgot.

Összefoglalva: az üzemeltetési/fejlesztési vonal szerintem fájdalmas és nagyon kátyús lesz, a tartalmi vonal az indulásnak megfelelő és jó irány lehet. Akarva-akaratlanul az az ember érzése, hogy a fejlesztői csoport nem volt jó választás, ekkora tőkével és célokkal illett volna egy erre méltó, ilyen jellegű referenciákkal rendelkező céget választani, mely már megtapasztalt ekkora látogatottságot és megoldott nagy rendelkezésre állást is.

Webalkalmazások hosztingja

Alkalmazásaink hosztingját illetően ma több választás is áll előttünk. Hazai hoszting szolgáltatók, külföldi hoszting szolgáltatók, és újabban az Amazon és Google ezirányú szolgáltatásai csábítanak. A konkrét döntés jelentősen befolyásolhatják az adott hosztolni kívánt alkalmazás kívánalmai, de megpróbálom röviden összefoglalni ezirányú véleményemet a Google ezen a piacon történő megjelenése kapcsán. Mivel jómagam is egy hoszting céget vezettem több éven át (már nem), úgy érzem hogy elég jó rálátásom van a helyzetre.

Hazai hoszting szolgáltatók

A legalja valahol havi 500 Ft – 1000 Ft környékén kezdődik, ezek azok a szolgáltatók, akikkel nem érdemes szóba állni, ha valaki komolyan veszi magát. Ezen az áron a magyar piacon nem lehet minőségi szolgáltatást nyújtani – aki ezen az áron nyújt szolgáltatást, az vagy “egyetemista” viszonylag kevés tapasztalattal hoszting terén, vagy nagyban űzi, de ekkor is nagyon minimálisan nyújt. A többéves ezirányú tapasztalatom azt mutatja, hogy ha mázlista valaki, csak akkor nem lesz gondja, hosszabb (akár több napos) leállások, félrekonfigurálások, elérhetetlen szerverek és ügyfélszolgálatok jellemzőek erre a körre. Nincs, vagy minimális szintű backup van kínálva, kiesés esetén még ha visszafizetik is a havidíjat (előfordul hogy a szerződésben arányos visszafizetés szerepel – fél havi leállásnál 250 – 500 Ft visszafizetése elég komolytalan) akkor sem igazán vagyunk kárpótolva a kiesésekért. A jellemző tárhely 1-2 GB.

A minőségi szolgáltatók havi 5000 – 10.000 Ft környékén kezdődnek, itt már elérhető és barátságos ügyfélszolgálatra, segítőkész rendszergazdákra is számíthatunk. Ezen az áron se gondoljunk azonban csúcsszolgáltatásra, kiesés itt is előfordulhat, még ha azt már igyekeznek megelőzni a szolgáltatók jó minőségű hardver beállításával. Komolyabb környezet kialakítása (magas rendelkezésre állás, több szerveres környezet) itt sem igazán megoldható. A jellemző tárhely 1-10 GB.

Igazán komoly szolgáltatást akkor éri meg vásárolni, ha komoly üzletről van szó, itt már számunkra dedikált szervereket kapunk, a minimum itt olyan 50.000 Ft lehet, de a határ a csillagos ég (egy szerver elhelyezése BIX-re kötve 15000 – 20000 Ft, magas rendelkezésre álláshoz nem árt 3-4 szerver is, nem beszélve a backupokról, és a rendszergazdák költségeiről). Ezen a szinten jól képzett rendszergazdákat és rendszerünk felépítéséhez tanácsadást is kapunk, kaphatunk. A tárhely mérete a csillagos ég.

Természetesen azért, mert valaki elkér 3.000.000 Ft-ot egy szolgáltatásért havonta, nem feltétlenül lesz az jobb, mint ha a havi 500 Ft-osat vásárolnánk meg – nézzünk utána a referenciáknak.

Külföldi hoszting szolgáltatók

A külföldi hoszting szolgáltatókat illetően már viszonylag kisebb tapasztalatom van. Ezeknél a szolgáltatóknál is megvannak a különböző szintek, külföldi szolgáltató elérése ha baj van, akkor komoly nehézségekbe ütközhet (vagy drága lesz a nemzetközi telefonköltségek miatt). A fizetés jellemzően bankkártyával történik, és az itthon elterjedt elektronikus bankkártyákat nem, csak a dombornyomottakat fogadják el. Kérték már azt is, hogy küldjek személyi azonosítóról fotót, vagy szkennelt képet. A szerverek mivel a tengeren túlon vannak, jellemzően egy nagyon kicsit lassabbak lesznek, vagy kisebb adatforgalmat fognak tudni lebonyolítani, mint hazai társaik.

Minőségi, de backup nélküli szolgáltatást amerikából kaphatunk havi 1000 – 2000 Ft összegért, s ebben akár TB szintű tárhely is benne foglaltatik, azonban biztosan limitált az adatforgalom mennyisége (mondjuk a tárhely tízszerese, jellemzően átlag használatra teljességgel elfogadható). Speciális szerver beállításokra, egyedi igények megoldására ne számítsunk, bár lehet, hogy részben – ha értünk hozzá – pár dolgot meg fogunk tudni csinálni.

Ennél jobb, de nem sokkal drágább szolgáltatásról, ahol már backupot és nagy rendelkezésre állást is garantálnak, nincsenek tapasztalataim. Komoly (de még 1 szerverből álló) szolgáltatásra kértem már árajánlatot, ez jellemzően drágábbra jött ki, mint egy hazai megoldás.

Amazon

Az Amazon nemrégiben kezdte el nyújtani speciális, nagy rendelkezésre állású környezetét, az Amazon EC2-t. A szolgáltatás igénybevétele igényel rendszergazdai ismereteket, ha már előre összerakott megoldást választunk, akkor is. Kis forgalomnál inkább egy minőségi külföldi vagy hazai szolgáltató választás éri meg, nagyobb forgalomnál el lehet gondolkodni az igénybe vételén. Bár az EC2 a SimpleDB-vel kínál adatbázis szerver jellegű megoldást, ez kicsit túl butára sikerült, nem igazán alkalmas komolyabb feladatokra. Ez persze még bőven fejlődhet.

Statikus adatok tárolására (akár képekről, akár személyes backupunkról beszélünk) mindazonáltal kiváló megoldást nyújthat az EC2, ahogyan a Twitter is az Amazon szolgáltatását veszi igénybe erre a célra a profilképek kiszolgálásához.

Google

A Google pár hete jelentette be a Google Apps Engine-t, mely egészen más a korábbiakhoz képest. Jelenleg Python nyelven lehet alkalmazásokat írni, és egy konkrét alkalmazáskönyvtár ár rendelkezésünkre. Kapunk adatbázis szerver megoldást is, mely a Google saját megoldására épít. A Google Apps Engine minden üzemeltetési feladatot levesz a vállunkról, teljesen elrejtve előlünk a konkrét környezetet, ahol az alkalmazásunk futni fog. Szinte egyáltalán nem kell foglalkoznunk a látogatók számának növekedésével sem, a rendszer megoldja a háttérben a skálázást is.

A megoldás nagyon jól hangzik, de vannak gondok is vele. Míg a lehetőségeink nagyon jók, gyakorlatilag a Google-hoz kötjük az alkalmazásunkat ha ezt a környezetet választjuk. Direkt ehhez igazodóan kell leprogramozni a feladatot, és nem fogunk tudni költözni, nincsen hosztoló cég alternatíva. Erős kötöttséget jelent még a Python programozási nyelv is, hiszen itt csak ezen tudunk programozni – kevés a magyar Python programozó, illetve a kész megoldások hiánya (nincsenek kész alkalmazások, ebbe a környezetbe készült alkalmazáskönyvtárak, stb.). Végül az adatbázis megoldás is bizonyos kötöttségekkel bír, egy lekérdezés futásának az ideje limitált, így például backupot is nehezen lehet készíteni, mert egy teljes lekérdezés túl hosszú ideig tartana, és le lesz lőve, mielőtt bármit kiköpne magából.

Várhatóan lesznek törekvések alternatív hoszting környezet kialakítására szabad forráskódú eszközök használatával, a programozási nyelvek körét is bevallottan bővíteni fogja a Google. Az alkalmazáskönyvtárak, kész kisebb alkalmazások szintén biztosan kialakulnak majd, melyek a praktikus és gyors fejlesztést is lehetővé fogják tenni.

Összefoglalás

Az elkövetkező években a “hagyományos” hoszting mellett várhatóan komoly részt fognak kihasítani az Amazon és Google féle megoldások, de ezek még érezhetően nem “tökéletesek”, és jóval több és rugalmasabb lehetőségünk van, ha még nem döntünk a használatuk mellett. Ezzel együtt akár a részben átállás (ahogy a Twitter teszi), akkor csak a kipróbálásuk/ismerkedés egy olyan feladat, amit nem szabad kihagynia egy webfejlesztőnek, ha haladni szeretne a korral.

MySQL vs. PostgreSQL I.

A PostgreSQL-lel való megismerkedés – a MySQL szuper propagandájának köszönhetően :) – kimaradt az életemből, illetve az utóbbi évek alatt nagyon sok ponton fejlődött. Most egy projekt kapcsán elkezdtem ismerkedni vele, az ezirányú tapasztalataimat fogom most és további bejegyzésekben megosztani. A cél nem egy teljes bemutatás, hanem azoknak a hasonlóságoknak, különbözőségeknek a megmutatása, melyekkel találkoztam.

A MacOSX-re történő PostgreSQL telepítés nem túl bonyolult folyamatát már bemutattam másik blogomon, két témára térnék ki most, az egyik a típusok, a másik pedig a dátumkezelés. Értelemszerűen és nyilvánvalóan – mivel mind a két rendszer az SQL szabvány felé próbál minél jobban közelíteni, hatalmas különbségek nincsenek az SQL parancsokat illetően. Megvannak azonban mind a két rendszerben olyan elemek is valósítva, melyek nem szabványosak, és ezek bár hasonlóak, egyáltalán, vagy nem teljesen egyezőek.

Típusok, adatbázis tábla létrehozása

Míg a PostgreSQL alatt részben használhatjuk a MySQL-ben megszokott típus elnevezéseket, az adat típusok elnevezését illetően mind filozófiabeli, mind pedig konkrét elnevezésbeli különbségek adódnak. Az INT, VARCHAR(200), DATE, TIME, TEXT típusok – legalábbis elnevezésükben – megegyeznek (bár a TEXT a MySQL beli LONGTEXT méretű szöveg tárolását teszi lehetővé). Konkrétumokat illetően azonban mindenképpen érdemes a két rendszer ezirányú dokumenticáióját átolvasni: MySQL adattípusok, PostgreSQL adattípusok.

Az AUTO_INCREMENT tulajdonsággal mező a MySQL újítása, PostgreSQL alatt nem áll rendelkezésre (és a szabványban sincs ilyen). Van azonban mind a két rendszerben olyan típus, mely kiváltja, mégpedig a SERIAL. MySQL-ben ez egy alias a ”BIGINT UNSIGNED NOT NULL AUTO_INCREMENT UNIQUE” típus és tulajdonságlistára, míg PostgreSQL alatt egy szekvenciát hoz létre (mely egy olyan eleme az adatbázisnak, melyből folyamatosan növekvő elemek kérdezhetőek le), és rendeli hozzá az alapvetően INTEGER típusú oszlophoz.

A BLOB típus szintén MySQL sajátosság, PostgreSQL alatt a BYTEA a megfelelője (szabványban nincsen rá külön megfelelő). Míg MySQL-ben direktben hozhatunk létre ENUM (felsorolás) típusú oszlopot, PostgreSQL alatt vagy deklrálni kell egy ENUM típust, vagy pedig a szabványos megkötésekkel lehet szimulálni: mezőnév VARCHAR(255) NOT NULL, CHECK (mezőnév IN (”érték1″, “érték2″, “érték3″…)). A TIMESTAMP típus viselkedése MySQL alatt is függ attól, hogy az adatbázisszerver milyen kompatibilitási módban fut. A jellemző viselkedés mindazonáltal az, hogy ez a mező automatikusan frissítésre kerül az éppen aktuális időponttal ha az adott sort változtatjuk (és ez az első TIMESTAMP típusú oszlop az adott táblában). PostgreSQL esetén DATETIME mezőként viselkedik a TIMESTAMP, azaz semmilyen értékkel nem töltődik ki automatikusan. PostgreSQL alatt hasonló funkcionalitás triggerekkel érhető el.

A fentiek alapján levonható a következtetés, miszerint egyszerű táblákat MySQL-t ismerők is könnyen létrehozhatnak, de komolyabb munkánál mindenképpen áttekintendő a PostgreSQL dokumentációja.

Dátum kezelés

A MySQL kellemes funkciólistával rendelkezik, ha a dátum (és idő) manipulációról van szó. Ez a PostgreSQL-ről is elmondható, nem kell panaszkodnia a dátum manipulációs függvényeit illetően. Az ismerkedés kapcsán két funkciót néztem meg, és ezeket emelném ki, mint egy példát a hasonlóságra, és egy példát a különbözőségre.

MySQL alatt az aktuális időpont a NOW() függvény segítségével kérdezhető le, de ez az érték elérhető a szabványos CURRENT_TIMESTAMP kifejezéssel, vagy a már nem annyira szabványos CURRENT_TIMESTAMP() függvénnyel. PostgreSQL alatt hasonló a helyzet, a NOW() és az SQL szabvány CURRENT_TIMESTAMP használható.

Ha egy adott dátumtól bizonyos távolságra levő dátumra vagyunk kiváncsiak, akkor mind a két adatbáziskezelő alatt az INTERVAL kifejezés jöhet szóba, azonban ezek eltérően paraméterezendőek. MySQL alatt például a SELECT now() + INTERVAL 2 day formátum a használandó, PostgreSQL alatt a SELECT now() + INTERVAL ‘2 days’ forma a nyerő. PostgreSQL alatt aposztrófok közé kell tenni az intervallumot leíró kifejezést, és az egyes számot-többes számot illetően megengedőbb (a helytelen 1 days és 2 day is működik), míg MySQL alatt nem lehet aposztróf, és csakis az egyes szám a megengedett.

Összefoglalás

Ismerkedésem kapcsán tervezem további “kalandjaim” megosztását is egyéb területek kapcsán – akármennyire is mind a két rendszer a szabvány SQL-hez próbál meg közelíteni, mint láthatjuk nem kis különbségek vannak. Az mindenesetre elmondható, hogy a PostgreSQL-ben jellemzően több lehetőségünk van, mint a MySQL-ben, még ha nem is mindig lesz könnyebb a helyzetünk ezzel (gondolok itt az ENUM vagy a TIMESTAMP mezőtípusokra).

MySQL Maria

A MySQL háza tájáról a Sun általi felvásárlás volt az utóbbi időben a leghangosabb, azonban a fejlesztés ezzel párhuzamosan nem állt meg, sőt. Az akvizíció rövid távon biztosan nem érinti a MySQL-t semmilyen módon, és egyelőre semmi jel nem utal arra sem, hogy hosszú távon kár érné az adatbázismotor használóit. Ebben a blogbejegyzésben azonban nem erről, hanem az egyik új fejlesztésről: a MyISAM táblatípus utódjának szánt Maria-ról lesz szó.

MySQL

A MySQL több fajta táblatípus használatát teszi lehetővé párhuzamosan egy adatbázisszerveren, egy adatbázison belül, táblázatonként. A MySQL alapértelmezett táblatípusa a MyISAM, de többnyire ismert még az InnoDB táblatípus is (és van még pár: MyISAM Merge, Memory/HEAP, Cluster, Archive és Federated – talán egyet sem hagytam ki). Mindegyik táblatípus más felhasználási területen tud optimális teljesítményt nyújtani – a éppen aktuális felhasználási módnak megfelelőt kiválasztva hozhatjuk ki a leghatékonyabb megoldást. Több aktívan fejlesztett táblatípus is ismert, ilyen a Falcon és a MyISAM utód Maria.

A Maria táblatípus gyakorlatilag a MyISAM továbbfejlesztése, kezdetnek két újdonsággal (és pár kötöttséggel): opcionálisan “crash safe” táblák, illetve sor alapú gyorsítótárazás. Az előbbi magyarra lefordítva annyit jelent, hogy ha a tábla módosítása során a szerver lefagy, a tábla nem sérül (kijavítja önmagát), míg az utóbbi a teljesítményt javíthatja jellemzően átmeneti lemezre írt táblák esetén (amikor nem fér be egy JOIN miatt összeálló a átmenetileg létrejövő tábla a memóriába). Nagy csodáról tehát nincsen szó, ezek a változások azonban megbízhatóbbá, és gyorsabbá tehetik majd a jövőben a MyISAM táblákat.

Az egy hete megesett bejelentésben nem esik szó róla, hogy mikorra készül el a végleges változat, eddig – főleg részmunkaidőben végzett – 2 év munkája áll a projektben. A jelenlegi verzió már letölthető és kipróbálható, annyit lehet róla tudni, hogy működik, s hogy a teljesítménye jónak mondható jelenlegi állapotához képest. A projektet egyébként Michael “Monty” Widenius vezeti, aki a MySQL egyik alapítótagja, és a MyISAM motor is nevéhez fűződik. S hogy miért pont Maria?

Monty, the creator of MySQL, named MySQL after his first child ‘My’. His second child, Max, gave his name to MaxDB and the MySQL-Max distributions. His third and youngest child is named Maria…

Netvibes Ginger bétázás

Jópár visszajelzést kaptam a Gingerrel kapcsolatosan, az ezekkel kapcsolatos gondolataimat megosztanám egy kicsit. Szó fog esni egy kis architektúráról (nem, nem fogom leírni, hogy milyen van a Netvibes mögött, mert köt a titoktartási szerződés, de olyan dolgokat szívesen összefoglalok, melyek kikövetkeztethetőek), arról, hogy mi történik, történt az átálláskor, hogy miért van bétázás, s hogy miért fordulhatott elő, hogy egy kicsit ma belassult az oldal és korrekcióra volt szükség.

Netvibes Ginger

Mindenekelőtt fontos látni, hogy jelenleg két Netvibes rendszer fut egyszerre, a régebbi Coriander változat, és az újabb Ginger, és hogy mit kapunk, az attól függ hogy milyen felhasználóval vagyunk bejelentkezve. A két rendszer nagyon sok ponton tér el egymástól, a különböző függvénykönyvtár (pl. Mootools) verzióktól kezdve a szerverrel történő kommunikációig, nem hiába: a Ginger mögött jópár hónap fejlesztés van, és közben nem henyélt egyik fejlesztő sem. Ennek megoldása elvileg nem nehéz, gyakorlatilag sok apróság miatt nem a triviális kategória, és a fejlesztés nem kis körültekintést kívánt. Alapvetően amit látni is lehet a rendszerből az annyi, hogy bejelentkezéskor egy cookie kerül beállításra, és a terheléselosztó rendszer ez alapján tudja, hogy melyik szerverhez küldje a kéréseket. A ki-be jelentkezést és egyéb folyamatokat persze jól le kell zsírozni.

A Gingerhez új szerverek kerültek beállításra, de a Ginger hatása korántsem csak az új szerverekre korlátozódik, ezért az üzemeltetésnek jelentősen megnövekedett aktivitásra kellett számítania – ekkorára mint ami most volt, mégsem számítottunk, az átállás kiemelkedően jól sikerült. Az egyik architektúrális dolog mely számít, hogy a Ginger az ecosystemet is használja és terheli, hiszen tartalom hozzáadáskor immár nem saját adatbázist, hanem az ecosystemét használja, a Gingerben hozzáadandó widgeteket keresők valójában az ecosystemen keresnek, stb. Másrészt a Ginger átállás marketingje a Netvibes teljes látogatottságát, használatát is megdobta, olyanok is az oldalra látogattak, akik egyébként nem lettek migrálva, azok is ránéztek korábbi oldalukra, akik már nem használják azt, és jöttek új felhasználók is persze, nem is kevés.

Harmadrészt az új funkciók (barátok, aktivitás) alapvetően adatbázis terhelőbbek, mint a régi felállás, ahol gyakorlatilag felhasználónként teljesen szeparált adatokról beszélhettünk. Negyedrészt, hogy soroljam még az indokokat, a Ginger felhasználók (akik early adopters, erősen tech réteg) most rárobbantak az oldalra, jelentősen nagyobb látogatottságot produkálva, mint ami jellemző a Netvibes-on, és mint ami jellemző lesz rájuk – egyszerűen végigpróbálták a funkciókat, kommunikáltak egymással, létrehozták, összerakosgatták univerzumukat.

Végül, de nem utolsó sorban: a meghívásos bétázást olyan marketinges, webkettes herce-hurcának szokták tartani az emberek, alapvetően azonban az üzemeltetés szempontjából nagyon is praktikus kérdés. A felhasználók egy kis csoportjának átállítása lehetővé teszi, hogy valódi felhasználói aktivitás mellett, de kisebb körben, kevesebb befektetéssel, az esetleges problémákat csak a felhasználók egy részére korlátozva felmérjék, hogy a rendszer hogyan muzsikál, hol kell rajta hangolni. A felmerülő hibák sokkal nyugodtabban javíthatóak, esetlegesen valamilyen nem várt, de nagy probléma esetén vissza lehet térni az előző verzióra. S ezekkel együtt persze marketingről is szó van. Lehet növelni az érdeklődést, a béta rendszert használók számára jó érzés, hogy az új funkciókhoz előbb hozzáférhetnek, mint a többség, s ráadásul a körülmények hatására toleránsabbak is a hibákkal szemben, mint általában.

A bétázás egy lehetőség a Netvibesnak, hogy stabilan történhessen meg a Gingerre a végleges átállás a közeljövőben. A Ginger kiemelkedően kedvező fogadtatásra talált. A helyzettel azonban – és ez igaz bármelyik “béta” címkéjű oldalra – nem szabad, s nem célszerű visszaélni. A teljes csapat erősen dolgozik is azon, hogy a felmerülő hibák javításra kerüljenek, s hogy a Netvibes továbbra is megbízhatóan, stabilan működjön.