Spazio su disco affamato Database NoSQL

Ho testato database NoSQL come CouchDB, MongoDB e Cassandra e ho osservato la tendenza ad assorbire una quantità molto elevata di spazio su disco rispetto alle coppie chiave-valore inserite. Quando si confrontano i database CouchDB e MySQL senza schemi, CouchDB sta consumando molto più spazio su disco rispetto a MySQL. So che i DB con valori-chiave sono di default versioni e hanno un lungo uuid e necessitano di un'ottimizzazione chiave - il confronto era tra circa 15 mln di righe in MySQL e 1-5 mln di documenti elencati nei DB NoSQL.Spazio su disco affamato Database NoSQL

La mia domanda è: c'è qualche NoSQL con una buona compattazione/compressione dei dati? In modo che possa avere database NoSQL con una dimensione più vicina a 5 GB di 50 GB?

fonte

2010-06-09 jlmfao

MongoDB ha una funzione di "riparazione del database" che esegue anche una compattazione. Tuttavia, una tale compattazione non si verificherà mentre il DB è in esecuzione.

Ma se lo spazio DB è un problema serio, provare a configurare una coppia master/slave MongoDB. Poiché i dati richiedono compattazione, esegui la riparazione sullo slave, permettigli di "recuperare" e quindi di cambiarli. Ora puoi tranquillamente compattare il master.

Ma devo echeggiare il commento di jbellis: probabilmente avrete bisogno di più spazio e la maggior parte di questi prodotti presuppone che lo spazio su disco sia (relativamente) economico. Se lo spazio su disco è davvero limitato, allora troverai che MongoDB ha dimensioni ragionevoli, ma sarà difficile competere con i dati CSV tabulari.

Pensate in questo modo, cosa c'è di più efficiente nello spazio?

un file CSV con un milione di linee
che stessi dati formattati in JSON

Ovviamente il JSON sta per essere più lungo b/c si sta ripetendo i nomi dei campi ogni volta. L'unica eccezione qui è un file CSV con 100 colonne di cui solo poche sono riempite per ogni riga. (ma probabilmente non sono i tuoi dati)

fonte

2010-06-10 05:55:17

Questo è vero, se si usano nomi di campo lunghi è necessario più spazio su disco quando si utilizza Mongodb. E Mongodb prealloca file di 2 gigabyte. – TTT

Sì, CouchDB ha l'opzione "compatta" anche dopo il test, riduci più volte la dimensione del db (Cassandra lo fa come "in background" a causa di migliori scritture di massa organizzate). – jlmfao

Piggy su questo, se si tratta di un problema con 1 nodo che ha abbastanza spazio sul disco, provare qualcosa come HBase o Cassandra è molto facile aggiungere più spazio di archiviazione dati (e potenza di elaborazione!) Semplicemente aggiungendo più nodi. Non so come siano strutturati MongoDB/CouchDB, quindi non so se puoi fare facilmente e semplicemente la stessa cosa con loro. – Drizzt321

Si sta controllando la "lunghezza del file" o la dimensione di allocazione effettiva?

Molti database allocano scarsamente le strutture di file e la loro "lunghezza" è molto più grande della loro dimensione su disco.

fonte

2010-06-09 15:44:18

Controllo anche che il buffer di file non è così grande quindi non lo considero nemmeno in db come 15 mln di documenti (anche se saranno pochi GB). Penso che questo "affamato di spazio" sia la settimana di dumb ma non sono sicuro. – jlmfao

Lo spazio su disco è la risorsa più economica oggi, quindi se lo si può scambiare con meno ricerche o meno CPU utilizzate è un buon commercio da fare. Questo è ciò che fa Cassandra.

fonte

2010-06-09 22:56:04 jbellis

Spazio su disco magnetico sì, ma non spazio SSD, che è quello che vorresti un DB ad alte prestazioni memorizzato in ogni caso. Dall'altro lato, le ricerche sugli SSD sono quasi gratuite. Inoltre, il fatto di impacchettare in modo efficiente i dati nelle pagine su disco significa potenzialmente un caching molto più efficace sul livello del buffer di pagina all'interno del DB, un'altra vittoria. – TheManWithNoName

magnetic vs ssd non è monouso; se il tuo hot data set si adatta alla ram (molto comune!) Quindi SSD sta solo buttando giù i soldi. per carichi di lavoro meno prevedibili, vedi Cassandra distribuito su SSD, dove la sua elusione di ricerche su scritture è una grande vittoria per l'amplificazione (non) di scrittura. – jbellis

Penso che il problema sia la chiave. CouchDB memorizza i suoi dati in un albero b. UUID: le chiavi sono la causa per cui è necessaria una grande quantità di spazio su disco. B-tree memorizza i dati compatti per natura escluso UUID. Prova a trovare una chiave più comoda per un b-tree.

fonte

2010-11-11 11:45:02 Dejan

Spazio su disco affamato Database NoSQL

risposta

Problemi correlati