Ottimo modo per memorizzare 18 miliardi di chiavi, coppie di valori [chiusa]

5

Ho circa 200 milioni di nuovi oggetti in arrivo e una politica di conservazione di 90 giorni, quindi mi rimangono 18 miliardi di record da memorizzare sotto forma di coppie chiave-valore.

Chiave e valore saranno entrambi una stringa. Si tratta fondamentalmente di una mappatura tra un identificativo univoco per l'oggetto nell'applicazione all'identificatore univoco per l'oggetto nell'archiviazione effettiva dell'oggetto.

Esiste un'applicazione che carica oggetti in un sistema operativo Web. Per ogni oggetto caricato, crea una stringa di 16 caratteri, ad esempio DataID. Il sistema operativo Web stesso crea una stringa di 40 caratteri, ad esempio ObjectID. Quindi quello che sto cercando di fare è creare un mapping tra DataID - > ObjectID per 18 miliardi di oggetti. Non conosco il meccanismo utilizzato per creare gli ID.

Dovrò occuparmi di:

write(key,value)
read(key)
delete(key,value)

Sto cercando idee per un modo ottimale per implementarlo. Dovrebbe essere ottimizzato per letture e amp; scrive. L'ottimizzazione dello spazio è secondaria.

So che Hadoop / NoSQL è un modo per andare, e probabilmente un'altra soluzione verrà distribuita nelle tabelle di hash, ma alcune altre opzioni mi aiuteranno a decidere quale sia la soluzione migliore. Un database relazionale non è un'opzione in quanto non disponiamo di un RDBMS esistente nell'ambiente corrente.

    
posta Chaos 05.06.2013 - 20:12
fonte

2 risposte

5

Prova redis . È tutto in memoria e scarica i dati in modo che possa essere caldo al reset. Tuttavia, potrebbe essere necessario fare attenzione e modificare le impostazioni se è necessario non perdere dati poiché normalmente attende un secondo o due prima di eseguire il dumping (o ho dimenticato le impostazioni predefinite errate?).

Utilizza un hash in cui GUID / 6 o 7 bit è la chiave e il rimanente è un campo link . Notare che avere più nomi di campo rende più lento quindi attenersi a < = 128 come regola personale. Raccomando di avere 64 o 32 bit ma testare con il keylength.

La ragione per cui dico usare un hash è diminuire l'utilizzo della memoria. Più campi = meno puntatori (e un aumento del tempo di CPU)

    
risposta data 06.06.2013 - 01:01
fonte
5

Guarda questi negozi di valore-chiave: Berkeley DB Java Edition , o JDBM ( JDBM3 è l'ultimo) o MapDB (successore JDBM). Tokyo Cabinet non è nativo Java ma ha un wrapper Java.

Per una panoramica, consulta link .

    
risposta data 06.06.2013 - 00:03
fonte

Leggi altre domande sui tag