Dotaz: postgres ukladani binarniho souboru

[jirkamailto]

Dobry den, potreboval bych ukladat do databaze POSTGRES nahrane soubory. V javovske aplikaci muze uzivatel nahrat soubor, pdf, obrazek a dalsi, uzivatel v tomto neni omezen. Mam napad, ze bych vsechny tyto soubory prevedl na retezec a pote je ukladal do databaze jako "text". Nezkousel jsem to, a nevim jak to pujde. Co jsem hledal, existuje v databazi i specialni datovy typ na soubory. Tusim ze bytea. Potreboval bych se zeptat, jaky zpusob je lepsi, jestli soubor prevest na retezec a ulozit nebo pouzit ten specialni datovy typ a to i z hlediska pouzitelnosti v ramci javovskeho ovladace k postgres databazi. Predem dekuji za odpovedi.

Odpovědi

[Šangala]

Obecně bych binarní data na nic nepřeváděl a BYTEA datový typ nevím jak je vhodný na soubory a třeba 10MiB velké (jestli se nepletu tak i proces je limitován na všech vrstvách dostupnou či přidělenou pamětí).
Spíše použít BLOB.
O propojení s Javou asi tady.

[okbob]

Plete te se. Velikost Bytea je limitovana 1G a nijak nesouvisi s limity, ktere jsou v PostgreSQL pro pamet.Jelikoz se ale s Bytea nepracuje proudove, jako s BLOBem, tak se pri zpracovani alokuje cca dvojnasobek az trojnasobek RAM co je delka hodnoty - coz pro velikostech nad 50MB uz muzete byt poznat. Coz je duvod proc se s Bytea a dalsimi varlena typy konci nekdy do 10-50MB.

Pro 10MB bych klidne pouzil Bytea, nad pak spis BLOB. Fakticky velke Bytea polozky a BLOBy se pak v db ulozi velice podobne - rozdil je hlavne v tom jak je dostat z/do db.

[Šangala]

Jsem to nedostatečně popsal, nevěděl jsem jaký je limit BYTEA sloupce.
Myslel jsem tím, že ten přenos do tabulky je omezen na všech vrstvách a to právě tím, že se přenáší jako klasický SQL dotaz a vstupují do toho limity, jak serveru (když ho máte třeba na 512MiB RAM), tak i limity (a přidělené zdroje) aplikace či použitého „providera“ k přístupu do DB.
Takže dík za upřesnění.

[Radim Kolář]

Hlavne ty bloby nefunguji v auto commit modu a to ani pro cteni. To rozbije dost Java aplikaci. Dokonce ani hibernate to neumi zaridit aby to slo transparentne pro aplikaci kdyz uz to neemuluje driver.

[jirkamailto]

Jak to tak vypada, tak nakonec pouziju prevedeni do retezce, protoze pouzivam knihovnu MyBatis3 na ORM.

[jirkamailto]

Dekuji za nazor, zkusim tu byteu. Ty soubory hodlam prilozit k mailu, tak budu muset nejak limitovat velikost souboru, protoze spravci mail serveru limituji velikost mailu ruzne, tak abych tam mel rezervu a mail v drtive vetsine pripadu prosel.

[Justas]

A bude se s tím souborem v databázi nějak pracovat (vyhledávání, třídění, ...)? Pokud ne, doporučím ten soubor uložit do separátního adresáře, a do databáze si zavést jen informaci, který soubor to je. Výhodou by měla být podstatně větší rychlost.

[jirkamailto]

Se souborem pracovat nebudu. Kdyby to byla ciste webova aplikace, tak bych jiste volil ukladani na disk, ale bude to klient server aplikace, a tudiz kvuli privetivosti ke sprave a zalohovani ukladani na disku nechci.

[Heron]

Výhodou by měla být podstatně větší rychlost.

A nevýhodou omezený počet takových souborů ve filesystému a neexistence transakcí, což znamená, že se to (vazba na DB) rozpadne při nejbližší příležitosti.

[l0gik]

Omezenej počet souborů ve filesystému? Eh? Samozřejmě, některý filesystémy nemaj rádi hodně souborů v jednom adresáři, ale to se snadno vyřeší např. ukládáním do adresářů např. po tisících. - To s transakcema je pravda, ale vzhledem k tomu, že jde dělat copy on write plus garbage collection (soubor na disku bez záznamu v db s datem vytvoření starším, než nejstarší transakce v db) tak i to je snadno řešitelný.

[Heron]

Tak samozřejmně záleží o jakém počtu se bavíme. Já mám praktické zkušnosti se stovkami milionů, kde FS (jakýkoliv) šel do kolen a DB o ničem neveděla. Nakonec i na mailling listech systémů souborů posílají tazatele s dotazem na ukládání mnoha souborů do databáze.

že jde dělat copy on write plus garbage collection (soubor na disku bez záznamu v db s datem vytvoření starším, než nejstarší transakce v db) tak i to je snadno řešitelný.

Ano, existují způsoby jak to vyřešit, ale o toto se bude muset vždy starat vrstva (program) nad fs i db. A já osobně si myslím, že o související data (referenční integrita) by se měla starat jen jedna vrstva, v tomto případě databázová.

[Šangala]

To je nekonečná otázka, která nemá asi jednoduchý závěr.
Přírůstkové zálohování se bez speciálních nástrojů zas lépe dělá na filesystému.
Praktickou zkušenost z takovým počtem nemám, ale přes 70 mil. maličkých souborů jsem testoval na běžném nijak neladěném ext3 na běžném disku, ID ukládané v 64-kové soustavě dvě písmena tři úrovně (tedy na adresář 4096 položek) a nezaznamenal jsem žádný problém.

V případě dokumentu jako externích dat, postačuje očekávat, že tam dokument je, což lze zařídit docela spolehlivě nadřazenou aplikační transakcí (stejně takových transakcí probíhá spoustu, o tom to programování je ). A i databáze se musí sem tam kontrolovat (<joke>viz dohledávání zásilky PPL celý tento víkend</joke>), tak lze také kontrolovat i externí úložiště a jeho integritu vůči db. Jediné co se musí zajistit je, aby možný přístup do úložiště byl jen jeden (přes jedno rozhraní).

[l4m4]

Pokud se bavíme o velkých souborech, jak diskuse naznačuje, tak by omezení počtu (typicky alespoň 2^31) takový problém být neměl: místo dojde mnohem dřív než počet. Transakce samozřejmě problém jsou (což je smutné, protože db na ukládání gigových blobů není efektivní backend).