2009-07-31 10 views
7

Recentemente, io e i miei colleghi, stiamo discutendo su come costruire un enorme sistema di archiviazione in grado di memorizzare miliardi di immagini che potrebbero essere ricercate e scaricate rapidamente.Pensi che sia una buona idea salvare miliardi di immagini nel Database?

Qualcosa come un fickr, ma non per una galleria online. Il che significa che la maggior parte di queste immagini non sarà mai scaricata.

I miei colleghi suggeriscono che dovremmo salvare tutti questi file direttamente nel database. Ritengo davvero che non sia una buona idea e penso che il database non sia stato progettato per il ripristino di un numero enorme di file binari. Ma ho una ragione molto forte per cui non è una buona idea.

Cosa ne pensi.

+11

Questo è già stato discusso a morte: http://stackoverflow.com/questions/3748/storing-images-in-db-yea-or-nay http://stackoverflow.com/questions/815626/to- fare-o-non-fare-memorizzare-immagini-in-un-database http://stackoverflow.com/questions/805519/save-image-in-database –

risposta

17

Quando si ha a che fare con oggetti binari, seguire un approccio incentrato sui documenti per l'architettura e non archiviare documenti come PDF e immagini nel database, sarà necessario ridefinirlo quando si iniziano a vedere tutti i tipi di problemi di prestazioni con il database . Basta memorizzare il file sul file system e avere il percorso all'interno di una tabella del tuo database. Esiste anche una limitazione fisica sulla dimensione del tipo di dati che verrà utilizzato per serializzare e salvarlo nel database. Basta salvarlo sul file system e accedervi.

+8

È interessante notare che SQL Server 2008 fa questo per te con il FILESTREAM opzione di archiviazione- http://msdn.microsoft.com/en-us/library/cc949109.aspx – RichardOD

+0

Anche se sono d'accordo con questo, non archivia quasi tutto nel database? In tal caso, penserei che le persone di SharePoint potrebbero non pensare che sia una cattiva idea memorizzare i file nel database. Credo che sia utile in qualche modo (come l'interrogazione), ma probabilmente questi modi non neutralizzano completamente le cose che hai menzionato qui. – Dusty

+0

@RichardOD, ho letto il documento e parla principalmente delle stesse sfide di archiviazione di contenuti strutturati rispetto a contenuti non strutturati e raccomanda NTFS. "FILESTREAM è una nuova funzionalità nella versione di SQL Server 2008. Consente di archiviare i dati strutturati nel database e i dati non strutturati associati (ad esempio BLOB) da memorizzare direttamente nel file system NTFS. È quindi possibile accedere al BLOB dati attraverso le API di streaming Win32® ad alte prestazioni, piuttosto che dover pagare la penalità delle prestazioni di accesso ai dati BLOB attraverso SQL Server. " –

0

Non è una buona idea. Il punto di un database è che puoi risolvere rapidamente query complesse per recuperare i dati testuali. Mentre i dati binari possono essere archiviati in un database, possono rallentare le transazioni. Ciò è particolarmente vero quando il database si trova su un server separato dall'applicazione in esecuzione. Nel database, memorizzare i meta-dati e la posizione/nome file delle immagini. Le immagini stesse dovrebbero essere su server statici.

2

Se siete veramente parlando di miliardi di immagini, li avrei memorizzarli nel file system, perché il recupero sarà più veloce di serializzazione e de-seralizing le immagini

+1

Sì, sto davvero parlando di miliardi di immagini. I miracoli accadono ogni giorno. – ablmf

1

Le risposte di cui sopra sembrano assumere la banca dati è un RDBMS. Se il tuo database è un database orientato ai documenti con supporto per i documenti binari delle dimensioni che ti aspetti, allora potrebbe essere perfettamente saggio memorizzarli nel database.

+0

Potresti nominare un paio di tali database? – Moonwalker

+2

MarkLogic (http://developer.marklogic.com/) supporta la memorizzazione di documenti XML, JSON, di testo e binari. Esiste un'API REST per iniziare rapidamente a http://github.com/marklogic/Corona e un linguaggio di query nativo (XQuery). –

Problemi correlati