Előző alkalommal egy saját fordítású, de különböző népszerű, finomhangolásokat lehetővé tevő patcheket nem tartalmazó MySQL 5.5.9 community edition, illetve egy gyári beállításokkal indított MongoDB 1.6.5 voltak a tesztalanyok. Most egy Percona Server 5.5.8 (béta), és egy MariaDB 5.2.4 disztribúció bővítette a kört. Ezek a disztribúciók alapvetően bináris kompatibilitást ígérve alapból sokkal jobban hangolt, illetve még jobban hangolható változatát ígérik az eredeti MySQL disztribúciónak. A bináris kompatibilitás azt jelenti, hogy a diszken tárolt adatbázisunk felett konverzió elvégzése nélkül kicserélhetjük az adatbázisszervert. Ezek a gyakorlatban nagyon jól is működtek, az egyes adatbázisszerverek által előállított fájlok egy-az-egyben meg is egyeztek.

Az InnoDB-vel végzett tesztjeim kapcsán kaptam több irányból is visszajelzést, hogy ennél jobbnak kellene lennie az eredményeimnek. Alapvetően gyári beállításokkal futtattam, a konfigurációba nem nyúltam bele, emiatt erre számítottam is, de utánaolvastam a témának, és a végeredmény végül erősen meglepett, az InnoDB hozta a MyISAM sebességét. Ezen kívül a MongoDB kapcsán végeztem még el egy változtatást, miszerint egy extra paraméterrel indítottam, mely csökkentette az I/O-t, és tovább gyorsította az importálás sebességét, még szimpatikusabbá téve a MongoDB szolgáltatásait.

Először álljanak itt a friss eredmények, majd pedig írok arról, hogy pontosan milyen változtatásokat eszközöltem a konfigurációkon. Az adatok és a felállás teljesen megegyezik a korábbi bejegyzésben írottakkal, egy korrekt, más feladatot el nem látó, terhelést nem kapó szerverrel végeztem a méréseket. Az adatfájlok méretét itt nem részletezem, a korábbi bejegyzéshez képest nem változtak. A referencia sebesség, csak az XML feldolgozása továbbra is 2:28 körüli érték.

MySQL Community Server 5.5.9, saját fordítás, extra configure paraméterek nélkül

• MyISAM tábla, tömörítés nélkül: 5:32
• MyISAM tábla, PHP oldalon gzdeflate-tel: 6:17
• InnoDB tábla, tömörítés nélkül: 5:24
• InnoDB tábla, PHP oldalon gzdeflate-tel: 6:15
• InnoDB tábla, ROW_FORMAT=COMPRESSED-del: 7:56

Az InnoDB tábláknál a többi MySQL disztribúcióhoz képest a konfiguráción változtatnom kellett, nem engedett akkora logfájl méretet, mint a többi megoldás.

Percona Server 5.5.8, béta változat, bináris 64 bites Linuxos disztribúció

• MyISAM tábla, tömörítés nélkül: 4:54
• MyISAM tábla, PHP oldalon gzdeflate-tel: 6:17
• XtraDB tábla, tömörítés nélkül: 5:14
• XtraDB tábla, PHP oldalon gzdeflate-tel: 6:29
• XtraDB tábla, ROW_FORMAT=COMPRESSED-del: 8:03

Az XtraDB engine egy InnoDB fork, olyannyira, hogy a CREATE TABLE során az ENGINE megadásakor így kell rá hivatkozni.

MariaDB 5.2.4, bináris 64 bites Linuxos disztribúció

• Aria, tömörítés nélkül: 7:54
• Aria, PHP oldalon gzdeflate-tel: 8:00
• MyISAM, tömörítés nélkül: 5:31
• MyISAM, PHP oldalon gzdeflate-tel: 6:12
• XtraDB, tömörítés nélkül: 6:25
• XtraDB, PHP oldalon gzdeflate-tel: 6:16
• PXBT, tömörítés nélkül: 8:23
• PXBT, PHP oldalon gzdeflate-tel: 8:16

Az Aria engine egy MyISAM fork, komolyabb eltérésekkel, például ACID műveletekkel. A PXBT egy a PrimeBase cég által fejlesztett, szintén ACID megoldás. Az Aria és a PXBT finomhangolásának erőforrások hiányában NEM jártam utána.

MongoDB 1.6.5, bináris 64 bites Linux disztribúció

• tömörítés nélkül: 3:01
• PHP oldal gzdeflate-tel: 4:47

MongoDB 1.8.0 RC0, bináris 64 bites Linux disztribúció

• tömörítés nélkül: 3:02
• PHP oldal gzdeflate-tel: 4:46

Kipróbáltam a fejlesztői változatot is.

Optimalizációk

A MyISAM tuningolásakor a key_buffer, a key_buffer_size és thread_concurrency értékek voltak, melyek leginkább befolyásolták a sebességet. A végleges beállítások:

key_buffer              = 16M
key_buffer_size         = 384M
max_allowed_packet      = 16M
table_open_cache        = 512
sort_buffer_size        = 2M
read_buffer_size        = 2M
read_rnd_buffer_size    = 8M
myisam_sort_buffer_size = 64M
thread_stack            = 192K
thread_cache_size       = 8
query_cache_limit       = 1M
query_cache_size        = 32M
thread_concurrency      = 8

Az InnoDB/XtraDB esetén a sebességben a legjelentősebb változást az alapértelmezett innodb_buffer_pool_size korrekt, illetve az innodb_log_file_size és innodb_log_buffer_size paraméterek hangolásával sikerült elérni. A rendelkezésre álló memóriához, illetve az adatbázis méretéhez képest nagyobbra állítással értem el a kedvező sebességeket. Végül az alábbi paramétereknél maradtam (az utolsó két megoldás az InnoDB ACID mivoltát torpedózza meg, ezzel sebességnövekedést elérve):

innodb_file_per_table
innodb_file_format      = Barracuda
innodb_buffer_pool_size = 8G
innodb_additional_mem_pool_size = 20M
innodb_log_file_size    = 2G
innodb_log_buffer_size  = 512M
innodb_flush_log_at_trx_commit = 0
innodb_flush_method     = O_DIRECT

A MongoDB esetében egyetlen változtatást eszközöltem, parancssorban a –syncdelay 1000 átadásával. Ez a bufferek kiírási gyakoriságát csökkentette 1000 másodpercre, mely több volt, mint az írások futási ideje.

Összefoglalás

Mint látható, a korábbi méréseimhez képest sikerült az InnoDB sebességét a MyISAM motoréhoz hasonló sebességűre hoznom, sőt, volt olyan felállás is, ahol az InnoDB-ből jobb eredményt tudtam kihozni, mint a MyISAM-ból. A Percona Server bizonyult a legjobban optimalizáltnak, hiszen ugyanazon szerverbeállításokkal a MyISAM táblákból jelentősen jobb, az InnoDB (XtraDB) táblákból pedig a többi adatbázis disztribúcióhoz képest megegyező sebességet tudott kihozni. A MongoDB-t tovább sikerült gyorsítanom, ezzel is megmutatva, hogy az egyik leggyorsabb adatbázismotorok között van, jelentősen lepipálva a MySQL szerverek lehetőségeit. A MongoDB-nél mindenképp, de a többi esetben is elmondható, hogy a sebesség eredményeket a PHP oldali adatfeldolgozás, kitömörítés nagymértékben befolyásolta, sokkal gyorsabb eredmények születtek volna, ha a betöltendő adat egyből rendelkezésre áll.

A méréseim visszahozták a bizalmam az InnoDB táblákba, illetve rámutattak arra, hogy a Percona Server disztribúcióra érdemes lehet átállnom. Ez utóbbiról más forrásokból is pozitívumokat hallottam csak, így ezt várhatóan meglépem. A mérések nem kis időmet vitték el, de az írási sebességek mellett mindenképp szeretnék még egy olvasási tesztet is elvégezni, valamennyire modellezve a végső felállást is, így úgy tűnik, hogy lesz egy harmadik rész is, mely erről fog szólni.

© boogie for ‹Webakadémia /›, 2011. | Permalink | 3 comments | Add to del.icio.us
Post tags:

Feed enhanced by Better Feed from Ozh

A célom annak eldöntése volt, hogy mely az az adattárolási eszköz, melyet kiválaszthatok nagyon-nagy mennyiségű adattárolásához. A legfontosabb szempont számomra az, hogy az adatokat minél gyorsabban letárolhassam, mivel folyamatosan fogok komoly mennyiségű változást átvezetni az adatbázison.

Az adatbázisszerver egy saját fordítású, MySQL 5.5.9-es community edition volt, a MongoDB pedig egy 1.6.5-ös, 64 bites bináris Linuxos verzió. A teszteket Ubuntu Linux alatt végeztem. A MySQL beállításai alapvetően a gyári “huge” alapján voltak belőve, a MongoDB-t nem konfiguráltam. A MySQL konfig releváns sorai:

  key_buffer               = 16M
  key_buffer_size          = 384M
  max_allowed_packet       = 16M
  table_open_cache         = 512
  sort_buffer_size         = 2M
  read_buffer_size         = 2M
  read_rnd_buffer_size     = 8M
  myisam_sort_buffer_size  = 64M
  thread_stack             = 192K
  thread_cache_size        = 8
  query_cache_limit        = 1M
  query_cache_size         = 32M
  thread_concurrency       = 8
  innodb_file_per_table
  innodb_file_format       = Barracuda
  innodb_additional_mem_pool_size = 20M
  innodb_log_buffer_size   = 8M
  innodb_flush_log_at_trx_commit = 1
  innodb_lock_wait_timeout = 50

A teszteléshez a Wikipédia adatbázisát választottam, mind a magyar, mind az angol változat dumpjaival végeztem méréseket, de az angol akkora adatmennyiségnek bizonyult, hogy végülis nem futtattam le mindegyik mérést ezekkel az adatokkal. A magyar Wikipédia dump 336,707,547 byte-nyi bzippel tömörített XML fájl volt 415,111 szócikkel, amit egy rövid PHP kóddal dolgoztam fel, on-the-fly kitömörítéssel, és az adatok egyből történő letárolásával.

Több felállást is vizsgáltam, kipróbáltam az InnoDB transzparens tömörítési lehetőségét (ROW_FORMAT=COMPRESSED), illetve olyan felállást is, amikor a PHP oldalán tömörítettem be a Wikipédia cikkeket, a gzdeflate paranccsal. Az adatbázis id, language és content oszlopokat tartalmazott, ahol az id a cikk címe, a language a nyelve (‘hu’), míg a content a cikk tartalma volt. Egyetlen összetett index volt a táblákon, mely az id és language oszlopokat tartalmazta. A méréseket egy mást egyáltalán nem végző szerveren folytattam le, bőségesen elég memóriával, 7200 rpm-es SATA2 diszkekkel, négymagos Intel Xeon processzorokkal.

A következő mérési eredményeim voltak (táblatípus, tömörítés, időtartam perc:másodperc formában, az adatok helyfoglalása):

• MyISAM tábla, tömörítés nélkül: 5:14, 1,159,562K táblaméret
• MyISAM tábla, PHP oldalon gzdeflate-tel: 6:24, 531,764,518 byte táblaméret
• InnoDB tábla, tömörítés nélkül: 27:58, 2,138,120K táblaméret
• InnoDB tábla, PHP oldalon gzdeflate-tel: 18:14, 1,019,912K táblaméret
• InnoDB tábla, ROW_FORMAT=COMPRESSED-del: 22:42, 978,952K táblaméret
• MongoDB, tömörítés nélkül: 3:31, 4,144,128K táblaméret
• MongoDB, PHP oldalon gzdeflate-tel: 4:25, 2,048,000K táblaméret
• adattárolás nélkül: 2:28

MyISAM esetén az MYI, MYD és FRM fájlokat, InnoDB esetén az IBD és FRM fájlok, míg MongoDB esetén az adatbázishoz köthető .0, .1, .2… fájlok együttes méretét értem táblaméret alatt. Ez utóbbi méret csalóka lehet, mert a MongoDB nagyobb blokkokban foglalja le a tárhelyet az adatbázishoz.

Bármely megoldást is választottam, látszik, hogy az egyben bzippel tömörített, eredeti XML fájl mérete a legkisebb, ez várható is volt. Az InnoDB tárhelyigényét furcsállom, érdekes, hogy a tömörítés nélküli MyISAM volt akkora kb., mint a tömörített InnoDB. Az InnoDB beépített tömörítési lehetősége ami a sebességet illeti eléggé leszerepelt (de méretben sem sokkal jobb egy kliens oldali megoldásnál), továbbra is úgy tűnik, hogy kliens oldalon érdemesebb a tömörítést megoldani. Az InnoDB-nél látszik, hogy a sebesség erősen függ attól, hogy mekkora lesz a végleges táblaméret, a MyISAM tábláknál nem volt ilyen erős az összefüggés, sőt, amikor nem volt tömörítés, a több adatot gyorsabban ki tudta írni a MyISAM, itt már látszott, hogy a tömörítés fogta a sebességet, nem pedig az I/O műveletek.

A MongoDB verte mindegyik másik megoldás sebességben, a tárhely foglalása viszont láthatóan nem olyan optimális, mint egy MyISAM táblának, még talán úgy sem, hogy a lefoglalt blokk nagy része valószínűleg üres volt.

A sebessége miatt az InnoDB-t egyértelműen elvetettem. Míg MyISAM-mal 3-4 óra alatt betölthető volt az angol Wikipédia tartalom, addig az InnoDB-s táblába majd 1 napig tartott a betöltés. Az igen jelentős sebességkülönbség a fenti számokon is látszik. Azt gondolom, hogy a sebességen biztosan lehetne javítani pár konfig beállítás átállításával, de valószínűleg így is csak megközelítené, de nem érné be a MyISAM sebességét. A MongoDB megoldása továbbra is nagyon szimpatikusnak tűnik, a MongoDB vs. MyISAM kapcsán célszerű lenne egy random olvasási tesztet is elvégeznem, hogy korrekten tudjak dönteni.

A mérések csak az írási sebességet vizsgálták, és az írás 1 szálon zajlott, a forrás és a cél adatbázis ugyanazon a diszken volt, bár mind a kettő együttesen is belefért a memóriába, így valószínűleg az operációs rendszer cache-elte a forrást. Mivel ezek viszonylagosan speciálisnak mondhatóak, így mondjuk egy átlagos weblap esetén a működéssel valószínűleg nem összehasonlíthatók.

© admin for ‹Webakadémia /›, 2011. | Permalink | 15 comments | Add to del.icio.us
Post tags:

Feed enhanced by Better Feed from Ozh

A HipHop for PHP a gyakorlatban egy C++ fordító, illetve webszerver funkciót lát el. A Facebook azért fejlesztette ki, mert sem a PHP memóriafoglalásával, sebességével, sem a kódok más nyelvi környezetben felhasználhatóságával, s a kiterjesztések programozhatóságával nem voltak túl elégedettek, másfelől viszont már van egy hatalmas PHP-ben írt kódbázisuk, és a tanulhatósága is jó a nyelvnek.

Érdemes megnézni a prezentációjukat:

Illetve én is megpróbáltam összeszedni, hogy milyen gyakorlati különbségek vannak a HipHop és az eddig megszokott, Zend Engine-es PHP között:

C++-ra fordít

A HipHop a PHP forráskódot egy optimalizált C++ kódra írja át, melyet aztán a G++ fordítóval lehet futtatható kóddá alakítani. A nyelvi elemek, a teljes PHP-ben a programozó számára elérhető kódkörnyezet egy jól optimalizált C++ kódban testesül meg az átírás végére, melynek a PHP kódjához ezután nem sok köze van. Néhány – általában ritkán használt – funkció (legfőképpen a PHP kódból dinamikusan új kód előállítását megcélzóak): eval(), create_function(), a preg_replace “e” kapcsolója be lett áldozva a teljesítmény oltárán, mindazonáltal pár dolog, mint a call_user_func(), dinamikus változók, extract() megmaradtak. A hiányzó függvények miatt pár népszerű framework (konkrétan a Symfony felől hallottam ilyen véleményeket) várhatóan nem fog működni HipHoppal. Kérdés, hogy ki alkalmazkodik majd kihez, mennyit jelent majd a gyakorlatban a HipHop sebességnövekedése, s mennyire lesz kényelmesen használható – ezek majd a kód közzététele, és a lehetőségek pontos megismerése után derülnek ki.

Ami a sebesség növekedést illeti, a Facebook webes forgalmánál 50%-kal kevesebb processzor használatot tapasztaltak ugyanakkora, az API-nál 30%-kal kevesebb processzor használatot dupla forgalom mellett. Ezek nem feltétlenül tűnnek hatalmas számoknak, de ha belegondolunk, hogy több, mint 30.000 szerverük van (2009 októberi adat), akkor mindjárt komoly spórolásról beszélhetünk.

Fejlesztőkörnyezet

A fordítás a kód méretétől függően várhatóan nem tizedmásodperces, másodperces sebességű lesz, így leginkább egy deploy folyamatba lesz beilleszthető. Ez így nehézkes lenne fejlesztés közben, így elkészült egy HPHPi névre hallgató interpreter is, ahol kimarad a fordítgatás, így a fejlesztés könnyebbé válik. Ez a megoldás eval() függvényt is megvalósítja, de a HipHophoz közel áll.

Deployment

A deployment során nem PHP kódot kell a szerverekre eljuttatni, hanem egy darab lefordított, “hatalmas” bináris fájlt. Egy HipHop szerver egy processzként, threadek segítségével fog futni, leállás nélkül lehet új verzióra átállni vele.

PHP kiterjesztések

A Facebook programozók saját bevallásuk szerint jópár PHP kiterjesztést használnak. Nem túl tiszta számomra, hogy pontosan mely kiterjesztések lesznek a HipHoppal is használhatóak, de a fenti prezentációban 100.000 sornyi kiterjesztés függvényről beszélnek, mely a HipHop részét képezi – ezzel gondolom jópár kiterjesztés le van fedve.

Beépített webszerver

A HipHop saját webszerverrel rendelkezik, ami az én meglátásomban hatalmas előnyként jelentkezik, mindazonáltal a hoszting cégek dolgát ezzel sem könnyíti meg. Gondolom a webszerver a statikus fájlok kiszolgálására nincsen felkészítve, illetve nem feltétlenül támogatja a rewrite rule-okat, és más hasonló tipikus általános webszerver funkciókat sem, így várhatóan egy nginx/lighttpd felhúzása proxyként a HipHop elé lehet a legcélszerűbb felállás.

Roadmap

A HipHop PHP jelenleg az 5.2-es PHP verzióval kompatibilis, de szeretnék az 5.3-as verziót mielőbb beérni. További cél az Apache támogatása is.

Kinek jó, kinek nem?

Aki néhány nyílt forrású programot futtat egy hoszting cég szerverén, az várhatóan semmit sem fog profitálni a HipHop megjelenésével, sem a hoszting cégek, sem a nyílt forráskódú projekteket fejlesztők várhatóan nem fognak rövid távon átállni rá. A célcsoport sokkal inkább azok a saját nagyobb projekteket kivitelező fejlesztők, melyek jópár szerverre dolgoznak, API-t fejlesztenek, ahol a PHP kódokra jelentős terhelés jut. Ezekből adódóan a HipHop célja nem a Zend Engine lecserélése, ez egy párhuzamos vonal lesz.

Még több olvasnivaló

Ha valaki egy jó kis tech olvasnivalóra vágyik, akkor ajánlom neki Terry Chay írását, jó sok részletről lehet nála olvasni egy hosszú-hosszú blogbejegyzés keretében.

© admin for ‹Webakadémia /›, 2010. | Permalink | 3 comments | Add to del.icio.us
Post tags:

Feed enhanced by Better Feed from Ozh

Frissítés #1: Íme az előadásom fóliái (kicsit más infókat tartalmaznak, mint az alábbi írás, például azt is, hogy milyen lehetőségek lesznek az 1.1-es, illetve jövőbeli Redisekben:

Először a key-value adatbázisokról lesz szó, majd arról beszélek, hogy milyen gondolatiság van ennek a filozófiának az újbóli fellángolása mögött, és miért is aktuális ez a téma manapság, miért célszerű megismernünk minél több lehetőséget ezirányban. A bejegyzés másik felében pedig a Redis lehetőségeit mutatom be a funkcióitól a backupolási lehetőségekig, s szó lesz majd egy esettanulmány jellegű rész keretében arról is, hogy milyen gondolkodásmóddal tudjuk hatékony módon kihasználni a Redis, illetve a hasonló projektek lehetőségeit.

NoSQL, key-value adatbázisok

Egyre divatosabbnak számít manapság adatbázisok oly módon történő megvalósítása, ahol az SQL lekérdezőnyelv nem játszik szerepet. A NoSQL “mozgalom” mögött az a gondolatiság rejtőzik, hogy minél egyszerűbb eszközökkel, minél terhelhetőbb, skálázható, illetve stabil adattárolást valósítsunk meg. A relációs adatbázisok ugyan nagyon sok problémára választ kínálnak, de ez bonyolultságot hoz, s ebből adódóan vesztik el rugalmasságukat, illetve ez az, ami sebességük kárára is válik. Azzal együtt, hogy a bonyolultságból visszavéve, egyszerű adatbázis sémákkal dolgozva gyors megoldások építhetőek relációs modellben is, vannak olyan céleszközök, melyeket nem lehet csak egy kézlegyintéssel elintézni.

Az igényt a nagy látogatottságú, terhelt webes szolgáltatások, a “cloud” témaköre hozta, ebből az irányból származnak azok az elvárások, melyek például a MySQL egyszerűsítését zászlajára tűző Drizzle projekt születését is lehetővé tették, illetve hoztak képbe, tesznek populárissá olyan technológiákat, melyeknek már régóta birtokában vagyunk, de kevésbé használtuk őket szélesebb körben.
A key-value adatbázis fogalma nem mai találmány, sőt, az egyik legegyszerűbb adatmodellről van szó, melyet az összes programozó ismerhet. A legtöbb modern programozási nyelvben jelen levő hashek, asszociatív tömbök, szótárak ezt az adattárolást valósítják meg. A key-value adattárolás lényege, hogy az adatbázis tartalma úgynevezett kulcsok segítségével hozzáférhető, a kulcsokhoz jellemzően egyszerű adatstruktúrával rendelkező értékeket párosítva. Az adatbázis tartalma semmilyen más módon nem kérdezhető le, alap esetben nem tudunk szűrni, rendezni adatokat, csak és kizárólag a kulcsok jelentik a hozzáférési pontot, melyek segítségével viszont nagyon gyorsan férhetünk hozzá a hozzárendelt információhoz. A képet persze árnyalja, hogy egyes megvalósítások – így az előadásom témáját adó Redis is – ezt kiegészíti különböző irányokban, ezáltal bizonyos feladatokra, problémákra hatékony megoldást kínálva a több szereplőhöz képest.

A key-value reneszánszát könnyű lenne elintézni úgy, hogy csak egy újabb hype-ról van szó, de alapvetően inkább egy tudatosabb, céleszközökkel dolgozó, a nagyobb látogatottságot hatékonyabban kiszolgálni akaró, illetve olyan funkciók megvalósítását lehetővé tenni akaró internet korszakába léptünk, melyekre jó választ ad ez a technológia (többek között). A key-value megoldást használó szerverek pedig gombamódra válnak nyílt forráskódú projektek keretében elérhetővé, így rendkívül olcsó és jól használható megoldást adva a webfejlesztők, szolgáltatás fejlesztők kezébe – azzal együtt, hogy bőven van még mindig olyan terület, ahol a hagyományos relációs modell sokkal jobb, hatékonyabb megoldást kínál.

Redis

Az előadásom címében a Redist memcached gyilkosnak neveztem, mivel számos tekintetben többet nyújt annál úgy, hogy megtartja annak előnyeit is.

A Redis egy key-value adattárolást megvalósító, az adatokat memóriában tároló, de perzisztensen háttértárra írni képes, az értékek tekintetében nem csak egyszerű sztringeket, de összetettebb listákat, halmazokat atomi műveletekkel is támogatottan megvalósító adatbázis, mely replikációra is képes.

Rendkívül dinamikusan fejlődő projektről van szó, mely pár hónap alatt jutott el az 1.0-s kiadásig úgy, hogy már korábban is stabilan használható megoldást kínált. Hamarosan várható az 1.1-es kiadás is, mely további újdonságokkal, lehetőségekkel szolgál. A projekt igen jól dokumentált, számos programozási nyelven érhető el kliens szoftver hozzá.

A key-value adattárolás mivoltát az előzőekben már tisztáztam, de nézzük, hogy a többi funkció mit is jelent. A Redis a memóriában tárolja az összes adatot, amiből egyenesen következik az is, hogy maximum annyi információt tudunk segítségével letárolni, amennyi belefér a szerver memóriájába. Mivel járulékos információk is letárolásra kerülnek, ezért figyelembe kell venni, hogy 1 GB memóriába nem tudunk 1 GB-nyi adatot letárolni, csak kevesebbet. A pontos overhead jelentősen függ attól, hogy milyen adatokkal dolgozunk, a Redis FAQ-jában olvasható példa szerint rossz esetben akár 84%-os veszteséget is jelenthetnek a különböző indexek (ez egy elég elrettentő szám, ennél sokkal jobb százalékok is kihozhatóak, mivel duplikált értékeket képes felismerni a Redis, illetve az értékeket tömöríteni is tudja), persze ez korántsem a jellemző arány, sokkal inkább a 10-20% overhead a jelemző.

A Redis az adatokat képes a háttértárra is kiírni, ezáltal perzisztens adattárolást megvalósítva. Az adatok kiírásának folyamata jól hangolható, megadhatunk intervallumot (pl. 5 percenként), írások számát (pl. minden 10.000 írás) is, de mindezeket vegyesen is be lehet állítani. Adat kiírást kezdeményezni lehet menet közben is bármikor. Az adatok kiírása közben a szerver kiszolgálja a kéréseket, nem áll meg, de a háttértárra kiírt adathalmaz konzisztens marad, s a kiírás kezdeti pillanatának állapotát tartalmazza.

Az összetett adattárolást illetően nem csak sztringek tárolhatóak el a Redis adatbázisában értékként, hanem támogatva vannak a listák és a halmazok is. Ez azt jelenti, hogy listákhoz, halmazokhoz különböző műveletek segítségével atomi módon tudunk például hozzáadni vagy lekérdezni elemeket, s ezekhez különböző parancsokat is kapunk (lásd később). További adatszerkezetek is tervbe vannak véve a Redis következő verziójának megjelenésével.

Ami a replikációt illeti, a Redis több szerver között is fenn tud tartani konzisztens adat állapotot. A replikációhoz szükséges szinkronizálást önállóan, beavatkozás nélkül képes beindítani, illetve fenntartani.

A Redis ezeket a funkciókat nagyon gyorsan képes kivitelezni, másodpercenként százezer feletti írásműveletet, illetve százezerhez közeli olvasási műveletet lehet megvalósítani a segítségével egy átlagos szerveren. Ami a konfigurálást, telepítést illeti, nagyon gyorsan, szinte nulla konfigurációval üzembe állítható a szerver szinte fapados módon, és egyből tesztelhető, kipróbálható. A parancsai egyszerűek, s gyorsan tanulhatóak, s egy kiváló, stabil eszközt ismerhetünk meg egy rövid ismerkedés során.

Hasonló projektek

Ami a memcached-del történő összehasonlítást illeti, az eddig leírtakból talán látható, hogy miben nyújt a Redis többet a Memcached szolgáltatásainál. Legfőképpen az összetett adatszerkezetek, illetve a perzisztens adattárolás lehetnek azok a funkciók, melyek miatt érdemes lehet váltani, de persze az igényektől függ, hogy ez szükséges-e. A Memcached-del szemben a Redis segítségével nem csak cache megoldásokat, hanem akár “igazi” adattárolást is megvalósíthatunk, mely egészen más felhasználási módokat is lehetővé tesz, a Memcached lehetőségeinek megtartása mellett.

Létezik egy MemcacheDB nevű projekt is, mely valójában csak nevében és protokolljában rokon a Memcacheddel, hiszen a netes interfész megvalósítását annak protokolljával kompatibilisen valósították meg, az adattárolása azonban nem a memóriában történik, hanem a BerkleyDB projektet használja erre a célra. Tekintettel arra, hogy írás műveleteknél itt minden alkalommal háttértárra írási művelet valósul meg (az mondjuk nagyon gyorsan), illetve hogy a BDB is csak egyszerű adatszerkezeteket támogat, ezért a Redis ezzel a projekttel szemben is előnyösebb választás lehet.

Támogatott nyelvek

A Redishez rövid pályafutása alatt a közösség jóvoltából (illetve a jól dokumentált protokolljának köszönhetően) számos programozási nyelven készült kliens, illetve további nyelvekhez viszonylag egyszerűen implementálható kliens megvalósítás. Ruby, Python, PHP, Erlang, Tcl, Perl, Lua, Java és Scala nyelvek alkotják a hivatalos listát, az egyetlen hiányzó ismertebb nyelvcsalád a .Net vonal. Egyes nyelvek alá (Ruby, Perl…) nem csak a parancsokat megvalósító, de komplexebb rutinkönyvtárak is rendelkezésre állnak.

Parancsok

A Redis parancsait négy csoportba sorolnám, vannak az alap-, a lista és a halmaz műveleteket megvalósítóak, továbbá az egyéb, legfőképpen adminisztrációs célúak. Persze ez elég önkényes besorolás, a projekt wiki oldalán specifikusabb kategorizálással találkozhatunk. Íme a fontosabb műveletek.

Az alapműveletek közé a következőket sorolnám:

SET kulcs érték: beállít egy új értéket a kulcs kulcshoz
GET kulcs, MGET kulcs1, kulcs2, kulcs3...: egy, illetve több kulcs értéke kérdezhető le
EXISTS kulcs: definiált-e adott kulcsú elem?
INCR kulcs, DECR kulcs: az adott kulcs numerikus értékének növelése, illetve csökkentése 1-gyel
INCRBY kulcs érték, DECRBY kulcs érték: mint az előző, de konkrét értékkel növelés, illetve csökkentés
DEL kulcs: adott kulcsú elem törlése az adatbázisból
KEYS minta: a “minta” mintával kezdődő kulcsok nevének lekérdezése
RANDOMKEY: egy véletlenszerű elem értékének lekérdezése
RENAME régikulcs újkulcs: kulcs átnevezése
EXPIRE kulcs másodperc: az adott kulcshoz lejárati idő társítás

A SET, GET, INCR/DECR műveletek sztring értékű kulcsok esetében használhatóak. Értékadás jellegű műveleteknél, ha egy kulcshoz eddig nem volt érték letárolva, akkor a Redis nem reklamál, hanem létrehozza az adott kulcsot, ez a tapasztalatok alapján így praktikus művelet.

Az EXPIRE művelet viszonylag egyedi módon megvalósított, ugyanis amennyiben egy adott kulcshoz lejárati időt társítunk, legközelebbi olvasást és írást is tartalmazó műveletkor (például INCR) a korábbi érték megsemmisül, avagy hiába nem járt még le a kulcs, de nulla értékről indul ezeknél a műveleteknél. Ez a replikáció konzisztensen tartása  miatt működik így.

A listaműveletek közé az alábbiak sorolhatóak:

RPUSH kulcs érték, LPUSH kulcs érték: az adott kulcsú listába új elemet szúr érték értékkel, jobb oldalra, illetve bal oldalra
LLEN kulcs: lista hosszának lekérdezése
LRANGE kulcs kezdet vég: lista egy adott szakaszának lekérdezése
LTRIM kulcs kezdet vég: lista csonkolása csak a megadott szakasz megtartásával
LINDEX kulcs index: adott indexű elem lekérdezése a listából
LSET kulcs index: adott indexű elem értékének módosítása a listában
LREM kulcs darab érték: adott értékű, maximum “darab” darab elem eltávolítása a listából
LPOP kulcs, RPOP kulcs: listából egy elem kiemelése bal, illetve jobb oldalról

A lista pozíciók (kezdet, vég) megadásakor negatív számok is használhatóak, a “-2” érték hátulról a második elemet jelöli.

A halmaz műveletek igen érdekes felhasználási lehetőségeket rejtenek:

SADD kulcs érték, SREM kulcs érték: adott értékű elem halmazhoz adása, törlése
SPOP kulcs: egy véletlenszerű elem kivétele a listából
SMEMBERS kulcs: halmaz elemeinek a lekérdezése
SMOVE kulcs1 kulcs2 érték: az adott érték egyik halmazból a másikba történő mozgatása
SCARD kulcs: adott halmaz tagjainak száma
SISMEMBER kulcs érték: adott érték eleme a halmaznak?
SINTER kulcs1 kulcs2 kulcs3...: halmazok metszetének lekérdezése
SINTERSTORE célkulcs kulcs1 kulcs2 kulcs3...: halmazok metszetének lekérdezése, és letárolása a “célkulcs”-ú halmazba
SUNION kulcs1 kulcs2 kulcs3...: halmazok összegének lekérdezése
SUNIONSTORE célkulcs kulcs1 kulcs2 kulcs3...: halmazok összegének lekérdezése, és letárolása a “célkulcs”-ú halmazba
SDIFF kulcs1 kulcs2 kulcs3...: halmazok különbségének lekérdezése
SDIFFSTORE célkulcs kulcs1 kulcs2 kulcs3...: halmazok különbségének lekérdezése, és letárolása a “célkulcs”-ú halmazba

Egy halmazban egy adott érték csak egyszer szerepelhet, ha megpróbálunk hozzáadni egy már szereplő értékű elemet a halmazhoz, akkor a művelet “sikertelen” lesz (hozzáadáskor válaszul megkapjuk az információt, hogy mennyi elem lett sikeresen hozzáadva a halmazhoz).

Egy elég összetett lehetőségeket kínáló, a rendezés gondolatára felépített művelet is elérhető, mely listákkal és halmazokkal is működik:

SORT kulcs
SORT kulcs DESC
SORT kulcs LIMIT 0 10 ALPHA DESC
SORT kulcs BY suly_*
SORT kulcs BY suly_* GET object_*

A művelet adott kulcs elemeit képes rendezni (növekvő, csökkenő sorrendbe, numerikusan és alfanumerikusan), s limitálható az eredményhalmaz is a LIMIT kifejezés hozzáadásával. A BY kulcsszó segítségével bár a kulcs elemei lesznek rendezve, de nem a saját értékük szerint, hanem a BY által megadott prefixhez hozzáfűzött értékük szerinti kulcs értékét véve. Ha a GET kulcsszót is megadjuk, akkor válaszként nem az adott kulcs elemeit fogjuk visszakapni, hanem a GET által megadott prefixhez hozzáfűzött értékük szerinti kulcsok értékét.

A SORT funkció nem tud csodát művelni ami a sebességet illeti, gyorsrendezés az algoritmusa. Alfanumerikus rendezéskor a LC_COLLATE környezeti változó értékét veszi figyelembe.

További érdekesebb műveletek:

DBSIZE: adatbáziselemek számának lekérdezése
TYPE kulcs: kulcs típusának (sztring, lista, halmaz) lekérdezése
SAVE, BGSAVE, LASTSAVE: háttértárra mentéssel kapcsolatos műveletek

Nem az összes műveletet mutattam be, de a Redis által biztosított lehetőségek talán jól láthatóak ezen felsorolás után. Egy átgondolt, biztos alapokon álló fejlesztésről van szó, mindegy parancs esetén use-case indokolja meglétét, illetve csak olyan parancsok állnak rendelkezésre melyek legtöbb esetben gyorsak, vagy melyek nem feltétlenül gyorsak, de a funkcionalitáshoz sokat hozzátesznek.

Nem vettem bele a felsorolásba, de a Redis több adatbázist is támogat, melyeket sorszámokkal lehet elérni, s alapból 16 áll rendelkezésre. Ezek leginkább névtérként működnek, ezek között a névterek között is lehet kulcsokat mozgatni igény szerint. Használatuk helyett inkább több Redis szerver indítása (különböző portokon) lehet javasolt, tekintettel arra, hogy így az adatbázis mentések is elkülönülnek, hogy többprocesszoros szerveren a Redis egyszálas futtatási környezete így jobban megoszlik a processzorok között, egy esetleges blokkoló művelet csak egy adott Redis szervert tart fel, s mert talán egyszerűbb a nyilvántartása egy portnak, mint egy Redis adatbázis sorszámnak.

Backup

A Redis perzisztens módon háttértárra, konkrétan egy darab fájlba írja adatbázisának tartalmát a konfigurációban meghatározott időpontokban, események bekövetkeztekor. Ez a fájl a memória tartalom egy speciális, gyorsan kiírható, illetve gyorsan beolvasható lenyomata, más célokra nem használható – nem valami egyszerű fájlformátum, hanem tömény bináris fájl.

A kimentett tartalom backupolása igen egyszerű: csak le kell másolni a fájlt. Ez akár menet közben is történhet, a szerver leállítása nélkül, még akkor is, ha éppen egy háttértárra mentési folyamat fut éppen. A Redis egy átmeneti fájlt hoz létre, és a rename nevű parancs segítségével írja felül a korábbi fájlt, így biztosítva azt, hogy az átnevezés csak akkor történik meg, ha a fájlba írás véget ért, és sikeres volt. A művelet atominak számít, tehát vagy sikeresen megtörténik a régebbi fájl felülírása, vagy sikertelen lesz a művelet, s a korábbi fájl nem sérül.

Backupolni ezen kívül egy master-slave replikáció beállításával is lehet, egy slave adatbázison, így még az I/O műveletekkel sem terhelve a fő szervert.

Replikáció

A Redis replikációja egy elég egyszerűen konfigurálható, master-slave felállású replikáció, mely lehetővé teszi több slave használatát is, illetve a slave-ek láncként felfűzve (a slave is masterként viselkedik, hozzá további slave csatlakozik) gráfot is alkothatnak.
Replikáció közben a master szerver nem áll le, így egy slave kiesésekor vagy beállásakor (szinkronizáció esetén) a master továbbra is kiszolgálja a kéréseket. Ezzel szemben a slave oldalán a replikáció beindítása, a master állapotának felvétele közben nem végez műveleteket, ezzel is biztosítva az adatok konzisztenciáját.

Ha az adatbázis nem fér be a memóriába

Az adatbázisnak a Redis esetén be kell férnie a memóriába. Ennek megkerüléséhez a Redisnek nem célja segítséget adni, bár már felmerült egy olyan jövőbeni fejlesztési irány a levelezőlistán (egészen más okokból), hogy a Redis adattárolását megvalósító layer esetlegesen cserélhető lesz. Mindenesetre ha az adatbázisunk nem fér el a memóriában, akkor vagy nem tudjuk a Redist használni, vagy valamilyen adattárolási stratégiát bevezetve meg kell kerülnünk a kérdést.

Egy lehetőség, hogy a Redist csak cache-ként használjuk azokhoz az adatokhoz, melyekről tudjuk, hogy jelentős memóriát igényelnének. Ekkor ezekhez az információkhoz lejárati időt rendelünk az EXPIRE segítségével, így ha fogyóban a memória, a Redis fel fogja ezeket a területeket szabadítani, illetve maguktól is felszabadulnak egy idő után. Az írást mind a Redisbe, mind pedig a nagyobb kapacitású másik adatbázisba elvégezzük, s először megpróbáljuk a Redisből kiolvasni az információt, ha ott nem létezik, akkor fordulunk a másik háttértárhoz. Ezt a felállás mi sikeresen használjuk.

Esettanulmány: egy Twitter klón

A Redishez szinte az indulása óta elérhető egy PHP-ben írt Twitter klón forrása, mely nagyon egyszerű forráskódjával, illetve az alkalmazott stratégiákkal jól szemlélteti a Redis lehetőségeit, illetve azt a gondolkodásmódot, melyet el kell sajátítanunk, ha key-value adatbázist szeretnénk használni fejlesztéseinkhez.

Erre a gondolkodásmódra SQL múlttal nem is olyan egyszerű átállni, mert ellentmond minden ott megtanult metodikának, többek között a normalizálás szabályainak. Mindazonáltal ha végiggondoljuk hogy mi történik egy relációs adatbázisban a háttérben: látni fogjuk, hogy gyakorlatilag kevés a különbség ami a letárolt adatokat illeti, az indexek létrehozásával és redundáns tárolásával egy relációs adatbázis is hasonlóképpen működik mint amire szükség van key-value adatbázisok esetén.

A Redis wikiben található kis tutorialt érdemes végigolvasni, mivel olyan alapokkal kezd, hogy mi is jelent a key-value adattárolás a gyakorlatban, illetve mik azok az atomi műveleteket. Ebből a tutorialból emeltem ki pár gondolatot, melyek megmutatják, hogy hogyan lehet felépíteni egy összetett adatbázist.

A Twitter klón nem csak üzenetek küldését teszi lehetővé, hanem egy teljes(ebb) klónról van szó, mely a regisztrációt, a felhasználók személyes oldalát, ismerőseinek kezelését is tartalmazza.

A felhasználókat számmal azonosítja, melynek előállításához egy “global:nextUserId” kulcsú elemet használ. Új felhasználó létrehozásakor a következő parancsokat futtatja le a rendszer:

INCR global:nextUserId (ezáltal visszakapunk egy számot, pl: 1000)
 SET uid:1000:username felhasznalonev
SET uid:1000:password jelszo

Ebből a három sorból már rengeteget lehet tanulni. A kulcsok kapcsán mint látható, speciális elnevezéseket célszerű használni, “névtereket” létrehozva a kettőspontok használatával. Míg egy key-value adatbázis alapvetően nem struktúrált, ezzel a trükkel hierarchiát vezethetünk be. A felhasználó azonosító legyártásához szükséges változót a globális névtérbe, a felhasználó azonosítójához köthető információkat az “uid” névtérbe helyeztük.

Vegyük észre a párhuzamot az adatbázis táblákkal is, hasonló a helyzet, mintha egy “uid” táblában két oszlopot hoznánk létre, az 1000-es id-jú felhasználónak két oszlopa: a “username” és “password” állnak rendelkezésre. Most egy fontos design patternt tanultunk meg a key-value adatbázisokat illetően.

Mivel csak kulcs szerint érhetőek el az adatbázisunk értékei, jelenleg nem tudjuk lekérdezni azt, hogy a “felhasznalonev” felhasználóhoz milyen azonosító, milyen jelszó kapcsolódik, bejelentkezéskor, illetve a felhasználó saját oldalának kiszolgálásakor azonban erre az információra szükségünk van. Mint látható, az adatbázis tervezését jóval alaposabban végig kell gondolnunk mint egy relációs adatbázis esetén, legfőképpen azt megvizsgálva, hogy milyen módon szeretnénk a későbbiekben hozzáférni az adatbázisban szereplő információkhoz.

A felhasználónévből felhasználói azonosító létrehozását egy új kulcs létrehozásával tudjuk megtenni, relációs adatbázisok esetén erre egy index szolgált volna:

SET username:felhasznalonev:uid 1000

A Twitternél minden felhasználónak vannak követői, illetve követik is felhasználók. Itt is hasonló stratégiát kell alkalmaznunk, mint az előbb, ugyanis mind a két irányból szeretnénk lekérdezni az információt a szolgáltatás működtetésekor (kiket követ, kik követik a felhasználót), ezért két kulcsot fogunk használni felhasználónként erre a célra. Amit az adatszerkezetet illeti, a halmazok tökéletes választást jelentenek majd:

uid:1000:followers
uid:1000:following

Egy nagyon fontos adatstruktúra még hátra van, a felhasználó legfrissebb hozzászólásait szeretnénk megjeleníteni az oldalán, mondjuk visszanézhetően maximum mondjuk ezret. A hozzászólásokat egy globális névtérben fogjuk eltárolni, s a felhasználókhoz hasonlóan azonosítókkal látjuk el, s hogy lekérdezhető legyen, hogy egy adott felhasználónak milyen hozzászólásai voltak, egy listát vetünk be:

uid:1000:posts

Amikor a felhasználó hozzászól, akkor a globális lista adminisztrációja mellett ebbe a listába is felvesszük a hozzászólás azonosítóját (LPUSH), majd a listát az ezredik elem után csonkoljuk (LTRIM), hogy ne nőjön a végtelenségig. A lista “lapozhatóan” az LRANGE parancs segítségével érhető el.

A Twitter klónt bemutató wiki oldalon ennél sokkal több gondolat olvasható, de ezzel a kivonattal talán sikerült megmutatnom pár design patternt, melyek jól használhatóvá teszik a key-value adatbázisokat, illetve megmutatják azon gyengeségeit, melyek erősségként is felfoghatóak.

Összefoglalás

A fentebb írtakból talán kiderül: egy nagyon jól használható adatbázis szervert ismerhetünk meg a Redis személyében ha úgy döntünk kipróbáljuk mit tud. Gyorsan tanulható, egyszerűen használható megoldást kínál sok problémára, melyek webes alkalmazásfejlesztéskor kifejezetten hasznosak tudnak lenni.

Mi a Miner.hu projektünk keretében, illetve iWiW alkalmazásokhoz használjuk háttéradatbázisként a Redist. Az előbbihez nagyrészt cache megoldásként, a friss bejegyzések memóriában tárolására, tematikus rovatainknál pedig a friss bejegyzéseket listákban tartjuk nyilván. Eddigi tapasztalataink azt mutatják, hogy egy terhelhető, stabil, jól használható eszközt vezettünk be, melyet másnak is szívesen ajánlunk.

© admin for ‹Webakadémia /›, 2009. | Permalink | 14 comments | Add to del.icio.us
Post tags:

Feed enhanced by Better Feed from Ozh

A szervező Sebestyén Anna volt, akinek nemzetközi szinten vannak tapasztalatai a témáról, s egy igen jó eseményt sikerült szerveznie a Dob utca egy hangulatos borozójában, egy kis borozással fűszerezve. Az, hogy az előadások angol nyelvűek, annak alapvetően nem lenne értelme, de Anna sikeresen meghívott egy amerikai, és egy hazánkban élő, de ír előadót is, az előbbi az egész rendezvénysorozatot elindító June Dershewitz volt, míg az utóbbi a Yahoo! Magyarország hazai részlegénél analítikai szakértőként dolgozó Emer Kirrane. Rajtuk, és rajtam kívül még Tóth Benedek és Anna adott elő. A két említett előadón kívül még további magyarul nem beszélő résztvevők is eljöttek, azt sajnos nem tudom hogy a magyar ismerősökön kívül pontosan kikkel beszélgettem igen jókat.

Az angol nyelv gyakorlásán, illetve a kapcsolatépítésen kívül azért is igen jól éreztem magam, mert végre itthon is beindult azon rendezvények sora, ahol lehetőség adódik egy kis kitekintésre. Nem csak az amúgy sokat látott barátságos magyar arcok, hanem még barátságosabb idegenek is előfordultak, azokat az élményeket előhozva belőlem, amikkel eddig csak külföldi rendezvényeken találkoztam.

Hogy az előadásomról is ejtsek egy kis szót, a Google Analytics API-ról beszéltem, illetve a Piwik és Open Web Analytics nyílt forráskódú analítikai szoftverekről. Az előbbi segítségével – egy kis kódolással – sokkal testreszabhatóbb, használhatóbb felület állítható össze mint amit a Google Analytics mutatni tud, illetve az utóbbiak pedig a saját információim, adataim feletti szabadságot teszik elérhetőbbé úgy, hogy közben minőségben is jót tudnak adni.

© admin for ‹Webakadémia /›, 2009. | Permalink | 2 comments | Add to del.icio.us
Post tags:

Feed enhanced by Better Feed from Ozh

A prezentáció letölthető PDF formátumban is: Turbó fokozat (kb. 10MB)

© admin for ‹Webakadémia /›, 2009. | Permalink | 11 comments | Add to del.icio.us
Post tags:

Feed enhanced by Better Feed from Ozh

Egyik gond a MySQL adatbázis backupja, melyet megoldottunk ugyan egy slave adatbázis beállításával, a napi backup alatt a replikáció leállításával, rsync-kel történő backupolásával, de rengeteg erőforrást emészt fel így is a történet. A régi blogbejegyzéseket persze törölhetnénk, rengeteg helyet felszabadítva, hiszen ki kiváncsi vajon egy két évvel ezelőtt született blogbejegyzésre, de szeretnénk a Miner ezen lehetőségét megtartani. Másik lehetőség az lenne, hogy szétdaraboljuk az adatbázist, és a régebbi tartalmakat csak olvasható formában tároljuk, ezzel az a gond, hogy akár igen régi bejegyzésekhez is hozzá kell nyúlnunk néha, mert a szerző kéri, hogy blogját töröljük adatbázisunkból (ilyen igen ritkán van, de nem mondhatjuk hogy nem tudjuk megoldani). Az irány valószínűleg valamilyen elosztott adatbázisba mentés lesz, mely nem csak a tárolást, hanem egyben a backupot is biztosítani tudja.

Másik gond a lekérdezések sebessége. Itt például a mellékletek friss bejegyzéseiről van szó, itt a gyors megjelenítés a követelmény. A probléma itt abból adódik, hogy egyes mellékleteknél (mint például a film) vannak olyan blogok (pl. sorozatjunkie, comment.com), melyekben nagyon-nagyon sok bejegyzés van. Ilyenkor egy olyan SQL lekérdezés, mely dátum szerint rendez, és több tucat kategóriára szűr, elég sokáig tarthat. Ugyanitt probléma a megfelelő képek, videók kiszűrése is a tartalomból. Már korábban továbbléptünk egy külön indexelésre, illetve keresőszerverünk bevetésére (mely meglepő módon gyorsabb tud lenni, mint a MySQL), további lépés várhatóan az lesz, hogy az egészet felturbózzuk az egy-az-egyben a memóriába pakolással.

Végül, de nem utolsó sorban a robotok működését sem mondanám a legkiforrottabbnak, bár az utóbbi években bizonyított ez a felállás, a további skálázhatóság, és a jobb áttekinthetőség érdekében tovább kell lépnünk. Jelenleg pár PHP-ben írt robot fut párhuzamosan, lekérdezve a MySQL adatbázisból hogy mely blogok RSS-ének letöltése következik, s párhuzamosan elindítanak 100 kérést, az eredményt pedig memóriába pakolják. További robotok a memóriából felolvassák az RSS tartalmát, megnézik van-e új blogbejegyzés, módosult-e már régi, s ha igen, akkor letárolják azokat, s gondoskodnak a mellékletekbe történő “címkézésről” is. Ezt a felállást a MySQL lehetőség szerinti teljes kiiktatásával, s erre kitalált jobszerverek, queue-k összerakásával szeretnénk kiváltani, mely azt is kényelmesen lehetővé teszi, hogy a hamarosan beállítandó új szerverekre osszuk szét a jelenlegi terhelést (az indexelés jelenleg a legerőforrásigényesebb feladatunk).

Persze ez csak az előttünk álló technikai változtatások egy (a jelentősebb) része, s az új szolgáltatásokról még nem is ejtettem szót. A megoldásokról igyekszem majd részletes blogbejegyzésben, blogbejegyzésekben, továbbá ha lehetőségem adódik rá, akkor egy newtech meetup keretében is beszámolni.

© admin for ‹Webakadémia /›, 2009. | Permalink | One comment | Add to del.icio.us
Post tags:

Feed enhanced by Better Feed from Ozh

Nem mondom hogy a kódot valaki próbálja meg élesben használni, ahhoz egy kicsit még kezdeti állapotban van – az irány az érdekes, amit meg lehet majd esetleg csinálni a motorral ha felnő.

Kérdés lehet persze, hogy mi a fenének hozzuk be a MySQL-t a képbe, miért ne direktben PHP-ben valósítsunk meg inkább egy feladatot, ha már. Számos oka lehet egy ilyen iránynak mely miatt hasznos lehet egy ilyen motor számos hátránya ellenére:

1. Mindenekelőtt a PHP kód ebben az esetben egy szerver szolgáltatásba épül be, állandóan a memóriában van, szemben egy webes PHP-val, ahol egyszer lefut, és el is felejt utána mindent. Ennek már így vannak előnyei, például hogy cache-elhetőek a lekérdezésekre adott válaszok. Persze egy memcached segítségével is meg lehet valósítani ugyanezt.
2. A MySQL szerver lehet egy különálló gépen is, és nem feltétlenül csak PHP-ből használhatjuk a kódját. Vagyis kvázi távoli eljáráshívásokat is megvalósíthatunk ezzel a megoldással. Persze vannak kész szabványaink távoli eljáráshívásra.
3. MySQL-en belülre hozhatunk be adatokat, és azokat kombinálhatjuk “igazi” MySQL táblákkal, támaszkodva a MySQL ezirányú képességeire. Nem tűnik rossz ötletnek egy JOIN-t rábízni a MySQL ahelyett hogy saját magunk valósítanánk meg.
4. Az előző ponthoz kapcsolódva, például az Amazon S3-at (vagy bármely más, adatbázis szerű Webes API-t) tudjuk MySQL-es lekérdezéseken keresztül elérni, összekapcsolni más táblákkal. Persze nagy csodát ne várjunk, mert jellegéből adódóan ez csak limitáltan fog működni, ellenben el lehet gondolkodni a lehetőségeken.
5. Az absztrakció sohasem elvetendő ötlet, egy adattárolási réteget hozhatunk be az alkalmazásba – ha az jó.

Több pontot is “persze”-vel fejeztem be, így látszik, hogy ez a motor azért eléggé öszvér megoldás. Az ilyen ötletek mozdítják viszont előre az innovációt, hiszen ki tudja kinek mi jut eszébe vagy mire tudja hasznosítani majd ezt a lehetőséget.

© admin for ‹Webakadémia /›, 2008. | Permalink | 3 comments | Add to del.icio.us
Post tags:

Feed enhanced by Better Feed from Ozh

A Drizzle a MySQL kódbázisára épülő, könnyített változat, melynek fejlesztéséhez úgy tűnik, hogy többen is kapcsolódnak – ráadásul a MySQL tulaj Sun berkeiből. A csonkítás – többek között – érintette a nézeteket, triggereket, tárolt eljárásokat, a lekérdezések gyorsítótárazását és a jogosultság kezelést is, tehát rendesen folyt vér is a művelet közben. Ezek a funkciók azért lettek beáldozva, hogy egy olyan “kicsi”, karbantartható forráskód szülessen, mellyel aztán meg lehessen célozni cloud computing környezetben futó alkalmazásokat.

A funkciók többségének eltávolítását egyébként teljesen korrektnek tartom abból a szempontból, hogy egész jól meg lehet lenni ezek nélkül a funkciók nélkül – a MySQL története is ezt bizonyítja, ezeknek a funkcióknak egy része nem volt jelen, a MySQL viszont töretlenül fejlődött. Ha tényleg sikerül kialakítani egy az eredetinél jobban skálázható szervert, akkor elég sokat nyerhetünk a dologgal.

Addig is viszont ideje lenne hivatalosan (nem release candidate-ként) is megjelennie végre a MySQL 5.1-nek.

© admin for ‹Webakadémia /›, 2008. | Permalink | 6 comments | Add to del.icio.us
Post tags:

Feed enhanced by Better Feed from Ozh

Mire jó a view?

A MySQL nem túl régóta használható lehetősége a view támogatás. Az eddigi munkáim során valahogy sohasem hiányzott a lehetőség, hirtelen még olyan esetet sem tudok felidézni, hogy kellett volna, de kliens oldalon megoldottam. A view-k pedig többféle érdekes dologra is használhatóak, ezeket sorolja fel a belinkelt cikk is: adat tisztításra, “döntéshozatalra”, bonyolult táblák egyszerűsítésére, adattartalmak “szebbé tételére”, stb.

Memcached Wiki

A memcached jó dolog. A belinkelt róla szóló wiki is, különös tekintettel a FAQ részekre, ahol elég jó kérdés-válasz párokat gyűjtöttek össze.

MySQL pager

Az talán senkinek nem újdonság, hogy ha a MySQL konzolban a pontosvessző helyett \G-t írunk a lekérdezés végére (így simán, két karakterrel), akkor másfajta megjelenítésben nézegethetjük a lekérdezés eredményét (ez akkor jó, ha az oszlopos nézet használhatatlan, mert sok az oszlop). Ami számomra újdonság volt, hogy az adatbázis válaszok megjelenítőjét “pager”-nek hívják, és hogy írhatunk sajátot is.

MySQL WITH ROLLUP

Egy érdekes lehetőséget biztosít a MySQL a GROUP BY használatakor, főként mikor több oszlop szerint is csoportosítunk. Én valami olyan hasznos alkalmazását tudom elképzelni, hogy több oszlop szerint csoportosítás után még HAVING segítségével leszűkítjük a kört úgy, hogy csak pár sor maradjon, olyanok, melyeket amúgy nehéz lenne összehozni egy lekérdezésben, de célszerű együtt megjeleníteni. Másik érdekes alkalmazási terület az, amikor a szerveren olyan alkalmazásunk fut ami korlátozottan engedi csak az SQL lekérdezések eredményeinek manipulációját (pl. egy lekérdezést egy az egyben képes csak megjeleníteni, és nem engedi összeadni a sorokat), így kénytelenek vagyunk mindent SQL-ből megoldani.

URL kódolás és dekódolás MySQL-ben

Ha egy SQL lekérdezés során szeretnénk egy kész URL-t előállítani, akkor jöhet jól ez az UDF, avagy User Defined Function MySQL kiegészítés, amivel a PHP-ben megszokott urldecode/urlencode függvényeket használhatjuk SQL lekérdezéseken belül is.

Myosotis Connector (MySQL & PostgreSQL)

Többször emlegettem már a különböző proxy lehetőségeket, ezekkel legfőképpen az a baj, hogy kimutatható módon lassítják az adatbázis műveleteket. A Myosotis Connector nevű proxy ezzel szemben azt ígéri, hogy gyors – a saját tesztjeik alapján gyorsabb, mint a MySQL Proxy és az uni/cluster megoldások.

© boogie for ‹Webakadémia /›, 2008. | Permalink | 2 comments | Add to del.icio.us
Post tags:

Feed enhanced by Better Feed from Ozh