Ukládat BLOB do databáze nebo do filesystému? Tuhle otázku si asi položil každý kdo někdy dělal do DB. A každý má na to svůj (jediný správný) názor. Jenže málokdo má svá data podložené testy, protože se do toho nikomu nechce. Zřejmě se každý bojí – a to oprávněně – že ho lidi sepsují kvůli špatné metodice, proč neměl v konfiguraci totok a proč tam měl tamtok, když to tam být nemá…
A data žádná nejsou. Až tento týden jsme objevil zajímavou práci To BLOB or Not To BLOB: Large Object Storage in a Database or a Filesystem? ABS. Samozřejmě i já mám k metodice výhrady (data přístupná přes SMB – pche, MS SQL – pche). Ale převažuje nadšení z pěkné práce o kterou se dá opřít a na které stavět.
Pokud jste líní si to přečíst, tak závěr je takový, že pro malé objekty ( < 256kB) je rozhodně lepší ukládat do DB. Pro velké objekty ( > 1MB) je rozhodně lepší ukládat do FS. Mezi tím je mlhavá hranice a silně záleží na druhu aplikace. Pokud se data často přepisují, tak je lepší spíše FS (lépe se vyrovnává s fragmentací). Pokud se data nepřepisují, tak je lepší DB (větší propustnost malých objektů).
No, ono to totiž dost záleží na druhu aplikace a databáze. Pokud chci plnou transakčnost aplikace, těžko tam budu zanášet netransakční prvky (na filesystému prostě ROLLBACK neuděláte). Na druhou stranu pokud budu používat MySQL tak ten soubor je asi fakt lepší, vzhledem k tomu že MySQL pracuje s BLOBy hodně stupidně.
Pokud si vzpomínám, tak Oracle umí BLOB pouze vysypat z DB na FS, kdežto MS SQL ho umí přímo vrátit.
Jinak transakční zpracování na FS není takový problém, máme ACID transakční FS (TxF).
U PostgreSQL jsou ty limity asi nekde jinde. Zhruba do 6MB (zalezi na velikosti pameti) se bez blobu pohodlne obejdete a klidne lze pouzit text nebo bytea. Nad uz je to na uvahu. BLOB ma tu vyhodu, ze pokud se klient dokaze pripojit, tak k nemu dokazu dostat data jednim kanalem. Coz ma smysl, pokud k databazi pristupuje vic aplikaci.
Jinak zmineny test je pouze pro MS SQL a pro NTFS. Pro cokoliv jineho nema zadny vyznam.
Celou studii jsem nečetl. Ale zabývá se taky někdo uživatelskými právy? V DB se to jednoduše nagrantuje a to stejným způsobem jako přístup k jiným tabulkám/sloupečkům. V souborovém systému je potřeba mít nějaký další autorizační mechanismus. A kdo se s tím má patlat? Dělat jednu věc na dvou místech...
[6] Oracle s tim opravdu nema problem - jen se prace s xLOBy mirne meni a tak treba nejde pristupovat pres starsi OCI k novejsim DB. AFAIK v7, v8, v9 i v10 xLOBy propusti na klienta celkem bezproblemove (sedmicka byla v tomto misty blba a potrebovala nejake berlicky, ale slo to).
Ad ukladani do FS. Asi bych v pripade Oracle taky nechtel ladit problemy, ktere nastanou s transakcemi, vicenasobnym pristupem apod. Pokud to budu resit nejakym transakcnim FS, tak to uz muzu ukladat rovnou do DB, nebo se pletu? Navic jakmile sahnu po nejakem reseni typu Oracle RAC (Real Application Cluster), tak mam dalsi problemy. Oracle snad do fulltextu umi zahrnout i BFILE (nepouzivam je, takze si nejsem jisty), ale muze to byt dalsi prekazka, proc data neukladat mimo DB.
Ono je taky duleziny vedet co v tech datech mate a jak jsou ta data pro vas dulezita. Pokud v Oracle pouzite datavy typ BFILE, tak se data ukladaji mimo kontext transakce a obsah takovych 'blobu' se nekopiruje do redologu(a archredologu). Takze urcite dosahnete vetsiho vykonu, ale prijdete o hlavni vyhodu databazoveho zpracovani a tou je ochrana dat. Jeste bych dodal, ze API oracle pro BFILE je naprosto debilni. Z OCI se z klineta nedaji BFILEs zapisovat vubec a teprve od verze 10g je mozne ulozit vice nez 32KB binarnich dat. Cely UTL_FILE bylo delany na textovy soubory a tak vam DB vklada <CR> nebo <CR><LF> i do binarnich dat.
Co se tyce starsich verzi, tak BLOB se objevil ve verzi 8 a predtim se pouzival datovy typ LONG. Ten mel spoustu nekdy naprosto neocekavanych omezeni proto by se nemel pouzivat.
ČLÁNKY DO MAILU