Vlákno názorů k článku Suckless: méně smradlavý software od Franta Kučera - Zrovna píšu takovou jednoduchou Java EE aplikaci. Funkcionalita...

Zrovna píšu takovou jednoduchou Java EE aplikaci. Funkcionalita je daná, vychází z požadavků – pojďme se tedy podívat na technologie: např. to, co vyřeším pomocí jednoho SQL nebo XPath dotazu, bych psal v „čistém Céčku“ na kolik logických řádků? Skutečně by to bylo méně kódu a byl by přehlednější? Konverzi a filtrování dokumentů bych měl dělat místo v XSLT taky v C? Opravdu by to bylo efektivnější a čitelnější? Měl bych raději použít „plain text“ a souborový systém a napsat si nad tím na zelené louce „pár funkcí v Céčku“, místo abych použil relační databázi, kterou již napsal, odladil a otestoval někdo jiný? Nepřijde mi to jako dobrý nápad – takový software by byl mnohem dražší, vývoj by trval déle a údržba a rozvoj by byly obtížnější.

Dobrý databázový systém nemá s velkými soubory problém, klidně tam můžeš naprat obrovské BLOBy – databáze si to stejně uloží do separátních souborů, ale ty od toho abstrahuješ – je ti jedno, jestli je to několika-prvkové pole bajtů nebo gigový ISO obraz, s obojím můžeš pracovat pomocí stejného API.

Ten důvod proč dávat velké soubory rovnou na FS než do databáze je spíš ten, že z databáze ty data musí obvykle protékat přes tvoji aplikaci a zbytečně ji to zatěžuje – zatímco z FS to můžeš třeba nasdílet nějakým jednoduchým protokolem po síti nebo jen dát příkaz HTTP serveru, aby servíroval určitý soubor z disku (tzn. data nemusí fyzicky téct přes tvoji aplikaci, ale přesto si u nich můžeš řídit uživatelská oprávnění nebo logovat přístupy).

> ale proc tam jsou obludnosti jako: sql, xpath

Protože aplikace si potřebuje držet stav – data (nebudu říkat záznamy nebo objekty, protože to už je implementační detail, abstrahujme od toho) a s těmi daty potřebuji něco dělat. A většinou ale ne se všemi daty, ale s nějak definovanou podmnožinou. Buď si na to napíšu SQL dotaz s WHERE podmínkou nebo třeba XPath dotaz, který vyfiltruje elementy na základě jejich atributů a dalších vlastností… a nebo bych mohl pokaždé v Céčku iterovat přes pole všech dat a pomocí několika IFů z nich vytahovat požadované položky.

Jak relační databáze, tak XML databáze podporují indexy a tohle hledání/filtrování je efektivní – většinou nemusím dělat full table scan.

Plus, jak už tady padlo, transakce, agregační funkce atd. – tohle všechno mám při použití databáze „zadarmo“ – nemusím to programovat, nemusím to testovat, prostě to funguje. Prostě dám BEGIN a COMMIT a nemusím řešit, v jakém pořadí mám přejmenovávat a přepisovat soubory a dělat nějaké další vylomeniny, aby byl systém po případném výpadku v alespoň trochu konzistentním stavu. A když narazím na něco, co se mi nelíbí, dám ROLLBACK a vše je zase v původním stavu – nemusel jsem si kvůli tomu někam poznamenávat všechny provedené kroky a návod, jak je vrátit zpátky – to za mě dělá ta „obludnost“ relační databáze. Funkce jako sum, min, max, avg… mi spočítají výsledek, aniž bych ta data musel natahovat do mé aplikace – který souborový systém tohle umí? Leda tak spočítat počty souborů nebo orientačně obsazené místo, ale tím to hasne – obsahu souborů nerozumí a to už bych musel řešit ručně v aplikaci já.

> ale proc tam jsou obludnosti jako: … xslt

XSLT mi pomáhá např. zjednodušovat data – není potřeba se na to dívat jako na nějaké XML, text s ostrými závorkami, ten tam ani nikde být nemusí – prostě je to strom tvořený uzly různých typů a ten já chci převést na jiný strom s podobnou strukturou, ale zachovat jen některé uzly a jiné trochu upravit nebo nahradit něčím jiným.

> misto toho jsou ruzne filesystemy pro ruzne pouziti (male/velke soubory, read-only, komprimovane....)

Souborový systém je dobré lokální API, docela fandím různým FUSE souborovým systémům, která zpřístupňují data (třeba i z SQL databáze nebo XML) formou FS a uživatel může abstrahovat od toho, jak jsou data uložena a pracuje s nimi vždy stejně jako se soubory. Ale není to všemocné – např. nějaké dotazování se tam dělá dost špatně (leda přes nějaké virtuální adresáře). Ale jako primární (nevirtuální) úložiště toho FS nabízí hodně málo – právě proto se nad ním používají buď databáze nebo nějaké chytře navržené formáty souborů (indexy, metadata…).

> misto xml muze byt zase filesystem s textovymi, obrazkovymi, hudebnimi soubory. staci takovy filesystem zatarovat a mate v nem totez co v xml.

Pokud napíšeš SAX parser, který umí tu adresářovou strukturu nebo .tar načíst, tak máš v podstatě pravdu. V té své aplikaci jsem si jen tak z legrace přidal ukládání metadat o souborech do jejich rozšířených atributů. Je to pár řádků (doslova) a vliv na výkon není měřitelný, takže proč ne :-) Takže mám (meta)data jak v relační databázi, tak na souborovém systému a můžu k nim přistupovat z obou míst. Ale schválně, kde je to jednodušší a efektivnější? Radši napíšu SQL nebo XPath, než abych psal cyklus v BASHi a v něm parsoval/grepoval výstup příkazu getfattr a v nějakém IFu rozhodoval, zda soubor na výstup zařadit nebo ne. Nebo mi snad FS nabízí nějaké API, které by mi umožnilo vyhledat soubory, které mají např. atribut aaa = 123 a zároveň atribut bbb > 5 ? Až něco takového bude existovat, velice rád to budu pro jednodušší aplikace používat. Do té doby zůstávám u „obludností“ typu SQL a XPath.

BTW: úplně nejlepší by bylo SQL/XPath rozhraní k souborovému systému, které by umožnilo pomocí standardního jazyka provádět dotazy nad soubory a adresáři :-)

> takze filesystem je prirozena reprezentace stromu, vsecko ostatni lze udelat pomoci toho.

Ono to lze i bez FS – některé DBMS můžou pracovat nejen nad FS, ale i nad blokovým zařízením, např. LVM oddílem. Ovšem to „lze udělat“ znamená, že někdo musí napsat spoustu funkcí/metod obecně kódu – a většinou nemám důvod toto implementovat znova a znova ve svém aplikaci, ale použiji nějakou databázi, kde už je to hotové.

Myšlenky to jsou zajímavé, ale někdy mi ta snaha napasovat všechno na soubory přijde trochu moc kostrbatá – viz třeba příklad:

% cat /net/tcp/clone/ct1
44
% cd /net/tcp/44
% echo connect 128.2.194.80!79 > ct1
% echo ping > data
% cat data
pong

Trochu mi to připomíná současnou situaci kolem RESTu – tam je taky často vidět až křečovitá snaha udělat ze všeho „resources“ až těm lidem někdy uniká, že podstata té řešení úlohy je ve skutečnosti procedurální. Ano, i procedura se dá volat přes CRUD operace, ale není to ono…