Dotaz: Soubory MySQL vs. Filesystem

[Smudla2]

Zdravím, mám takový začátečnický dotaz. Máme navrženou databázi (vytvořené tabulky naplněné daty) v MySQL. Nyní bychom rádi do jedné tabulky databáze vkládali (příslušné položce tabulky) i soubory (přes atributy FILE_ID či URI). Tyto soubory bysme chtěli uchovávat mimo databázi někde na filesystemu. Problém je v tom, že nevíme, jak toto realizovat. Co vše musíme udělat pro to, aby šli soubory vkládat a získavát? Chceme mít rozhraní v Javě na PC (např. notebook), které do příslušné položky tabulky v databázi udělá záznam o souboru (např. URI) a zároveň tento soubor uloží na filesystem (např. na jiný server než běží samotná databáze). Z tohoto rozhraní by mělo jít zároveň tento soubor získat. Databáze MySQL beží na linuxovén serveru.

Díky za každou radu či příklad.

Martin

Odpovědi

[cronin]

To, čo opisuješ, sa v praxi bežne používa. Riziká sú v zásade dve. Poprvé musí byť konzistencia väzieb medzi údajmi v databáze a na disku udržiavaná aplikačne, t.j. mimo samotnej databázy. Takáto konzistencia je krehká a je viac-menej len otázkou času, kedy bude narušená. Viac informácií Ti poskytne akákoľvek seriózna kniha o návrhu aplikácií pre relačné databázy. Podruhé je zložitejšie robiť zálohovanie, a tu sú opäť riziká dve: Poprvé treba zálohovať dve údajové úložištia, databázu a súborový systém, čo je minimálne nepohodlné. Podruhé je problém urobiť konzistentnú zálohu, t.j. transakčne konzistentný snapshot týchto dvoch nezávislých úložíšť; zvyčajne je to možné iba v offline režime. A vlastne celkovo je problém zabezpečit transakčnosť operácií nad databázou a zároveň nad súborovým systémom; distribuované transakcie sú doménou databáz značne iného rangu ako je MySQL, a transakčnosť nad súborovým systémom je jemne povedané problematická; pritom práve databáza je práve oný prvok, ktorý rieši mimoiné aj transakčnosť uloženia údajov na súborový systém.

Takže ešte raz: to, čo opisuješ, sa v praxi bežne používa. Jedna z prvých požiadaviek na zmenu takto navrhnutého softvéru zvyčajne je umožniť ukladať kompletný obsah do databázy.

[Filip Hesse]

Ano, tak nějak. Těch nevýhod je si myslím víc, než při ukládání souborů přímo do BLOBu v databázi.

Hodně se mluví o zpomalení databáze při použití BLOBů. Nevím, jak to má MySQL, ale tato hlavní nevýhoda se dá eliminovat použitím jedné tabulky pro informace o souboru (z této tabulky se bude vyhledávat, bude možné ji JOINovat jinam) a druhé tabulky se samotným BLOBem, s vazbou 1:1 na první tabulku, do které se sáhne teprve při potřebě se souborem pracovat.

Trochu by pomohlo vědět, o jaké soubory se jedná. Můj přístup se bude hodit při databázi zaměstnanců na uložení JPEG. Určitě se nebude hodit na databázi filmů, kde se bude ukládat DVD.ISO.

[Josef Kufner]

Pak je ještě možnost do DB soubory uložit a cachovat je na disku, kde bude moct httpd k datům přistupovat i bez pomoci aplikační logiky (např. php). Ale i to má své drobné mouchy...

[Michal2]

Nekde delali mereni jak rychle trva vytazeni souboru ruznych velikosti z databaze (MySQL, MyISAM tabulka) vs precteni z disku (ciste select blob from tabulka where id= oproti fopen a fread, tabulka mela stejna zaznamu jako adresar souboru, merila se latence za jak dlouho bude mit v obou pripadech aplikace data nactena a zatizeni procesoru). Kdyz probehlo cteni v obou pripadech z diskove cache tak byla latence ziskani dat MySQL oproti filesystemu 50x vetsi kdyz byl mysql server na stejnem stroji jako aplikacni server, pokud to bylo na serveru jinema mysql slo pres tcp a soubory pres nfs tak to bylo z hlediska filesystemu jeste lepsi. Kdyz se data cetla z disku tak byly rozdil 1:3 ve prospech filesystemu.

Jinak take zjistili, ze velke bloby v databazi uspesne flushuji buffery coz ostatnim operacim nad databazi moc neprospiva.

Takze ano, pouzit se to da ale pozor na vykon.

[Ivan]

Hmm, ja delal mereni Oracle vs. JFS na AIXu a od 10^4 souboru v jednom adresari vedl Oracle. NFS poskytovalo nekonzistentni udaje, a kdyz jsem namontoval filesystemy s parametrem noac, tak bylo NFS nepouzitelny.

[Michal2]

Njn, od nekolika stovek zaznamu se oplati udelat hierarchie treba 12/34/56.jpg. Takto narves milion souboru do struktury pricemz tam jevzdy max 100 souboru/adresaru v adresari a dvoji traverzace nestoji skoro nic.

 

[Messa]

Ja osobne preferuji ukladat data do souboru a do databaze ukladat jen odkazy na ne (napr. nazev souboru). Myslim si, ze se to treba lepe zalohuje, kdyz je dump databaze radove mensi, na rozdilovou zalohu filesystemu existuji lepsi nastroje. Konzistentni zaloha nemusi byt problem, zalezi na tom, jak ta aplikace pracuje.

Pokud je problem v tom, ze aplikace neni zcela pod kontrolou a nemusi nekdy dodrzet konzistenci mezi db a filesystemem, resenim je pouzit (vytvorit) aplikacni server, ktery to nahravani souboru bude obstaravat, a uzivatelske aplikaci pristup do databaze treba i zakazat :)

V praxi se vyskytuji i pripady, kdy je jednim z prvnich pozadavku ukladat velka data do souboru misto do databaze :)