Posizione consigliata per l'archiviazione di documenti - in database o altrove?

StackOverflow https://stackoverflow.com/questions/512262

Domanda

Sfondo:

Abbiamo una casa di archiviazione dei documenti di sistema che è stato implementato molto tempo fa.Per qualsiasi motivo, l'utilizzo di database come il meccanismo di archiviazione per i documenti è stato scelto.

La mia domanda è questa:

Qual è la migliore pratica per l'archiviazione di documenti?Quali sono le alternative?Quali sono i pro e i contro? Le risposte non devono essere tecnologia o piattaforma specifica, è più generale di una best practice domanda.

Il Mio Pensiero:

I database non sono destinati per l'archiviazione di documenti.I Sistemi di File o 3rd party sistemi di Gestione dei Documenti può essere di meglio.Documento di Archiviazione in Database è costoso.Le operazioni sono lente.Sono queste logica ipotesi?Forse questo è il migliore, ma nella mia mente, ci sono alternative migliori.Potrebbe oracle BFILE (il link al documento su NAS o SAN) essere migliore di BLOB / CLOB?

Dettagli:

  • I documenti sono di vari tipi (pdf, word, xml)
  • Livello intermedio codice è scritto in .net 2.0 / c#
  • I documenti sono memorizzati in un database Oracle 10g in BLOB con la compressione (Storage NAS)
  • Le dimensioni dei File rabbia
  • Il numero del documento che cresce drasticamente e non ha segni di rallentamento
  • Inserti è di solito è in centinaia all'ora durante il picco di
  • Retreival è tipicamente in migliaia all'ora durante il picco di
  • Storage NAS e SAN archiviazione è disponibile

AGGIORNAMENTO (da domande qui di seguito):

  • il mio background è in sviluppo
  • c'è associato meta-dati sui file memorizzati accanto al file nel database
È stato utile?

Soluzione

L'unico limite per la conservazione dei documenti nel database tecnologico.

Un relazione database è pensato per essere un archivio permanente dei dati mission critical di un'impresa.Come ben si può eseguire questa funzione varia da un database e un sistema all'altro, naturalmente.Ma idealmente il ACIDO proprietà di un di database relazionali sono inteso per rendere l'archivio di tutti dati aziendali.Il file di sistema, revisione sistemi di controllo e di altri locali di stoccaggio, sistemi hanno vantaggi specifici, ma essi non sono progettati per data storage enterprise come tale.

Se i documenti sono memorizzati qualificarsi come impresa di dati - se utilizzato in modo persistente attraverso l'enterprise, quindi è logico mantenere nel database.Se si stanno avendo problemi con la memorizzazione nel database, forse un DBA può trovare una soluzione migliore.Si potrebbe anche avere per spostare il database per motivi di prestazioni, ma non credo che si dovrebbe spostare il database per le migliori pratiche di motivi.

Naturalmente, se i documenti non sono dati dell'organizzazione, se sono utilizzati solo per una domanda, diciamo, di portarli fuori il database potrebbe anche avere un senso.

Altri suggerimenti

Sulla base della mia esperienza, direi di tenerli in un database.Abbiamo spostato di due dei nostri sistemi per fare questo.

Metterlo nel database:

  • E ' di facile accesso, anche da più server
  • È il backup automatico (invece di dover avere un processo separato per farlo)
  • Non è necessario preoccuparsi di spazio (dato che le persone a mantenere il DB da un eccessivo riempimento del disco, ma potrebbe dimenticare di controllare dove i documenti vengono archiviati)
  • Non è necessario avere un complicato schema di directory

Abbiamo avuto i documenti del database.Diventa un problema con un sacco di documenti.Una normale directory in Linux è un blocco, che di solito è 4K.Abbiamo avuto una directory 58MB perché ha avuto così tanti file in esso (era solo un piatto directory, nessuna gerarchia).Aveva che molti indiretta blocchi.Ci sono voluti più di un'ora per eliminare.Ci sono voluti pochi minuti per ottenere un conteggio del numero di file nella directory.Era abissale.Questo è ext3.

Con il filesystem è necessario:

  • Separato meccanismo di backup (dal DB di backup)
  • Per mantenere le cose in sync (in modo che il record non esiste nel DB senza che il file non c')
  • Una gerarchia per la conservazione (per evitare il problema sopra elencato, in modo che nessun directory finisce con 10.000 s di file)
  • Qualche modo per vedere da altri server, se avete bisogno di un cluster (quindi, probabilmente, NFS o qualcosa del genere)

E ' davvero un dolore.Per qualsiasi numero non banale di documenti, mi raccomando contro il file system basato su quello che ho visto.

Preferisco salvare il documento nel file system e poi memorizzare un collegamento al file e file associato meta-dati nel database.

Si è dimostrato più conveniente, più facile da mantenere e meno costoso rispetto alle alternative.

La maggior parte di classe enterprise sistemi di gestione dei documenti NON memorizzare i file oggetto nel database.Solo perché si può non significa che si dovrebbe.Se la scalabilità e le prestazioni sono importanti per voi, e si dispone di un ampio set di documenti è necessario essere molto attenti circa la memorizzazione di oggetti nel db.Si consideri il seguente:

Nel caso caso di di imaging di documenti, di 200 milioni di file TIFF può essere considerato un relativamente grande, ma non enorme, di sistema.Su larga scala di sistemi può avere più di 1 miliardo di file oggetto.A, diciamo, a 20KB al TIFF in bianco e nero si potrebbe avere 4TB di oggetto di archiviazione di file.Per quanto tempo sono il tuo DB backup andando a prendere?Quanto tempo sono le vostre query di andare a prendere?Qual è la frequenza di accesso per questi oggetti?Se questi oggetti hanno un'alta frequenza di accesso, volete che il vostro high-end DB server di trascorrere tutto il suo tempo che serve il file?Se si dispone di milioni di oggetti, allora avete bisogno di essere maledettamente attenzione su come l'architetto di una soluzione in cui gli oggetti vengono memorizzati nel db.

Supponiamo che voi ora il compito di convertire tali 200M TIFF in file PDF.Essere preparati per portare la soluzione al ginocchio come database server sprechi il suo tempo a servire su ogni oggetto file per il processo di conversione, e poi ri-registrare i risultati.

Solo per fare un esempio, Sharepoint è famosa per la memorizzazione di oggetti in db.Sharepoint è famosa anche per i problemi di scalabilità.

La mia risposta:
Per impianti di piccola taglia (< 1M file) archiviazione di file nel DB può essere considerato.Per impianti di grandi dimensioni (> 1 milione di file) per memorizzare i file nel DB è un errore.

La mia più grande preoccupazione con la memorizzazione dei file del database stesso, è la gestione delle dimensioni e della complessità di backup e di altri db operazioni di manutenzione.

Una strategia per sopperire a questa difficoltà (almeno in MS SQL) è quello di creare le partizioni del database, potenzialmente memorizzati su dischi diversi.

Quindi di separare i dati dello schema in modo che i metadati circa i file si trovano su una partizione e l'effettivo BLOB file si trovano in una partizione separata.

Queste partizioni possono essere sottoposti a backup, ad orari diversi, o addirittura recuperati separatamente.

Io ho memorizzato le immagini come Blob nel database una volta e si è rammaricato per la prima volta ho dovuto eseguire un'operazione batch su quelle immagini.Sarebbe stato molto più facile farlo nel file system.Inoltre, come hai detto, è molto più veloce per recuperare i documenti, se vivono in un file system.

La mia semplice visione:il file system deve memorizzare i file, e un database relazionale, dovrebbe archiviare i dati relazionale.

Memorizzare i file binari nel file system.Creare un ASP.NET applicazione per l'archiviazione e il recupero di operazioni.Si può essere di fantasia, con la web app (doc versioning, multi-livello di sicurezza, ecc).Penso che questo sia il consenso nel doc di gestione del settore.

Dal momento che il "numero del documento che cresce drasticamente", ha questo aspetto sta diventando grande scala.Puoi iniziare a guardare di terze parti, out-of-the-box soluzioni (come http://kofax.com/capture/ - Ho una vasta esperienza con questo!) per fare il "lavoro sporco" per voi.O meglio ancora, prendere in considerazione guardando SaaS come questi ragazzi http://www.edocumentsolutionsllc.com/

:-)

Archiviare i vostri documenti come file, ad esempio .doc, se si vuole essere in grado di accedere ai file e modificare e salvare di nuovo loro.

Archiviare i vostri documenti come file, ad esempio .pdf o .tiff se vuoi storici reali di copie che può essere tirato indietro e riprodotto.

Memorizzare tutte le informazioni riguardanti i file (ad esempio date, autori, posizione) nel database.

Ho sempre negozio core info e percorso del file per i documenti nel database, ma non il documento stesso.Raramente l'intero documento bisogno di essere nel database.

Questo consente una maggiore flessibilità nell'utilizzo di tali documenti.Ad esempio, si desidera utilizzato tiered storage di backup e deduping meccanismi?Provare che in Oracle Blob.

L'unico vantaggio che posso vedere per la conservazione dei documenti nel database è la facilità di movimento di tali documenti in un altro ambiente.A parte questo, non vorrei farlo per tutti i motivi già citati.

Esperienza Personale:Sei un db admin o un programmatore?

Sicurezza:una impostazione per il database vs 2 per il database e i file di sistema.È una preoccupazione di qualcuno accidentalmente spostamento/eliminazione di file?Nel complesso l'impostazione di un admin può scegliere di spostare i file su un altro server e cambiare solo la Quota o la mappatura.So che questo non potrebbe mai accadere.

Le nuove basi di dati sono in miglioramento in questo settore.

Valutare la possibilità di archiviare i tuoi documenti in subversion, o altro sistema di controllo di versione.Avrai un buon backup, la capacità di guardare le vecchie versioni dei documenti e la splendida rete di accesso.Vedere "La mia vita su subversion".

Al contrario vorrei andare per l'archiviazione nel database per un paio di motivi:

  1. Semplice strategia di backup
  2. I documenti memorizzati nel database possono essere indicizzato e ricercato
  3. Non è necessario preoccuparsi di file trasferiti/sicurezza manomesso
  4. Facile la porta per un altro server in caso di crash
  5. Se i mandati di governo è necessario memorizzare i dati di tornare x anni, la gestione di questo utilizzo di un database è molto più facile

I database sono fatti per memorizzare i dati.I file sono solo dati.

Pur avendo detto che ci sono benefici per la memorizzazione dei file sul filesystem, il capo di uno dei database di prestazioni è migliore e la dimensione è mantenuto.SQL Server 2008 consente di avere il meglio di entrambi i mondi, utilizzando il FileStream. Leggere questo whitepaper per ulteriori informazioni

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top