Dove memorizzare molti file?

3

Ho 500.000 file con le dimensioni combinate di 350 GB. Quindi un file medio ha una dimensione di 0,7 MB. Ogni file ha metadati: da 1 a 100 parole chiave e opzionalmente una breve descrizione. Devo filtrare i file e trovare le parole chiave dell'espressione di ricerca nelle parole chiave dei file e nelle descrizioni. Si noti che alcuni file sono file di testo, quindi per quelli, ho bisogno di trovare anche le parole chiave nel file, che significa ricerca full-text.

  1. Devo memorizzare i metadati e i file nello stesso database, o dovrei memorizzare i metadati e i file di testo nello stesso database e i file binari da qualche altra parte?
  2. Quale tipo di database può memorizzare tanti file?

Si noti che i database sono protetti da RAID, ma posso avere una cache del filesystem non protetta da RAID, nel caso in cui renderebbero lo streaming lento.

Sono preoccupato solo delle prestazioni di ricerca e accesso ai file, non di coerenza, convenienza, sicurezza o utilizzo delle risorse. Posso usare anche il file system se questo rende le cose più veloci.

    
posta inf3rno 24.09.2016 - 22:07
fonte

2 risposte

5

Dove conservare i file?

La questione se archiviare o meno i file nel database deve essere considerata sotto diversi angoli:

  • Consistenza : l'archiviazione dei metadati e dei file (come BLOB) nel database assicura che ciò che appartiene insieme rimanga insieme. Nessuna paura di incoerenza se l'inserimento è interrotto, nessuna posizione di archiviazione separata da gestire con l'url assoluto o relativo nel database.

  • Praticità : puoi spostare / eseguire il backup / replicare / monitorare il tuo database se hai solo bisogno di utilizzare gli strumenti del database. Con file separati, devi organizzare tutte le operazioni. Non è necessariamente difficile, ma devi prenderti cura di esso.

  • Sicurezza : la maggior parte dei DBMS offre alcuni meccanismi di autorizzazione per l'accesso degli utenti e persino la crittografia, se necessario. Quindi avere il file nel DMBMS assicura che nessuno manometta i file e solo quelli che hanno i necessari privilegi di DB possono accedervi. Con file separati all'esterno del database, è molto più difficile organizzarlo (a meno che tu non sia su un server e i client non possano accedere direttamente alle cartelle).

  • Rendimento: questo è qualcosa che devi controllare attentamente con il DBMS che sceglierai: l'API per accedere ai BLOB potrebbe richiedere un sovraccarico per il trasferimento da / verso il database in pezzi più piccoli. Quindi è necessario fare attenzione a richiedere questo oggetto solo se necessario. Qui con i file nel file system, è più veloce accedere ai dati grezzi quando è necessario. Tuttavia con così tanti file, potrebbe essere necessario distribuirli su più cartelle, per non risentire delle prestazioni di ricerca di ogni nome di file in una directory enorme.

  • Risorse: se dovessi prendere in considerazione l'utilizzo di un database in memoria per accelerare il tuo lavoro "semantico" sui metadati, sarebbe molto costoso archiviare anche tutti i dati chiari in memoria. Lì, file separati potrebbero davvero essere di vantaggio.

Non sapendo cosa sta facendo esattamente la tua applicazione, non sarebbe saggio consigliarti fermamente in un modo o nell'altro.

Esempi di vita reale

  • Nella mia azienda utilizziamo un enorme ERP. I record delle transazioni finanziarie nel database si riferiscono a documenti finanziari scansionati che sono memorizzati al di fuori del DB su un server di contenuti distinto. Il content server è una specie di server web, che memorizza localmente i file immagine (JPG, PDF, ...) nel suo file system locale. La sicurezza dell'accesso è organizzata tramite un complesso schema di convalida dell'URL.
  • Un altro sistema memorizza i documenti scansionati per un'attività non coperta dall'ERP. Le immagini vengono memorizzate direttamente nel database.

Quindi, in pratica, entrambi gli approcci funzioneranno. Il primo è basato su prodotti software standard. Il secondo è stato sviluppato internamente. Dal punto di vista delle prestazioni, entrambi sono molto simili perché le immagini sono accessibili dal client (cioè il sovraccarico potenziale nella gestione BLOB sul lato DB, sono compensate dal sovraccarico di un ulteriore trasferimento con il server web aggiuntivo).

Relazionale o no?

Se diventi relazionale, potresti voler gestire:

  • i record di file (ad esempio identificazione, alcuni metadati univoci e BLOB).
  • le parole chiave (metadati + elenco filtrato di parole in testo semplice)
  • l'associazione di parole chiave a record di file (molti a molti).

Non c'è dubbio che le prestazioni e la flessibilità saranno lì, perché la ricerca di chiavi, l'unione di più ricerche, ecc. è il core business di un RDBMS. Ma dovrai capire come strutturare al meglio i metadati.

Potresti anche optare per un NoSQL database. Sono più flessibili sulla struttura dei dati. Intuitivamente suggerirei di iniziare a dare un'occhiata ai database dei documenti. Se invece preferisci mantenere i file fuori dal database, potresti essere più interessato a un archivio di valori-chiave, o anche a un grande archivio di colonne se gestirai diversi tipi di parole chiave per diversi tipi di metadati.

    
risposta data 25.09.2016 - 00:41
fonte
1

I am concerned only about the performance of search and file access, not consistency, convenience, security or resource utilization.

Le prestazioni di lettura e scrittura di file di quelle dimensioni (media 0,7 Mb), un file system è probabilmente più veloce. (Per i file più piccoli, ad esempio 0,7 Kb, un database potrebbe essere più veloce, mentre i file system tipici non sono adatti a gestire molti piccoli file.)

La ricerca è un problema diverso. Il modo per ottenere una ricerca veloce su una grande quantità di dati è costruire indici.

  • Per i dati strutturati (ad esempio i metadati del file) in genere si creano tabelle di database per contenere i dati ricercabili e quindi si aggiungono indici di database per rendere più veloci le ricerche comuni (semplici). Evita le ricerche che richiedono l'uso di LIKE , espressioni regolari e così via perché richiede scansioni lineari.

  • Per i dati non strutturati (in particolare il testo), la soluzione standard consiste nell'utilizzare un motore di ricerca a testo libero. Questo funziona costruendo un indice inverso per l'intero corpus. Questo ti dà ordini di grandezza di prestazioni migliori rispetto a fare una scansione lineare dei file su ogni ricerca. Può eseguire ricerche in modo efficiente con più termini o ricerca di frasi.

Mi sembra che l'approccio del motore di ricerca a testo libero sia ciò di cui hai bisogno. Un buon motore di ricerca a testo libero fornirà anche un modo per conservare e cercare i metadati del file.

    
risposta data 25.09.2016 - 02:09
fonte

Leggi altre domande sui tag