jAbLoK

Narazil jsem dnes na článek obsahující pozoruhodný mix nesouvisejících konceptů a zakončený bizarně nekompromisním prohlášením, že:

Dnešní rychlokvašná “MySQL generace” totiž vůbec neví, že databáze jsou určené k tomu, aby se v nich programovalo.

Stručný výtah pro ty, kdo se nechtějí celým pojednáním prokousávat:

• Nadstavby nad  API  pro komunikaci s databází (neboli autorovo slovníkem “databázové layery”) jsou špatné, pokud podporují více databázových systémů
• Tyto nadstavby mají smysl pro některé open-source projekty, kde je “rychlost nadřazena nad výkon a spolehlivost” (wtf?)
• Autor v TSQL vytvořil backend webu s návštěvností v řádu statisíc pageviews denně, a považuje to za správné
• Výše citované tvrzení o “MySQL generaci” je doplněno úvahou o tom, že nepsat backend webu v SQL dialektu o síle obdobné T-SQL často značí neznalost

Zvážit podporu více databází je pochopitelně namístě, pokud vyvíjíme produkt, který si uživatelé/zákazníci budou instalovat ve svém prostředí. Mimochodem, záhadou zůstává, z jakých důvodů autor původního článku tento smysl přiznává jen open-source projektům.

Více podporovaných databází znamená více potenciálních zákazníků. Jaké procento kódu se vyplatí psát pro každou databázi zvlášť je jistě věcí ekonomické úvahy zohledňující specifika konkrétního produktu. U “běžné databázové aplikace” se ale toto procento dle mého názoru bude blížit nule.

Takové “běžné databázové aplikace” si podle nasazení můžeme zjednodušeně rozdělit do tří skupin:

1. Aplikace, která zdaleka nezatíží ani jeden server
2. Aplikace, které jeden server zdaleka nestačí
3. Aplikace, která perfektně vytíží právě jeden server, plus minus autobus

Co si budem povídat, u skupiny prvni je výkon získaný vykonáváním aplikační logiky v databázi nepodstatný.

U skupiny číslo dvě si uvědomíme, že horizontální škálování v zásadě bezstavové aplikační logiky je brnkačka, a případným zástupcům“rychlokvašné MySQL generaci” jen poděkujeme za prozíravé rozhodnutí do aplikační vrstvy nacpat co nejvíc logiky, kterou by rÁdobyprofesionál programoval v databázi.

Časem podobně jako třeba eBay stejně zjistíme, že na aplikační vrstvu budeme muset převést i operace, které by nás dřív nenapadly – třeba spojování tabulek.

Co se týče skupiny číslo tři, ať každý sám zváží, jak dlouho do ní jeho aplikace bude spadat.

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.