Conservereste i dati binari nel database o nel file system? [chiuso]

Question

Questa è una domanda che è stata posta prima ( large-text-and-images -in-sql ) ma principalmente per i dati che verranno modificati. Nel mio caso i dati verranno archiviati e mai modificati. Sembra solo ragionevole tenere tutto insieme.

Ci sono dei motivi per cui non dovrei archiviare dati binari statici in un database?

Supponendo che sia una cosa sensata da fare, ci sono dei vantaggi nel conservare tali dati in tabelle separate? (Potresti iniziare a capire ora che non sono un esperto di DB ...)

chiarire: Probabilmente non ci saranno più di 10-20 utenti, ma questi saranno negli Stati Uniti e nel Regno Unito. I dati binari dovranno essere trasferiti in ogni caso.

Answer 1

Il vantaggio di archiviare i dati nel DB sta sfruttando i meccanismi di sicurezza del DB e riducendo i costi di manutenzione (backup, ...). Lo svantaggio è l'aumento del carico del DB e il consumo di connessioni (che potrebbe essere costoso per i server di database con licenza per connessione). Se si utilizza SQL Server 2008, FILESTREAM potrebbe essere utile alternativa.

A proposito, per le app Web (o qualsiasi altra app che potrebbe richiedere lo streaming dei dati), di solito è più sensato archiviare i dati al di fuori del DB.

Answer 2

Tutto questo parla di fare un " selezionare * dalla tabella " causando enormi problemi di memoria e / o larghezza di banda quando la tabella ha un LOB in esso non è un problema. Tutto ciò che viene restituito è un puntatore al LOB in questione. Non abbastanza reputazione per mettere il commento nel contesto, ma le persone che lo guardano dovrebbero sapere che NON è un problema.

Answer 3

Il più grande svantaggio se si memorizzano BLOBS è il consumo di memoria. Riesci a immaginare cosa farebbe select * from x per migliaia di record con un'immagine 45k in ciascuno?

Come diceva Mehrdad, ci sono anche dei vantaggi. Quindi, se decidi di seguire questo approccio, dovresti provare a progettare il tuo database in modo che la maggior parte delle query restituisca meno risultati con i dati BLOB al loro interno. Forse per esempio stabilire relazioni uno a uno per questo scopo.

Answer 4

Affrontando il problema dal punto di vista dei principi, un database relazionale è (principalmente) lì per l'archiviazione di dati strutturati. Se non è possibile creare una condizione di query o unirsi su un elemento dati, probabilmente non appartiene al database. Non vedo un'immagine BLOB utilizzata in una clausola WHERE, quindi direi di tenerla fuori dal database. D'altra parte, un CLOB può essere utilizzato nelle query.

Answer 5

Ho familiarità con un progetto OSS di dimensioni abbastanza buone che ha preso la decisione di archiviare immagini nel database MySQL e si è dimostrato tra le 3 cattive idee che hanno affrontato da allora. (Esacerbato dal fatto che & Quot; refactor senza pietà & Quot; è un anatema, ma questa è un'altra storia.)

Tra i gravi problemi che ciò ha causato:

1. Superamento della dimensione massima efficiente del database (mysql). (Lo spazio totale richiesto per le immagini supera tutti gli altri di almeno 2 ordini di grandezza).

2. I file di immagine perdono la loro " fileness " ;. Nessuna dimensione data ecc. A meno che non sia memorizzata (in modo ridondante) come data (che richiede codice per la gestione).

3. Le sequenze di byte arbitrarie non vengono elaborate correttamente in qualsiasi momento, per la memorizzazione o la manipolazione.

4. " Non avremo mai bisogno di accedere alle immagini esternamente " è un presupposto pericoloso.

5. fragilità. Perché l'intero accordo è innaturale e permaloso, e non sai dove morderà in seguito (contribuendo alla mentalità antirifattore).

I vantaggi? Nessuno a cui riesco a pensare, tranne che al momento potrebbe essere stato il percorso di minor resistenza.

Answer 6

Penso che questo dipenda dall'applicazione che costruisci. Se stai costruendo un sistema CMS e l'utilizzo dei dati sarà quello di visualizzare le immagini all'interno di un browser Web, potrebbe avere senso salvare le immagini su disco anziché essere inserite nel database. Anche se onestamente farei entrambe le cose, il che potrebbe consentire di aggiungere un server a una farm senza dover copiare i file ovunque.

Un altro caso d'uso potrebbe essere un oggetto complesso, come un flusso di lavoro o persino un oggetto business con molte interdipendenze. È possibile serializzare entrambi questi in un formato binario o basato su testo e salvarli nel DB. Quindi ottieni il vantaggio del DB: ATOMIC, backup, ecc ...

Non credo che le persone dovrebbero usare select * query in primo luogo. Quello che fai è fornire due modi per ottenere i dati, un metodo restituisce le informazioni di riepilogo, il secondo restituisce il BLOB. Non riesco a immaginare perché dovresti restituire migliaia di immagini contemporaneamente.

Answer 7

Chiunque abbia avuto l'idea di archiviare un'immagine (o altro documento binario) in un database non è qualcuno di cui sono molto contento. I database sono pensati per la memorizzazione di [principalmente?] INDEXABLE, DISCRETE data. Non BLOB di dati binari senza significato. Se hai lavorato di prima mano con BLOB per i dati binari, lo sai già.

Dovresti archiviare un riferimento al file nel filesystem. La migliore pratica è un nome file, non un percorso assoluto (o relativo).

Answer 8

Archiviamo gli allegati nel nostro sistema e non è possibile modificare un allegato, quindi penso che siamo sulla stessa pagina con i dati che " verranno memorizzati e mai modificati. " Abbiamo specificamente deciso non di memorizzarlo nel database. Lo abbiamo fatto per due motivi, semplicità e tempo di backup / recupero.

Semplicità innanzitutto: nel nostro caso questi allegati vengono caricati dal browser dell'utente finale ed è più semplice scriverli in una directory (sul server DB) piuttosto che scaricarli in streaming nel tubo SQL. Ne esiste una registrazione nel DB, ma il DB contiene solo meta-informazioni sull'allegato e il nome del file su disco (una guida nel nostro caso)

Dal lato backup / ripristino: questi BLOB diventeranno probabilmente uno dei pezzi più grandi del database. Ogni volta che esegui un backup completo, copi questi bit più e più volte, anche se sai che non potranno mai cambiare. A noi è sembrato molto più semplice avere backup (molto) più piccoli e fare una copia della directory degli allegati su un server secondario come backup.

Answer 9

Non è esattamente quello che LOB o CLOB o ... sono stati progettati?

Abbiamo utilizzato i CLOB per archiviare crittografie di grandi dimensioni delle transazioni con carta di credito per un importante sistema aereo.

Il consumo di memoria è il tuo più grande colpevole però.

HTH

applausi,

Answer 10

Alcuni database (ad esempio Postgresql) comprimono automaticamente i campi, forse è più veloce quando li legge direttamente da db. Inoltre, il programma può leggere tutti i campi e l'immagine in un colpo solo.

Answer 11

Il problema di prestazioni qui è stato l'indirizzo sopra, quindi non lo ripeterò. Ma penso che un buon consiglio se stai memorizzando cose che verranno trasmesse in streaming molto (come immagini / documenti su un sito web) è quello di creare un sistema di cache.

Con questo intendo archiviare tutti i dati nel tuo database, ma quando qualcuno richiede quel file, controlla se esiste sul disco (basato su un nome file noto, in una cartella temporanea), in caso contrario, prendilo dal DB e scriverlo nella cartella e quindi trasmetterlo in streaming all'utente. Per la successiva richiesta allo stesso file, poiché esiste sul disco, può essere servito da lì senza colpire il DB. Ma se hai bisogno di eliminare questi file (o il tuo web server diventa kapput!), Non importa in quanto verranno ricostruiti nuovamente dal DB man mano che le persone li richiedono. Questo dovrebbe essere molto più veloce rispetto a soddisfare ogni richiesta per lo stesso file dal DB.