Ukládat soubory do databáze nebo přímo na disk?

[Nota]

Zajima me nazor nekoho kdo provozuje nejakou sluzbu "weboveho uloziste".
Je lepsi ukladat libovolny typ medii do databaze nebo primo na disk a jake jsou vyhody/nevyhody?

[Reklama]

[Franta <xkucf03/>]

Databázový systém v konečném důsledku ukládá data (BLOBy) taky jako soubory na disk a nečiní mu to žádné problémy. Takže z tohoto pohledu tomu nic nebrání. Problém je spíš v tom, jak BLOB z databáze dostaneš ke klientovi. Většinou máš totiž vrstvy:

disk → DBMS → aplikace (Java, PHP, Python…) → HTTP server (Apache, Nginx)

A pokud máš soubory v databázi, tak je musíš protáhnout přes SQL rozhraní mezi DB a aplikací (např. v Javě si tam otevřeš InputStream) a pak mezi aplikací a HTTP serverem – v obou případech tam budeš s největší pravděpodobností v cyklu přehazovat data z jednoho „bufferu“ do druhého. Tzn. DBMS to tahá z disku do své paměti a předává do paměti aplikace a ta to předává ze své paměti do paměti HTTP serveru, který to následně předává klientovi. Tzn. problém není v tom, že by DB nezvládala uložení velkých dat, ale problém je v tom, kudy a jak ta data tečou potom. Zbytečně ti to zatěžuje aplikační server (který mohl dělat něco užitečnějšího než přehazovat bajty z jednoho místa na druhé) a aplikace se může stát i úzkým hrdlem, které to bude brzdit.

V případě souborů na disku pošleš z aplikace HTTP serveru jen cestu k souboru a HTTP server data servíruje rovnou z disku na síť. (samozřejmě bys to mohl dělat hloupě a číst v aplikaci data z disku a přehazovat je lopatou k HTTP serveru, ale proč bys to dělal, když stačí předat název souboru a dál se o to nestara?)

U některých DBMS je navíc problém v tom, že moc nezvládají defragmentaci, takže i když data smažeš, pořád ti zabírají místo. Zatímco souborový systém by se celkem v pohodě defragmentoval a uvolněné místo použil pro nové soubory.

Naopak argumentem pro soubory v DB jsou transakce a 100% konzistentní zálohy. Pokud máš data mimo DB v souborech, musíš si tohle ošetřit sám (ale není to zase tolik práce navíc).

Pokud je těch dat málo a nehrozí výkonnostní problémy, tak můžou převážit výhody uložení v DB – bude to na jednom místě, nebudeš muset nic řešit, zálohovat se ti bude vše najednou… – jinak bych ale volil spíš uložení do souborů a jejich přímé odesílání HTTP serverem (sám jsem to implementoval na svém webu a nebylo to moc práce navíc).

--
https://blog.frantovo.cz/

[PanLopata]

Otázka je, do jaké databáze. Pro tento účel vznikly blob storages. Často zneužívaná relační databáze na to není ideální - file data mají obvykle jiný charakter než relační data, takže pak vznikají problémy s maintenance a recovery plány, správou, rychlostí a škálováním.

[Tomas2]

file system je také databáze .

Databáze tak jak to myslíš ty se volí, protože lépe škáluje přes více serverů, u filesystému to je problematické. Pokud už se používá file system, běží nad nějakým diskovým polem či NASem (jeden český uložišťový projekt používá třeba emc isilon) kvůli replikaci a zálohám.

Běžně se také na tohle používá riak, cassandra, hadoop, gfs a spousty dalších technologií.

Nelze ti ale poradit obecně, je potřeba znát plánované velikosti souborů, počty a velikosti zápisů a čtení v čase. Něco jiného je dělat např. streaming pro českou televizi v období olympiády a něco jiného je dělat sdílené uložiště pro firmu o deseti zaměstnancích.

Relační databáze nejsou dobré s prací s velkými soubory, často to pak ani vůbec nefunguje (1 GB soubor do MSSQL je dost peklo). Ukládat zase  do file systemu není vhodné na velké množství malých souborů (10 M souborů dokáže pěkně pozlobit nejeden file system).

[Filip Jirsák]

To je věčný spor, na který neexistuje jednoznačná odpověď. Souborový systém je databáze vyladěná pro ukládání souborů, z hlediska efektivity je nejjednodušší soubory ukládat tam. Na druhou stranu, když soubory ukládáte do databáze, máte jistotu, že data jsou konzistentní, i v zálohách – nestane se vám, že máte na disku soubor, ke kterému chybí záznam v databázi, nebo naopak záznam v databázi, ke kterému chybí soubor. Soubory na disku se snáze zálohují, můžete dělat rozdílové zálohy. Databázi můžete mít replikovanou, ale když budete chtít udělat zálohu pomocí dumpu, celý ten objem uložených souborů se vám nahrne do toho dumpu, se kterým musíte pracovat jako s celkem. Když budete ukládat soubory na disk, můžete snadno škálovat na objem dat tím, že budete ukládat na více zařízení. NoQSL databáze zase často umí škálovat na více zařízení samy.

Já osobně bych pro službu typu „webové úložiště“ volil ukládání do souborového systému, protože pak můžete soubory z webového serveru odesílat s minimální režií, a můžete jinak škálovat a jinak zálohovat metadata a jinak samotné soubory. Ale jak jsem psal, je to věčný spor a otázka spíš osobního vkusu a zkušeností s různými technologiemi.

[Reklama]

[Michal2]

Metadata souboru do databáze, soubory na FS.

FS snadno škáluje (rozshardovat ho na víc serverů je triviální task), lépe se zálohuje a obnovuje (o obnově ze zálohy snad ani nemusím psát o kolik snadnější je vytáhnout ze zálohy jeden potřebný soubor než někam bokem obnovit celou mnoha-TB databázi abych ten jeden soubor dostal z BLOBu), má menší výkonnostní a velikostní overhead.

[Kit]

Nejříve si odpověz sám, o jaké typy souborů jde a do jaké databáze bys je chtěl uložit. Vlastně není moc typů souborů, pro které by se to hodilo. S obrázky ani s filmy bych to rozhodně nedělal.

Metadata souboru do databáze, soubory na FS.

Přesně.

[asdf111]

Odpoved je presne medzi, object storage, s3, swift, alebo nieco podobne