Když jsme si minulý týden s jedním zaměstnancem partnera firmy, ve které pracuji, povídali o jejich produktu – databázi ADABAS pro mainframy i otevřené systémy – dospěli jsme k zajímavé diskusi.

Abych šel po stopách našich myšlenek, nejprve jsme diskutovali o tom, že databáze ADABAS je podstatně rychlejší než Oracle. To není nic nového pod sluncem, nebo nějaký pokus o flame. ADABAS totiž není relační databáze. Moc toho neumí, ale je rychlá. V tom je veliký rozdíl s relační databází.

V poslední době se čím dál víc začínají prosazovat ne-relační databázové systémy. S příchodem webu 2.0 a nejrůznějších těžkomyslitelných „sociálních“ sítí se totiž ukazuje, že jakmile se startup povede, musí se databáze předělat. Nezačne to zkrátka stíhat.

Bavili jsme se o tom, že technologie ADABAS je trochu na ústupu. Společnosti tyto technologie zřejmě nepořizují pro nově vznikající projekty, nicméně softwarové firmy mají vyvinuty velmi stabilní technologie a firmy, u kterých jsou tyto nerelační systémy v provozu, je stále potřebují. Jsou to prostě jen stále špičkové technologie.

Možná je to šance pro společnosti dodávající takové typy databází tyto produkty znovu oživit. Znovu je přivést s pompou na trh. Udělat marketing, všechno nově zabalit. Oprášit a prodat. Znovu. Web 2. AJAX. JavaScript.

Jen je nutné, aby tyto produkty fungovaly na otevřených systémech (tj. na ne-mainframech – např. na Linuxu nebo Windows).

Mimochodem, když by jste se mě právě teď zeptali, ve kterém programovacím jazyku vidím budoucnost, řekl bych jistě JavaScript. Podle mého názoru se bude v JavaScriptu psát stále více kódu a budeme ho nacházet na místech, kde bychom to ještě před časem nečekali. Kravaťáci těšte se. To jen tak na okraj.

V přednášce Guido van Rossuma, který už od roku 2005 pracuje pro společnost Google a je (mimo jiné) autorem jazyka Python, jsem se dozvěděl jedno. Relační databázové systémy špatně škálují. Tečka.

Když si uvědomíme, co všechno relační databázové platformy nabízejí, je snadné sečíst jedna plus jedna. Samozřejmě, jistá škálovatelnost je možná, ale má své hranice. Všechno má své pro a proti. Nerad bych zacházel do technických detailů – koneckonců nejsem expert přes databáze.

Guido uváděl příklad – společnost LinkedIn. Autoři museli údajně minimálně pětkrát předělávat datový model. Postupně, jak služba rostla a připojovalo se více a více uživatelů, autoři vypouštěli JOINy z SQL dotazů, databázové tabulky postupně denormalizovali a nakonec vše rozdělili do různých navzájem replikovaných databází. Museli prostě ustoupit – hardware by to prostě nezvládal.

Ta přednáška byla mimochodem o databázové technologii BigTable, která pohání takřka celý Google. Může škálovat donekonečna – neexistují žádné hranice v rozsahu dat, se kterým lze pracovat v rozumných časech. Podle Rossuma není problém, abyste měli v Google App enginu petabajty dat. Pokud si je ovšem zaplatíte.

Technologie pod BigTable se nazývá MapReduce a umožnila vzniknout dalším projektům pro ukládání dat, které se hodí pro webové aplikace. Například CouchDB od Apache, což je databáze spíše dokumentově orientovaná, nicméně se dokonale hodí ke tvorbě cloudů. Podobně jako SimpleDB od Amazonu, což je podobná věc v bledě modré.

Programovací model MapReduce obrovskou měrou stojí za úspěchem společnosti Google – byla a je to vždy vysoká kvalita služeb, kterou Google poskytuje zejména na poli vyhledávání. Díky MapReduce lze rychle provádět výpočty jako jsou třeba zpětné odkazy, zpětný index nebo frekvence přístupů na webové stránky. To jsou pro Google klíčové záležitosti – musejí je provádět rychle.

Není to ovšem jen o firmě Google. Společnost Oracle před nějakým tím rokem koupila technologii Berekeley DB prostřednictvím společnosti Sleepycat. Jedná se o nerelační databázi s podporou transakcí původně vyvinutou na univerzitě Berekeley, a dále na Harvardu.

K dispozici jsou dvě edice – Berekeley DB a Berekeley DB Java Edition plus nadstavba pro práci s XML. Sama společnost Oracle v elaborátu vysvětluje, kdy se nasazení takovéto databáze hodí nejvíc. V situacích, kdy je relační systém prostě overkill. Na druhou stranu BDB je prostě jen knihovna, nejedná se o plnohodnotný server a z toho plynou jak výhody, tak i nevýhody. Oracle prezentuje BDB jako ideální pro web.

Zájemcům výše uvedený materiál doporučuji prostudovat. Jsou tam shrnuty asi všechny nejdůležitější vlastnosti.

Naše rozhovory mimochodem probíhaly ve velmi stylové australské restauraci v Darmstadtu, kde jsem snědl asi největší hamburger svého života. Poručil jsem si k němu ještě sýr navíc a opečené brambůrky na americký způsob. Nikdy jsem netušil, že málem nesním jeden hamburger. Jedli jsme ho příborem, protože rukama to nešlo. Byl výtečný, k tomu jsem popíjel ležák plné chuti Fosters. Vešel se do mě ale jen jeden – pak už jsem nemohl nic. Kdybych si zapamatoval název restaurace, určitě bych ji doporučil.

Tento zápisek vznikl převodem z mého starého blogu. Ne všechny texty byly takto převedeny, kompletní archiv již není k dispozici.