Jiří Hradil blog

o software


Téma: ukládání dokumentů na serveru

Představme si následující situaci. Máme vlastní informační systém, který běží na straně serveru (na Javě, PHP…) a klientům zasílá vygenerované HTML či XHTML stránky.
Hlavní komunikaci klienta se serverem zprostředkovávají formuláře.
Systém by měl fungovat jako datový sklad pro dokumenty, uploadované na server společně s připojením popisných údajů-vlastní název souboru, poznámky, propojení s nabídnutým číselníkem, atd.
Popisná data dokumentu budeme ukládat do databáze, ale co se samotnými dokumenty, které můžou být také binární data-obrázky, mp3, všemožné doc, xls?

Nabízí se několik možností:

Popisná data uložíme do databáze (DB) a dokument přímo do filesystému (FS) na serveru. Součástí popisných dat v DB bude odkaz na tento dokument ve FS.

  • + Dokumenty ve FS je možné sdílet a přistupovat k nim i jinak, než jen přes rozhraní systému. Třeba jen pro čtení. V Linuxu lze nastavit sdílení složky s dokumenty např. přes Sambu a klienti mají možnost otevírat soubory přímo ze serveru, což může být někdy rychlejší, než přistupovat přes browser.
  • + Dokážeme tak ukládat i velké objemy dat (mnoho velkých dokumentů). Protože databáze uchovává pouze popisná data, mohla by být menší a rychlejší.
  • +/- Data na dvou místech - pokud spadne DB, dokumenty máme jinde (řeší kvalitní záloha). Avšak musíme se starat o zálohu dvojí.
  • - Obtížná implementace fulltextového prohledávání dokumentů. Pokud umíme pracovat s určitým typem dokumentu, pak výsledky vyhledávání zřejmě budeme muset taky ukládat do databáze. Pak by v DB byla popisná data a výsledky fulltextu. Odkaz na dokument ve FS.
  • - Neustále je třeba kontrolovat konzistenci dat, pokud se smaže dokument v DB, musí se smazat i ve FS a naopak. Tohle je asi největší problém.

Vše uložíme do DB. Binární data dokumentu budou jako datový typ blob, bytea, large object, apod.

  • + Vše na jednom místě. Vyřešíme tím dokonale provázání popisných dat a dat dokumentu.
  • + Fulltextové prohledávání (pokud umíme s daty dokumentu nějak pracovat) bude řešit DB.
  • ? Rychlost a náročnost DB. Tady opravdu netuším, jaké bude mít DB odezvy, pokud v ní budeme mít několik GB dokumentů.

Téma: Co si myslíte o jednotlivých řešeních? Napadá vás nějaký jiný, rozumný a pokud možno co nejjednodušší návrh?

Publikoval Jiří Hradil • 28.04.2004 v 23:04 • pod kategorií Nezařazené •

6 komentářů k “Téma: ukládání dokumentů na serveru”

  1. Myslim, ze to prve riesenie je lepsie a robustnejsie. Problemy uz pri niekolko MB mozu nastat pri menej vykonnych DB, niekolko GB si ani neviem predstavit. Zaroven akasi indexacia (napr. popis dokumentu v DB) moze byt vybornou vecou, takze jednoznacne kombinacia DB+filesystem.

    Comment od dusoft on 30. 1. 2007 at 18:51



  2. Copak, pises to a nevis co si vybrat?

    Osobne se priklanim k reseni 1. Ty minusy co tam uvadis..

    indexace - to je vec metadat, nemusi byt vazana s dokumentem jinak nez prez nejake to ID..

    konsistence - pri alespon trosicku rozumnem navrhu se resi tak nejak sama.. coz koliduje s lozenim klientu primo do FS, pokud nemaji RO pristup (+ 1).

    data na dvou mistech - stejne tak ti muze spadnou FS. Navic aj DB aj FS uz dnes obvykle mivaji nejaky ten zurnal.. samozrejme pokud nepouzivas kombinaci FAT32 + Access

    Comment od Jarda on 30. 1. 2007 at 18:51



  3. Diky za nazory.
    Kazdopadne bych uvital praktickou zkusenost s ukladanim velkeho mnozstvi dokumentu primo do databaze.

    Comment od Jirka Hradil on 30. 1. 2007 at 18:52



  4. Správně navržený systém řeší konzistenci dat automaticky. Řekněme, že existuje jedna funkce, která ma na starosti smazání záznamu z DB, a zároveň tato funkce smaže i dotyčný soubor na FS. Na FS přímo mazat nejde. Zkrátka místo přímého vstupování do databáze vytvořit třídu, která je schopna s databází pracovat, a zároveň si hlídá FS. Pak není problém, ne?

    No a to stejné indexace - opět v oné tříde vznikne funkce Search, která si vše řeší ve vlastní režii.

    Zkrátka programy využívající této třídy ani nemusí vědět, co je v DB a co ve FS. Fungování bude transparentní.

    Comment od dgx on 30. 1. 2007 at 18:53



  5. Jak by rekl nas koryfej e.e. Velky Kecalista: to je naprosto ale naprosto spatne polozena otazka Obe dve varianty jsou totiz dobre. Proste varianta 1 s tim, ze se se serverem nekomunikuje dvěma protokoly (db a soubory)ale jednim novym zajistujicicm konzistenci. Z tohoto pohledu pak jde o variantu 2 kdy ovsem databaze neni ciste relacni. Pokud jde o konkretni zkusenosti, tak bohuzel nemohu slouzit, ale nejaky databazovy file system delala IBM (co ale IBM nedelala, ze) A nejbliz popisovanemu maji groupware prodikty - ibm notes, ms exchange atd.
    P.S. e.e. znamena extremni egoista

    Comment od plankton on 30. 1. 2007 at 18:53



  6. - nativni XML databaze
    - relacni databaze s podporou XML (Oracle?)
    - napsat si to sam - XML ukladane do databaze
    - koupit hotove DMS reseni (ala Filenet P

    Comment od Ondrej Valek on 30. 1. 2007 at 18:54



Komentovat

Security Code: