Domanda

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

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

Nota: il database sarà MySQL.

È stato utile?

Soluzione

Ogni sistema che conosco che memorizza un gran numero di file di grandi dimensioni li archivia esternamente al database. Archiviate tutti i dati interrogabili per il file (titolo, artista, lunghezza, ecc.) Nel database, insieme a un percorso parziale del file. Quando è il momento di recuperare il file, si estrae il percorso del file, si antepone un file radice (o URL) e lo si restituisce.

Quindi, avresti una " posizione " colonna, con un percorso parziale al suo interno, come " a / b / c / 1000 " ;, che quindi mappi a: " http: //myserver/files/a/b/c/1000.mp3 "

Assicurati di avere un modo semplice per indirizzare il database multimediale su un server / directory diverso, nel caso in cui sia necessario per il recupero dei dati. Inoltre, potresti aver bisogno di una routine che risincronizzi il database con il contenuto dell'archivio file.

Inoltre, se hai migliaia di file multimediali, non archiviarli tutti in un'unica directory gigante: si tratta di un collo di bottiglia delle prestazioni su alcuni file system. Invece, suddividili in più sotto-alberi bilanciati.

Altri suggerimenti

Penso che archiviarli nel database sia ok, purché si utilizzi una buona implementazione. Puoi leggere questo vecchio ma valido articolo per avere idee su come evitare che le maggiori quantità di dati nel database influiscano sulle prestazioni.

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

Ho avuto letteralmente centinaia di concerti caricati nei database mysql senza problemi. Il design e l'implementazione sono fondamentali, fai qualcosa di sbagliato e ne soffrirai.

Altri vantaggi DB (non già menzionati): - Funziona meglio in un ambiente con carico bilanciato - Puoi aumentare la scalabilità dello storage back-end

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

L'unico suggerimento che avrei a riguardo è quello di memorizzare solo un "relativo parente" " percorso del file nel database, quindi fai in modo che il tuo programma o le tue query / stored procedure / middleware utilizzino un parametro root specifico dell'installazione per recuperare il file.

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

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

Ma dovresti archiviare il percorso o il nome del file nel database come:

X\XYZ.Wav

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

C: \ Programma \ Data \ Sounds \

Ovviamente, dove dividere 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 saranno lotti di 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 del nome file, ma puoi approfondire o usare hash casuali). Questo rende felici anche gli indicizzatori di ricerca.

Vantaggi dell'utilizzo di un database:

  • Facile unire file audio con altri bit di dati.
  • Evitare le operazioni di I / O dei file ignora la sicurezza del database.
  • Non sono necessarie operazioni di separazione per elimina i file audio quando il database i record vengono eliminati.

Svantaggi dell'utilizzo di un database:

  • Database boat
  • I database possono essere più costosi dei file system

È possibile memorizzarli come BLOB (o LONGBLOB) e quindi recuperare i dati quando si desidera effettivamente accedere ai file multimediali.

o

È possibile semplicemente archiviare i file multimediali su un'unità e archiviare i metadati nel DB.

Mi sposto verso quest'ultimo metodo. Non so come sia fatto nel mondo, ma sospetto che molti altri farebbero lo stesso.

È possibile memorizzare collegamenti (percorsi parziali ai dati) e quindi recuperare queste informazioni. Semplifica lo spostamento delle cose su unità e ancora l'accesso.

Memorizzo il percorso relativo di ciascun file nel DB insieme ad altri metadati sui file. Il percorso di base può quindi essere modificato al volo se devo spostare i dati effettivi su un'altra unità (locale o tramite percorso UNC).

Ecco come lo faccio. Sono sicuro che anche altri avranno idee.

Alcuni vantaggi dell'utilizzo dei BLOB per l'archiviazione dei file

  • Riduzione dei costi di gestione: utilizzare un singolo strumento per eseguire 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 tuoi server di database con immondizia inutile che potrebbe essere utilizzata per archiviare righe, indici ecc.
  • Rende molto grandi i backup del tuo DB, quindi meno gestibili
  • Non è conveniente come un filesystem da servire ai client (ad es. con un web server)

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 un numero minore di file più grandi). In alcuni casi un DB potrebbe essere migliore (forse con un numero molto elevato di file di dimensioni ridotte).

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

Alcuni database offrono un web server integrato per servire i BLOB. Al momento in cui scrivo, MySQL no.

Archiviali come file esterni. Quindi salvare il percorso in un campo varchar. Inserimento di grandi BLOB binari in un database relazionale è generalmente molto inefficiente: usano solo spazio e rallentano le cose quando le cache vengono riempite sono inutilizzabili. E non c'è nulla da guadagnare: le stesse macchie non possono essere cercate. Tuttavia, potresti voler salvare i metadati multimediali nel database.

Una soluzione semplice sarebbe quella di archiviare le posizioni relative dei file come stringhe e lasciare che il filesystem lo gestisca. L'ho provato su un progetto (stavamo archiviando gli allegati dei file di Office in un sondaggio) e ha funzionato bene.

Il modo migliore per archiviare file audio / video, è possibile utilizzare qualsiasi archivio distribuito che può essere locale o su cloud.

https://min.io/

per cloud: AWS S3

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