Sláva databázím

Databáze jsou stroje na zpracovávání a ukládání dat. Dělají to dobře a proto je máme rádi. Databáze jsou velmi praktické, neboť usnaďňují přístup k datům. Místo toho, abychom si pro přístup k datům museli pokaždé napsat svůj program, můžeme vznést dotaz a server nám ho zodpoví. Vzrůstá tak dostupnost dat, jelikož jsou data snadno přístupná i mimo program, který s nimi obvykle pracuje.

Když máme k datům snadný přístup, můžeme je pak zpracovávat. Databáze je tu od toho, aby nám zpracovávání dat ulehčila, což také dělá. Umí je totiž zpracovávat mnohem efektivněji než kdybychom si to dělali ve vlastní režii. Efektivita databáze se nejlépe projeví při práci s větším objemem dat a při současném přístupu více uživatelů ke stejným datům. Embedded databáze toto neumí a to je také důvod, proč jsou mnohokrát rychlejší než databáze klient server.

Jak u IBM poskytovali Internet

V dobách boomu poskytování dialup připojení se do tohoto druhu podnikání pustili i u IBM. Měli k tomu mnoho předpokladů: vlastnili dostatečnou volnou přenosovou kapacitu ve vlastní síti a měli velmi dobré know how. Začali tedy podnikat ve velkém stylu, tedy ve stylu na který byly běžně zvyklí zvyklí ze svého podnikání pro velké zákazníky.

Bylo to dost v ostrém kontrastu se zbytkem trhu, jelikož ten se spolehlivost pro své zákazníky zajišťovat nepokoušel. A tak jsme si mohli vyzkoušet na jejich webu různé hračky, jako online monitoring sítě a podobné vychytávky. Linky i servery měli zálohované a o svých výpadcích reportovali veřejně na webu, což byla v té době velká vyjímka. Pokud se jim něco rozbilo, nabízeli všem zákazníkům, kteří o to požádají, následující měsíc zdarma. Neuvěřitelné.

Bavilo mně číst jejich crash reporty:

,,Tři dny nám nefungovala pošta. Server poštu pouze přijímal, ale neodesílal ji. Žádná data zákazníků se nestratila a po opravení závady se nahromaděné maily začaly rozesílat. Během doby, než se situace stabilizuje bude odchozí pošta rozesílána s hodinovým opožděním. Pokud potřebujete odeslat svou poštu okamžitě, kontaktujte náš zákaznický servis.''

,,Během 2-3 hodiny noční byla prováděna údržba, přičemž byly schránky uživatelů nedostupné. Jelikož jsme tuto údržbu neplánovali a neinformovali o ní, bude všem poškozeným poskytnutna 30 USD náhrada.''

Železářství

Jako hardware používaly servery z řady RS/6000 běžící pod AIX Unixem se standardnímy unixovými programy jako sendmail, inn, pop3d atd. S nárůstem zákazníků se zjistilo, že toto řešení není moc dobře škálovatelné. Větší výkon by se dal zajistit pomocí více strojů, ale to by zase zvýšilo náklady na správu systémů. Jelikož byla IBM trénována po mnoho desetiletí v oblasti IT highendu, kam ostatně patří dodnes, měla k dispozici i mnohem silnější stroje než RS/6k. Chtělo si to prostě jen vzít větší kladivo.

Na kovárně

Kovář s větším kladivem zhodnotil věc střízlivě. Když zjistil, že denní průjezd mailů je pouhých 1.5 miliónu se špičkami 50/sec, uklidnil se. Jím dovezené kladivo zvládalo 20000 uživatelů online. Zbýval tak jen jediný problém a tím byl software.

Data patří do databáze

Sendmail byl program pro malé, ale naštěstí ne měkké, systémy. Ale i kdyby na cílové platformě běžel, tak by to pravděpodobně nestačilo. Chtělo to poctivý software, který si dat váží a ukládá je do databáze, nikoliv do filesystému. Každý velký kovář totiž ví, že se filesystém používá jen pro archivaci záloh. Takový software však k dispozici nebyl a tak jej bylo nutné napsat. Nebylo to zase tak těžké - SMTP je jednoduchý protokol a MTA taky není příliš složitá úloha. Tož to nakódujeme za odpoledne, ne?

Jak si usmysleli, tak také udělali. Data se tak přestěhovala do nejlepší databáze na světě - IBM DB2 a bylo jim tam dobře. Smtp server s databázovým backendem se činil a situace se uklidnila. Časem přibyl ještě druhý mail exchanger. Ne, že by to první nezvládal, ale z důvodu zvýšení odolnosti proti výpadkům. To je jedna z výhod databázových emailových systémů - jsou bez problémů škálovatelné přes více strojů.

POP3

Přijmuté maily bylo nutné zpřístupnit uživatelům. S DB backendovou variantou se původně nepočítalo, jelikož mailboxové servery běžely svižněji. Naštěstí se v té době používal výhradně protokol POP3 a nikoliv hrůza zvaná IMAP4, což rozhodlo o dalším postupu. Proč data exportovat, když je můžeme použít přímo tam kde jsou.

POP3 je tak jednoduchý protokol, že je pro jeho špatné nakódování potřeba vynaložení mimořádného úsilí. Kovář s velkým K toto úsilí nevyvinul a nakódoval to hned napoprvé dobře. Uživatelé tak přímo přistupovali k mailům v databázi a bylo to tak dobře. Správa celého systému se tak zjednodušila, neboť se stačilo starat o databázi a nikoliv o data jednotlivých uživatelů.

NNTP

Po zvládnutí kombinace POP3+SMTP se Kovář zaměřil na další výzvu. Touto výzvou byl news server skomírající pod inn 1.x. Výkon news serverů závisí značně na výkonu filesystému, který nebývá nic moc. Mně se pro news server nejvíce osvědčil ReiserFs. Newsů je na severu moc hodně a pořád přicházejí další. News server schramstne veškerou bandwidth, co mu přihodíte, a veškerý diskspace.

Uživatelů také není zrovna málo, zájem je především o různé alt.binaries skupiny. Dříve byla nějvětším hitem alt.binaries.erotica. Veřejných news serverů zase nebylo tak mnoho a byly značně pomalé.

Kovář v tom žádný problém neviděl a pracoval, tak jak byl zvyklý. Nakrmil data do DB2 a bylo. Těch dat nebylo málo, statistika serveru povídala něco o 60 miliónech článků a 3 miliónovém denním průjezdu. Žádný problém pro Kováře.

Všeho moc škodí

News server s DB backendem byl vynikající dílo. Byl neuvěřitelně rychlý, zvládal stovky uživatelů online, a měl téměř full set news. Co je dobré, je taky populární. Tenhle server byl. Jelikož povoloval připojení odkudkoliv, používal ho kde kdo. IBM to nejprve nevadilo. Vadit to začalo až v okamžiku, kdy počet připojených uživatelů z non IBM network převyšoval jejich domácí uživatele o dva řády.

A tak jsme přišli o vynikající news server...