Archiviazione di documenti come BLOB in un database - Qualche svantaggio?

Question

I requisiti per il mio sistema di gestione dei documenti erano:

1. Deve essere protetto dal furto mediante una semplice copia di directory, file ecc.
2. Deve essere sicuro contro l'infezione da virus tradizionale (infezione del file fisico)
3. Deve essere veloce da recuperare
4. Il repository non deve essere visibile agli utenti casuali (di directory), ecc.

Ho deciso di archiviare tutti i documenti (e le immagini scansionate) come BLOB nel database e finora la mia esperienza è meravigliosa e anche il recupero dei documenti è incredibilmente veloce - soddisfa tutti i criteri dall'alto e ci sono anche un paio di ulteriori vantaggi, come il salvataggio automatico dei documenti insieme all'entità a cui si riferisce, la ricerca facile e rapida dei contenuti, la rimozione di ogni tipo di attività dell'utente relativa all'apertura e alla denominazione dei documenti, ecc. ecc.

La mia domanda è: ci sono rischi o cose gravi che ho trascurato in questo progetto e implementazione?

EDIT Nota: DB è PostgreSQL, gestisce BLOBS molto bene e si adatta in modo eccezionale. L'ambiente è multiutente.

Answer 1

Quando il tuo DB diventa sempre più grande, sarà più difficile eseguire il backup. Il ripristino di un backup di una tabella con oltre 100 GB di dati non è qualcosa che ti rende felice.

Un'altra cosa che si ottiene è che tutte le funzioni di gestione della tabella diventano sempre più lente man mano che il set di dati cresce.
Ma questo può essere superato facendo in modo che la tabella dei dati contenga solo 2 campi:  ID e BLOB.

Il recupero dei dati (tramite chiave primaria) probabilmente diventerà un problema solo dopo che si è colpito un muro con il backup del set di dati.

Answer 2

Lo svantaggio principale di cui sento spesso parlare dell'utilizzo di BLOB è che, al di sopra di una certa dimensione, il file system è molto più efficiente nell'archiviazione e nel recupero di file di grandi dimensioni. Sembra che tu l'abbia già preso in considerazione dal tuo elenco di requisiti.

C'è un un buon riferimento (PDF) qui che copre i professionisti e contro di BLOB.

Answer 3

Dalla mia esperienza, alcuni problemi sono stati:

1. velocità rispetto alla presenza di file nel file system.

2. caching. IMO il web server farà un lavoro migliore nella memorizzazione nella cache contenuto statico. Il DB farà un buon lavoro anche, ma se lo è anche il DB consegnando ogni sorta di altre domande, non aspettarti quei documenti di grandi dimensioni rimanere nella cache a lungo. tu essenzialmente devono trasferire il file file due volte. Una volta dal DB al Server Web, quindi Server Web su cliente.

3. Vincoli di memoria. Nel mio ultimo lavoro avevamo un PDF da 40 MB nel database e continuavamo a ottenere Java OutOfMemoryErrors nel file di registro. Alla fine ci siamo resi conto che l'intero PDF da 80 MB è stato letto nell'heap non solo una volta, ma DUE VOLTE grazie a un'impostazione in Hibernate ORM (se un oggetto è mutabile, ne fa una copia per la modifica in memoria). Una volta che il PDF è stato inviato nuovamente in streaming all'utente, l'heap è stato ripulito, ma è stato un grande successo risucchiare subito 80 MB dallo heap solo per lo streaming di un documento. Conosci il tuo codice e come viene utilizzata la memoria!

Il tuo server web dovrebbe essere in grado di gestire la maggior parte dei tuoi problemi di sicurezza, ma se i documenti sono piccoli e il DB non è già sotto un grosso carico, allora non vedo davvero un grosso problema con averli nel DB .

Answer 4

Ho appena iniziato a ricercare FILESTREAMing di SQL Server 2008 per BLOB e ho riscontrato un limite enorme (IMO): funziona solo con la sicurezza integrata. Se non si utilizza l'autenticazione di Windows per connettersi al server DB, non è possibile leggere / scrivere i BLOB. Molti ambienti applicativi non possono utilizzare l'autenticazione di Windows. Certamente non in ambienti eterogenei.

Deve esistere una soluzione migliore per l'archiviazione dei BLOB. Quali sono le migliori pratiche?

Answer 5

Questo articolo copre la maggior parte dei problemi. Se stai usando SQL Server 2008, controlla l'uso del nuovo tipo FILESTREAM come discusso da Paul Randal qui .

Answer 6

Dipende dal tipo di database. Oracle o SQLServer? Essere consapevoli di uno svantaggio: il ripristino di un singolo documento.

Answer 7

Siamo spiacenti: la risposta che ho offerto era basata su SQL Server, quindi la parte di manutenzione non è appropriata. Ma l'I / O dei file viene eseguito a livello hardware e qualsiasi database aggiunge ulteriori fasi di elaborazione.

Il database imporrà un sovraccarico aggiuntivo durante il recupero del documento. Quando il file è su disco, sei lento o veloce quanto l'I / O sul server. Dovresti certamente gestire il tuo meta in un database, ma alla fine vuoi l'UNC del file e puntare l'utente la fonte e levati di mezzo.

Dal punto di vista della manutenzione e dell'amministrazione ti limiterai a una SAN quando gestisci MS SQL Server. Soluzioni come Documentum adottano un approccio diverso con una semplice memorizzazione sul disco e ti consentono di implementare una soluzione di archiviazione come ritieni opportuno.

Modifica

Vorrei chiarire la mia affermazione: con SQL Server hai opzioni limitate quando superi la capacità di archiviazione fisica della scatola. Questo è in effetti uno dei maggiori punti deboli di Sharepoint che non si è in grado di collegare semplicemente alcun tipo di memoria di rete.

Answer 8

Da quello che ho sperimentato archiviare i file di contenuto come BLOB, sia in SQL Server che in Oracle, funziona bene con un piccolo database e con un basso numero di utenti che hanno effettuato l'accesso. Il sistema ECM li separa e usa servizi separati per lo streaming di contenuti. A seconda della dimensione dei file, le risorse del server possono essere influenzate dal recupero simultaneo di file di grandi dimensioni. L'archivio di database con grandi set di file diventa problematico a causa del tempo di ripristino e dell'impossibilità di recuperare i documenti dall'archivio.

Se questi file sono record aziendali e questa è la copia autorevole dei record, è possibile che si verifichino problemi di conformità e gestione della conservazione, soprattutto se si archiviano i file. Anche il controllo di ricerca e versione può diventare un grosso problema in futuro.

Potresti voler esaminare un sistema ECM con un'API di qualche tipo, piuttosto che reinventare la ruota.