Posso solo rispondere per MongoDB qui, non pretendo di sapere molto su HDFS e altre tecnologie simili.
L'implementazione di GridFs è totalmente lato client all'interno del driver stesso. Ciò significa che non esiste un caricamento o una comprensione speciali del contesto del servizio di file all'interno di MongoDB stesso, in effetti MongoDB stesso non comprende nemmeno che sono file ( http://docs.mongodb.org/manual/applications/gridfs/).
Ciò significa che eseguire query per qualsiasi parte dei files o chunks la raccolta risulterà nello stesso processo di qualsiasi altra query, per cui carica i dati di cui ha bisogno nel tuo set di lavoro ( http://en.wikipedia.org/wiki/Working_set ) che rappresenta un insieme di dati (o tutti dati caricati in quel momento) richiesti da MongoDB entro un determinato intervallo di tempo per mantenere prestazioni ottimali. Lo fa impaginandolo nella RAM (ben tecnicamente lo fa il sistema operativo).
Un altro punto da tenere in considerazione è che questo driver è implementato. Ciò significa che le specifiche possono variare, tuttavia, non credo che lo faccia. Tutti i driver ti permetteranno di interrogare una serie di documenti dai files raccolta che ospita solo i metadati dei file consentendoti in seguito di servire il file stesso dai chunks raccolta con un'unica query.
Tuttavia non è questa la cosa importante, vuoi servire il file stesso, inclusi i suoi dati; questo significa che caricherai i files raccolta e i suoi successivi chunks raccolta nel tuo set di lavoro.
Con questo in mente abbiamo già colpito il primo intoppo:
I file di gridfs verranno memorizzati nella cache nella ram e in che modo influiranno sulle prestazioni di lettura-scrittura?
Le prestazioni di lettura di piccoli file potrebbero essere fantastiche, direttamente dalla RAM; le scritture sarebbero altrettanto buone.
Per file più grandi, non è così. La maggior parte dei computer non avrà 600 GB di RAM ed è probabile, in effetti, abbastanza normale, ospitare una partizione da 600 GB di un singolo file su un singolo mongod esempio. Questo crea un problema poiché quel file, per essere servito, deve adattarsi al tuo set di lavoro, tuttavia è incredibilmente più grande della tua RAM; a questo punto potresti avere il page thrashing ( http://en.wikipedia.org/wiki/Thrashing_%28computer_science%29 ) per cui il server è solo page faulting 24 ore su 24, 7 giorni su 7, cercando di caricare il file. Anche le scritte qui non sono migliori.
L'unico modo per aggirare questo problema è iniziare a inserire un singolo file su molti shard :\ .
Nota:un'altra cosa da considerare è che la dimensione media predefinita di un chunks "chunk" è 256 KB, quindi sono molti documenti per un file da 600 GB. Questa impostazione è modificabile nella maggior parte dei driver.
Cosa accadrà con gridfs quando provo a scrivere pochi file contemporaneamente. Ci sarà un blocco per le operazioni di lettura/scrittura? (Lo userò solo come archivio di file)
GridFS, essendo solo una specifica, utilizza gli stessi blocchi di qualsiasi altra raccolta, sia in lettura che in scrittura a livello di database (2.2+) oa livello globale (pre-2.2). I due interferiscono anche l'uno con l'altro, ad es. come puoi garantire una lettura coerente di un documento su cui viene scritto?
Detto questo, la possibilità di contesa esiste in base alle specifiche dello scenario, al traffico, al numero di scritture/letture simultanee e molte altre cose di cui non abbiamo idea.
Forse ci sono altre soluzioni che possono risolvere il mio problema in modo più efficiente?
Personalmente ho scoperto che S3 (come ha detto @mluggy) in formato a ridondanza ridotta funziona al meglio archiviando una semplice porzione di metadati sul file all'interno di MongoDB, proprio come usare GridFS ma senza la raccolta di blocchi, lascia che S3 gestisca tutta quella distribuzione, backup e altre cose per te.
Spero di essere stato chiaro, spero di esserti stato d'aiuto.
Modifica:a differenza di quanto ho detto per sbaglio, MongoDB non ha un blocco a livello di raccolta, è un blocco a livello di database.
