Administrace komentářů

Vím, že přecházím z extrému do extrému, ale chci prijít na podstatu současného stavu. FS používáme z historických důvodů, databáze také. Přitom se v obou případech jedná o databáze s různými nároky na ACID. Proč se používají FS, když ACID nevyhovují a ani nejsou výkonnější? Proč je nezahodíme a nenahradíme všechny FS databází?

Jsou to dva různé způsoby ukládání dat. Oba (FS a DB) poskytují zcela jiné služby a mají jiné použití, výhody a nevýhody.

FS poskytuje blok dat (adresovaný od 0 do filesize, přístup blokově a nebo streamem) a nezajímají ho ta data samotná (nerozumí obsahu souboru a ani se o to nesnaží). Je to nejrychlejší možný způsob (tedy kromě RAW přístupu k disku, který se také používá na ukládání dat, klidně svá data můžeš ukládat jako jednotlivé sektory disku a fakticky si tak vytvořit vlastní FS, jde to) přístupu k datům. Proč se používá je jednoduché. Pokud má program data v nějaké struktuře v bloku paměti, tak jednoduše ten blok vysype do souboru. Staré 8bit, DOSové hry takto měli řešení ukládání herních pozic a některé programy to tak používají dodnes. Na velká sekvenční data (multimediální soubory například) je to ideální způsob uložení (i když by video šlo logicky rozdělit na jednotlivé framy a ty uložit pod nějakým pořadovým číslem do DB, tak toto by nepřineslo vůbec žádné výhody; najít ve velkém souboru konkrétní frame se umí i jinak a efektivněji).

FS také řeší rychlost přístupu k datům (velkých objemů) snižováním fragmentace a také snižováním seeků (pohyb hlaviček) u rotujících disků (u SSD toto odpadne, tam se budou řešit jiné problémy).

Toto byly výhody FS. Nevýhodou je adresace záznamu (souboru) pouze pomocí primárního klíče (plná cesta), malý počet souborů a neefektivní ukládání malých souborů (vždy jeden blok). Což ale všechno plyne z toho, co má FS být. FS prostě poskytuje blok dat adresovaný jedním primárním klíčem (jménem souboru) a offsetem (pozicí v souboru). Nic víc (pokud vynecháme metadata, ale o tom tu řeč není).

FS nemá nic jako transakce. Má jisté atomické operace (například přejmenování), pomocí kterých jde něčeho jako transakčního chování dosáhnout. Maildir například má adresář cur (new) a tmp. Soubor emailu si připravuje v tmp a až je celý hotový, tak jej atomicky přesune (přejmenuje) do adresáře cur (nový tedy do new). To už je takové drbání se levou nohou za pravým uchem. Šlo by to zobecnit samozřejmě i pro více záznamů (souborů) tak, že se vytvoří adresář někde bokem a pak se tento adresář přesune do "ostré" stromové struktury. Nevím, jestli tuhle šílenost někdo používá.

Další nevýhoda FS je drahá operace sync, kterou se mnozí programátoři snažili různě obcházet (jednoznačně jejich chyba a neznalost, šlo to udělat jinak) až se z toho nakonec stal patch do ext4 (který jinak ztrácel data při pádu stroje), který má za úkol se pro některé aplikace chovat stejně jako ext3 (default commit po 5s). DB ti to commitne bezpečně na disk bez většího výkonového dopadu na další operace.

Opačným extrémem je relační SQL DB. Jako mezi tím jsou ještě keyvalue (velmi vhodné pro jistá data), readonly archivy (takto některé programy obcházejí přílišný počet souborů, mají zip archiv a v tom adresářový strom s mnoha soubory, je to rychlé, protože readahead OS postupně načte tento zip celý do RAM a navíc se nemusí seekovat po jednotlivých souborech na FS, je to jen v jednom) a další způsoby ukládání dat, které lze zvolit pro řešení problému, není nutné a ani vhodné se při výběru přepínat jen mezi FS a SQL.

Relační DB potřebuje rozumět ukládaným datům (je velmi důležité správně zvolit datový typ a neodpustím si poznámku: fakt mi vstávají vlasy hrůzou, když někde vidí IPv4 uloženou jako VARCHAR (15), tedy 15B+značka velikosti na místo 32b INTu, 4B), umí záznam velice rychle adresovat i pomocí dalších klíčů (z klíčů vytvořených na základě obsahu dat, to FS vůbec neumí), umí efektivně (z hlediska rychlosti i z hlediska efektivity uložení) pracovat s velkým množstvím záznamů, umí transakční zpracování přes širokou řadu úkonů a s různými počty záznamů apod.

Databáze řeší konkurenční přístup (DB od svého vzniku musí řešit přístup a operace stovek klientů nad jedněmi daty, to se na FS většinou řeší pomocí zámků nebo pomocí šíleností jako jsou ta přejmenování z dočasného adresáře), práva (ale to i ten FS), garantované sekvence napříč klienty.

a ani nejsou výkonnější

To chce trochu upřesnit. FS je rozhodně rychlejší pro (střední a velká) sekvenční data. 1GB soubor se přečte rychlostí HW (disku, případně RAM), s tím bude mít DB (která to bude mít interně v 2kB blocích) trošku problém (ale zvládne to). Ale o tom se tu až tak moc nebavíme. FS není vůbec výkonnější při nevhodném použití jako DB (a to ani jako primitivní keyvalue). Například vyhledat všechny záznamy, ve kterých jsou data "Nick: Kit" DB zvládne levou zadní (pokud někdo nezprasil schéma), pro FS to bude znamenat progrepovat všechny soubory (čímž se zahodí původní stránky v IO cache (naplní se novými daty) a pak se další souboru budou muset číst opět z disku). Vůbec ta cache je hlavní devízou DB systémů.

Vždy záleží na konkrétním použití a konkrétním typu dat. Já nejsem přítelem různých adresářových stromů s tisíci soubory (jako je například i ten maildir), na toto FS ani není určený. A pokud se někdo chce vyhnout tomuto stromu a řešit si to sám v nějakých vlastních datových souborech, mno, to už je lepší využít 30let zkušeností špičkových světových programátorů a fakt to vrznout do DB.

Výběr vhodné technologie je těžká věc. Já jsem se (a klidně to přiznám) možná dostal do stavu, kdy mám v ruce kladivo (DB) a všude kolem vidím hřebíky. Na druhou stranu mi DB poskytuje výhody, které FS nikdy nenabídne, a vývoj (i FS, či spíše nástaveb) směřuje spíše k té DB. Souboru už máš dneska otagované (ten jeden přimární klíč už fakt pro uživatelskou práci nestačí), indexované podle obsahu (což je přesně to, co dělá každá pořádná DB) pro vyhledávání, různé media-library ti nabízí mnoho pohledů na jedna data apod.