[Mysql] Qual è il modo migliore per archiviare i file multimediali su un database?


Answers

Penso che archiviarli nel database sia ok, a patto che tu usi una buona implementazione. Puoi leggere questo articolo vecchio ma buono per idee su come mantenere le maggiori quantità di dati nel database da influire sulle prestazioni.

http://www.dreamwerx.net/phpforum/?id=1

Ho avuto letteralmente centinaia di concerti caricati nei database mysql senza problemi. La progettazione e l'implementazione sono fondamentali, sbagliate e soffrirete.

Ulteriori vantaggi DB (non ancora menzionati): - Funziona meglio in un ambiente con bilanciamento del carico - È possibile creare una maggiore scalabilità dello storage di back-end

Question

Voglio memorizzare un gran numero di file audio in un database, ma non so se sia una buona pratica. Mi piacerebbe sapere i pro e i contro di farlo in questo modo.

Ho anche pensato alla possibilità di avere "collegamenti" a questi file, ma forse questo porterà più problemi che soluzioni. Qualsiasi esperienza in questa direzione sarà il benvenuto :)

Nota: il database sarà MySQL.




Ho sperimentato diversi progetti con entrambi i metodi e alla fine abbiamo deciso che è più semplice usare il file system. Dopo tutto, il file system è già ottimizzato per l'archiviazione, il recupero e l'indicizzazione dei file.

L'unico consiglio che vorrei avere è quello di memorizzare solo un percorso "relativo alla radice" nel file nel database, quindi fare in modo che il programma o le query / stored procedure / middleware utilizzino un parametro root specifico dell'installazione per recuperare il file .

Ad esempio, se memorizzi XYZ.Wav in C: \ MyProgram \ Data \ Sounds \ X \ il percorso completo sarebbe

C:\MyProgram\Data\Sounds\X\XYZ.Wav

Ma dovresti memorizzare il percorso e il nome file nel database come:

X\XYZ.Wav

Altrove, nel database o nei file di configurazione del tuo programma, memorizza un percorso di root uguale a SoundFilePath

C: \ Programma \ Data \ Sounds \

Ovviamente, dove hai diviso la radice dal percorso del database dipende da te. In questo modo se si sposta l'installazione del programma, non è necessario aggiornare il database.

Inoltre, se ci sono molti file, trova un modo per eseguire l'hashing dei percorsi in modo da non finire con una directory contenente centinaia o migliaia di file (nel mio piccolo esempio, ci sono sottodirectory basate sul primo carattere di il nome del file, ma puoi approfondire o usare gli hash casuali). Ciò rende felici anche gli indicizzatori di ricerca.




Una soluzione semplice sarebbe quella di archiviare le posizioni relative dei file come stringhe e lasciare che sia il filesystem a gestirle. L'ho provato su un progetto (stavamo conservando allegati di file di Office a un sondaggio), e ha funzionato bene.




Alcuni vantaggi dell'utilizzo dei BLOB per archiviare i file

  • Minori costi di gestione: utilizzare un singolo strumento per il backup / ripristino ecc
  • Nessuna possibilità per database e filesystem di essere fuori sincrono
  • Capacità transazionale (se necessario)

Alcuni svantaggi

  • fa esplodere la RAM dei server di database con inutile spazzatura che potrebbe essere utilizzata per memorizzare righe, indici, ecc
  • Rende i backup del DB molto grandi, quindi meno gestibili
  • Non conveniente come un filesystem da servire ai client (ad es. Con un server web)

Che dire delle prestazioni? Il tuo chilometraggio può variare. I filesystem sono estremamente vari, così come i database nelle loro prestazioni. In alcuni casi vincerà un filesystem (probabilmente con meno file più grandi). In alcuni casi un DB potrebbe essere migliore (forse con un numero molto grande di file piccoli).

In ogni caso, non ti preoccupare, fai quello che sembra il migliore al momento.

Alcuni database offrono un server Web integrato per servire BLOB. Al momento della scrittura, MySQL no.