jAbLoK

Prosba pro čtenáře Jabloku: pokud vás nadpis odradil, dejte šanci aspoň poslednímu odstavci. Díky.

V původní zmínce o Google AppEngine na Jabloku jsem se zmínil, že při tvorbě vysoce škálující aplikace se vývojáři (vlastně i architekti) musí nemálo omezit. Aspoň pokud si škálovatelnost nezaměňují s “bude to nějak fungovat i na WebLogicovém clusteru”…

Podobně i poznámky z mailing listu o GAP zesumarizované na HighScalability.com se dají shrnout následovně:

• i ve velmi zatížené databázi jdou některé databázové poučky stranou
• v distribuované databázi tím tuplem

Pokud předpokládáme, že tam někde vzadu dříme neomezeně výkonná databáze, tak napsat škálující aplikaci je celkem triviální. Takový předpoklad je ale příliš silný. Když se podívám kolem sebe, nejpopulárnější jsou následující typy řešení:

1. Postavené na marketingu: vezmeme drahý hardware, velké diskové pole, rozběhneme drahou automagii typu Oracle RAC (wiki) a budeme doufat, že to našim potřebám postačí.
2. Postavené na skromnosti: vezmeme levný hardware, memcached nebo nějaké podobné kešovátko, a budeme doufat, že to našim potřebám postačí
3. Postavené na ambicích: stanovíme si neomezeně škálující databázi jako hlavní zadání a vypadne nám S3 nebo BigTable. Sami to asi dohromady nedáme, ale můžeme či budeme moci si za rozumný peníz pronajmout cizí infrastrukturu.
4. Postavené na koleně: zamyslíme se nad tím, co naše aplikace chce a jaká omezení jsou akceptovatelná, a zohledníme požadavky na škálovatelnost databáze už v návrhu aplikace. Vypadne nám třeba něco jako Flickr.

Varianta č. 1 se úspěšně etablovala v oblasti interních podnikových aplikací – požadavky na škálovatelnost jsou relativně omezeny velikostí korporátu, a utrácení peněz za hardware a licence u velkých dodavatelů je přece osvědčený postup

Druhá varianta je úspornější variantou téhož, i když zlí jazykové mohou poukázat na to, že úspora za hardware a licencích se vykompenzuje náklady na lidi. Těžko říct.

Varianta třetí je nejmladší. Škálovatelnost obvykle znamená, že databáze je při jakémkoli zatížení a objemu dat stejně, byť jakž takž únosně pomalá. Nutno kombinovat s variantou č. 2 (kešování). Omezení jsou předem daná – mohou vás odradit, na druhou stranu vás ochrání před tím, abyste si je bolestivě objevovali sami.

Varianta poslední byla obvykle implementována jako znouzectnost firmami, kterým předchozí varianty nestačily (a často v době, kdy varianta č. 3 nebyla na trhu). Pokud se člověk poučí od ostatních, může to být pro složitější aplikace zlatá střední cesta.

Názory ctěného čtenářstva uvítám. Pokud váš názor je “jdi s tím do háje, na jabloku chci číst o Javě”, dejte prosím taky vědět. Díky.