Motore di archiviazione file super veloce

Naviga le tue risposte
2

In pratica ho un grande tavolo gigantesco (circa 1.000.000.000.000 di record) in un database con questi campi:

id, block_id, record

id è univoco, block_id non è univoco, contiene circa 10k (max) record con lo stesso block_id ma con record diversi

Per semplificare il mio lavoro che riguarda il DB, ho un'API simile a questa: 

Engine e = new Engine(...);
// this method must be thread safe but with fine grained locked (block_id) to improve concurrency
e.add(block_id, "asdf"); // asdf up to 1 Kilobyte  max

// this must concatenate all the already added records added block_id, and won't need to be bigger than 10Mb (worst case) average will be <5Mb
String s = e.getConcatenatedRecords(block_id);

Se mappo ciascun blocco su un file (non l'ho ancora fatto), ogni record sarà una riga nel file e potrò ancora usare quell'API

Ma voglio sapere se avrò un vantaggio in termini di performance utilizzando file flat rispetto a un database postgresql ben sintonizzato? (almeno per questo specifico scenario)

Il mio più grande requisito è che il metodo getConcatenatedRecords ritorni stupidamente veloce (non così con l'operazione di aggiunta). Sto considerando anche il caching e la mappatura della memoria, ma non voglio complicarmi prima di chiedere se esiste già una soluzione per questo tipo di scenario?

    
posta David Hofmann 31.01.2014 - 19:01
fonte

3 risposte

2

Dopo alcune ricerche. Ho scoperto che questi archivi dati rappresentano la maggior parte dei casi d'uso che ho:

La parte interessante è che restituiscono principalmente l'API delle raccolte java (elenchi, insiemi, mappe ...)

Tutti questi progetti mi consentono di aprire un file come archivio dati di enormi collezioni e posso fare riferimento ad esse per nome, e ci possono essere molte raccolte per file. Ognuno di loro sono indicizzati. L'idea è che questi progetti siano utilizzati come base per veri database, è possibile vederli come il motore di archiviazione dati del database (sia esso SQL o NoSQL).

Poiché questi progetti sono la base per progetti come mongodb, h2database e orientdb, allora sono sicuro che se l'approccio del datastore semplicistico si adatta alle mie esigenze, si ridimensionerà anche senza problemi. Poiché la mia partizione ha bisogno di essere molto semplicistica, posso anche condividere il carico con altri nodi.

    
risposta data 05.02.2014 - 00:13
fonte
4

Sembra che il tuo "sistema di archiviazione" sia dotato di un'interfaccia di astrazione molto semplice. In sostanza si riduce a "ecco un ID, dati gimme".

Quindi puoi facilmente definire questa interfaccia e costruire l'intera app su di essa. Dietro le quinte puoi continuare ad usare PostgreSQL come fai oggi. E se vuoi sperimentare con l'archiviazione di file flat, dovrebbero impiegare più di 1 o 2 giorni per implementare qualcosa di molto semplice che legge / scrive i file direttamente su disco (la mia raccomandazione è di avere 1-3 livelli di directory basate sulla prima porzione dell'ID, quindi non hai troppi file in una directory flat).

Se lo fai, puoi confrontare il rendimento direttamente e vedere se è abbastanza buono per te.

Tuttavia, come sottolineato da Euforic, la maggior parte dei negozi di NOSQL sono stati introdotti e sono diventati popolari per lo scopo che si sta tentando di realizzare. Non ho intenzione di consigliare un negozio specifico perché è qualcosa che devi decidere, ma alcuni vantaggi che offrono sono:

  1. gestione della memorizzazione di enormi quantità di piccole entità mediante il buffering e l'esecuzione di scritture in blocchi più grandi. Nella mia esperienza la maggior parte dei file system può funzionare con un numero molto elevato di file, ma non nel modo più efficiente. Ad esempio, se si provasse a eliminare molti file dal disco, a meno che non si riformasse l'intero disco, potrebbero essere necessarie più ore solo per il comando "rm -rf *".
  2. Se e quando si superano i limiti di una singola casella fisica, molte soluzioni NoSQL consentono di scalare orizzontalmente il che consentirà di a) più spazio di archiviazione, b) ridondanza dei dati, quindi se un host si arresta, il server di archiviazione è ancora online e c) tempi di interrogazione più rapidi poiché i tuoi clienti possono bilanciare il carico nel punto in cui ottengono le informazioni.

Un'altra opzione da considerare è che potenzialmente non è necessario implementare la memorizzazione e l'indicizzazione nello stesso sistema. È possibile utilizzare un prodotto di indicizzazione separato come Solr o Elasticsearch e archiviare i dati effettivi in un DB NoSQL (o un file system diretto)

    
risposta data 31.01.2014 - 21:09
fonte
2
I database

NoSQL a valori-chiave sono praticamente fatti per questo scenario. Nel tuo caso, stai cercando qualcosa come indice secondario in cima all'archivio dei valori-chiave.

Non ho esperienza in questo campo, quindi non posso dirvi implementazione o strumenti concreti da utilizzare. Ma credo che tu possa trovare qualcosa che soddisfi le tue esigenze.

    
risposta data 31.01.2014 - 19:07
fonte

Leggi altre domande sui tag

Da Java a Javascript? [duplicare] Algoritmo di shuffling senza "auto-mappatura"?