Memoria su larga scala per i documenti aggiunti in modo incrementale?

Question

Ho bisogno di memorizzare centinaia di migliaia (in questo momento, potenzialmente molti milioni) di documenti che partono vuoti e vengono aggiunti frequentemente, ma non vengono mai aggiornati in altro modo o cancellati. Questi documenti non sono correlati in alcun modo e devono essere accessibili solo tramite un ID univoco.

Gli accessi in lettura sono alcuni sottoinsiemi del documento, che inizia quasi sempre a metà percorso in qualche posizione indicizzata (ad esempio "documento 4324319, salva # 53 alla fine").

Questi documenti iniziano molto piccoli, a diversi KB. Generalmente raggiungono una dimensione finale di circa 500 KB, ma molti raggiungono 10 MB o più.

Attualmente sto utilizzando MySQL (InnoDB) per archiviare questi documenti. Ciascuno dei salvataggi incrementali viene semplicemente scaricato in una grande tabella con l'ID del documento a cui appartiene, quindi leggere parte di un documento è simile a "seleziona * da salva dove document_id = 14 e save_id> 53 ordina da save_id", quindi manualmente concatenandolo tutti insieme nel codice.

Idealmente, mi piacerebbe che la soluzione di archiviazione fosse facilmente scalabile orizzontalmente, con ridondanza tra i server (ad esempio, ogni documento memorizzato su almeno 3 nodi) con un facile recupero dei server bloccati.

Ho visto CouchDB e MongoDB come possibili sostituzioni per MySQL, ma non sono sicuro che entrambi abbiano un senso per questa particolare applicazione, anche se sono aperto alla convinzione.

Qualsiasi input su una buona soluzione di archiviazione?

Answer 1

Suona come un problema ideale da risolvere HBase (su HDFS).

Il lato negativo è la curva di apprendimento un po 'ripida, tra gli altri.

Answer 2

C'è qualche ragione per cui hai bisogno di un database?

Si descrive "un sistema per archiviare documenti con nomi univoci", quindi ho iniziato a pensare a "file system". Forse qualcosa come file server di classe enterprise (ho stimato un massimo di circa 200 TiB di dati), dove l'ID univoco è una directory e un nome di file sulla rete.

Answer 3

Il mio pensiero immediato è perché memorizzarli in un database? La memorizzazione di questi in un database comporta migliori prestazioni di ricerca rispetto a un filesystem quando si hanno a che fare con così tanti file?

Penso che la memorizzazione di questi in un filesystem in una struttura di directory con hash sarebbe meglio. È possibile utilizzare il database per memorizzare solo metadati (directory root, id documento, ID salvataggio, posizione relativa a root).

Le directory radice (nodi) sarebbero una tabella separata e potrebbero essere utilizzate durante la scrittura (enumerazione e scrittura in tutte le posizioni) e quindi round robin (o altro algoritmo di bilanciamento del carico) per la lettura.

Se un nodo non è raggiungibile o non esiste un file, il bilanciamento del carico potrebbe "eseguire il failover" sul successivo in linea. Le directory principali potrebbero anche essere contrassegnate offline per le interruzioni pianificate se il codice di lettura/scrittura lo rispettava. Lo stesso potrebbe essere usato anche per il partizionamento in cui il numero x delle directory root serve ID dispari e il numero x serve anche solo come esempio.

Assicurarsi che i nodi siano sincronizzati potrebbe essere codificato utilizzando anche i metadati.

Solo i miei 2 centesimi come non ho mai trattato con quel volume di file prima.

Answer 4

OK, prima un avvertimento, MongoDB ha una limitazione sulla dimensione del documento. Tuttavia, la versione più recente coprirà le dimensioni di 10 MB.

Quindi alcuni punti utili per MongoDB.

Idealmente, mi piacerebbe che la soluzione di archiviazione fosse facilmente scalabile orizzontalmente, con ridondanza tra i server (ad esempio, ogni documento memorizzato su almeno 3 nodi) con un facile recupero dei server bloccati.

Per la replica, MongoDB supporta replica sets. I set di replica sono repliche a singolo master. Se il master scende, il sistema elegge automaticamente un nuovo master (recupero facile). Aggiungere un nuovo nodo è semplice come avviare un nuovo server e puntare al set esistente.

Per scalabilità orizzontale, MongoDB supporta sharding. Sharding è un po 'più complesso, ma funziona come ci si aspetterebbe, suddividendo le scritture su più macchine (o più set di repliche).

ho bisogno di memorizzare centinaia di migliaia (in questo momento, potenzialmente molti milioni) di documenti che partono vuoti e vengono aggiunti frequentemente

Diverse aziende hanno Mongo in esecuzione miliardi di documenti in produzione.

Mongo fornisce una serie di update modifiers che sono molto utili nel caso di "aggiunto a". In particolare controlla l'operatore $ push che aggiunge alla fine di un array. Dovrebbe essere esattamente quello di cui hai bisogno.

Gli accessi in lettura sono alcuni sottoinsiemi del documento, che inizia quasi sempre a metà percorso in qualche posizione indicizzata (ad esempio "documento 4324319, salva # 53 alla fine").

MongoDB consente di restituire solo i campi di selezione (come previsto). A seconda del layout, è possibile utilizzare dot notation per recuperare solo determinati documenti secondari. Se gli aggiornamenti vengono implementati come array, è possibile utilizzare anche lo $slice command che è adatto alla query che si elenca sopra.

Quindi penso che MongoDB soddisfi tutti i tuoi bisogni di base qui. Facile da accodare, facile interrogare gli allegati e la replica è incorporata. Si ottiene il ridimensionamento orizzontale tramite sharding (prova ad iniziare prima con una replica)

Answer 5

Controlla il nostro file system virtuale SolFS. Funzionerà bene nelle tue condizioni.