Memorizza e etichetta milioni di immagini

Naviga le tue risposte
2

Sto costruendo un'applicazione in cui ho bisogno di memorizzare milioni di immagini e successivamente etichettarle. I tag attribuiti alle immagini potrebbero cambiare nel tempo mentre il sistema di tagging si evolve. Le immagini verranno quindi cercate per tag.

In termini di archiviazione dei file, ho eliminato l'opzione di archiviarli in un RDBMS; L'ho provato in passato e ho riscontrato problemi di scalabilità e prestazioni e allo stesso modo ho eliminato l'opzione di archiviarli su un file system, poiché anche questo mi ha dato problemi di prestazioni, scalabilità e backup. Ora sto prendendo in considerazione l'utilizzo di un data store di valori chiave NOSQL o qualcosa come Amazon S3. Un archivio di valori-chiave è una scelta appropriata per questo tipo di dati?

In termini di memorizzazione dei dati dei tag per ciascuna immagine, poiché i tipi di tag sono sconosciuti in anticipo, sto cercando di sfruttare la natura schemaless di NOSQL e di utilizzare sia l'archivio dati dei documenti che un profilo colonna uno. Quali sarebbero i fattori chiave nel decidere quale tipo di negozio utilizzare? Ci sono altre opzioni che dovrei prendere in considerazione?

Infine, ha senso dividere i dati dell'immagine e i metadati in negozi separati oppure esiste una tecnologia che può fare entrambe le cose? Forse qualcosa come un archivio di valori chiave che consente anche l'aggiunta di metadati e l'esecuzione di query sui metadati?

Aggiornamento: ho visto le risposte precedenti ma hanno pochi anni e non sembrano sfruttare le tecnologie contemporanee. Qualcuno può commentare se RDBMS + Filesystem è ancora il modo migliore per farlo o sono le sue soluzioni più recenti e migliorate.

    
posta ssc327 31.10.2017 - 06:32
fonte

2 risposte

5

La domanda è di scala, dove sarà ospitata, costi e gestione. Se sai che stai per ospitare in AWS, puoi sfruttare la natura distribuita che rende il cloud più scalabile.

Prima decisione: Self-hosting vs Cloud

Le vecchie risposte (circa 2014) riflettono la mentalità in cui l'auto hosting era ancora predominante. Tuttavia, esistono motivi per guardare all'esterno di un RDBMS per le query correlate ai tag.

L'hosting del filesystem richiede che tu gestisca il tuo NAS o la tua SAN e assicuri di avere abbastanza provisioning e l'esperienza per migliorare le prestazioni e la capacità, se necessario. Può essere molto costoso se i costi non vengono ammortizzati su più applicazioni.

Il cloud ti consente di utilizzare AWS S3 o qualsiasi altra memoria di blob equivalente per il tuo provider cloud. Questa soluzione ti addebita solo per lo spazio di archiviazione che utilizzi e lo storage cloud blob fornisce sia la scala che le prestazioni necessarie per ridimensionare la crescita della tua applicazione.

Seconda decisione: RDBMS o Ricerca

Il modo in cui è necessario memorizzare i tag in un database relazionale rispetto a un archivio documenti rende le query più difficili per ottenere record correlati a tali tag. Lo è ancora di più quando cerchi intersezioni tra tag (cioè documenti che hanno 2 o più tag identici). Le query rallenteranno più diventa complicato.

ElasticSearch, SOLR e server di ricerca simili che possono raddoppiare come archivio di documenti forniscono una via di mezzo ideale. Molti fornitori di servizi cloud hanno soluzioni di hosting per questi tipi di problemi. Sono progettati per adattarsi a dimensioni molto grandi ed eseguire ricerche molto rapidamente. In realtà questo sito (softwareengineering.stackexchange.com) usa ElasticSearch per fare query come questa. NOTA: ElasticSearch è anche un DB NoSQL oltre ad essere un server di ricerca.

Dirò che non puoi pensare in termini relazionali quando stai facendo ricerche di documenti, quindi c'è una curva di apprendimento.

Il bonus aggiuntivo è che almeno con AWS, ElasticSearch costa meno di un RDBMS per lo stesso livello di dimensioni.

Bottom Line

Milioni di record non sono astronomici per gli RDBMS di oggi. Tuttavia, raggiungerai un punto di saturazione. Molti siti Web utilizzano ancora un RDBMS per l'archiviazione dei dati del record e quindi lo sincronizzano con un server di ricerca per il sollevamento pesante. Quella decisione dipende davvero da cose al di fuori dello scopo di questa domanda.

La rotta ElasticSearch / S3 si ridurrà ben oltre. Tuttavia, fai la tua ricerca. Ci sono dei compromessi che devi pesare. Nel mio caso questa scelta era quella giusta.

    
risposta data 31.10.2017 - 14:55
fonte
2

L'archiviazione dei file dovrebbe essere l'opzione meno dolorosa. Tuttavia, se hai bisogno della scalabilità devi metterlo su un file system distribuito come GFS o HDFS. Quando li stai salvando, puoi eseguirli di nuovo a scansione in modo che siano

  1. file immagine validi
  2. ottenere lo sha256sum o il 512 potrebbe essere eccessivo per ciascuno e usarlo come nome del file.
  3. (facoltativamente) rimuove i dati non immagine che possono essere aggiunti dopo il file immagine.
  4. (facoltativamente) reencode le immagini senza perdita in un nuovo formato.

Quando si archiviano i file non li si memorizzano tutti in una directory, ma si raggruppano per percorsi esadecimali a 2 caratteri che migliorerebbero la velocità di scansione della directory.

Facendo lo sha256sum del file è possibile eliminare rapidamente duplicati di file esatti. Facendo # 3, # 4 puoi eliminare ulteriormente i duplicati.

    
risposta data 15.11.2017 - 04:17
fonte

Leggi altre domande sui tag

Qual è la differenza tra una pagina man e --help per uno script Python? Evita la ripetizione del codice nelle operazioni CRUD