Perché il tiranno tokyo rallenta in modo esponenziale anche dopo aver regolato il bnum?

Question

Qualcuno ha usato con successo Tokyo Cabinet/Tokyo Tyrant con grandi set di dati? Sto cercando di caricare un sottografo della fonte dati di Wikipedia. Dopo aver raggiunto circa 30 milioni di record, ottengo un rallentamento esponenziale. Ciò si verifica con entrambi i database HDB e BDB. Ho regolato il bnum per 2-4x il numero previsto di record per il caso HDB con solo una leggera accelerazione. Ho anche impostato xmsiz a 1 GB o giù di lì, ma alla fine ho ancora colpito un muro.

Sembra che Tokyo Tyrant sia fondamentalmente un database in memoria e dopo aver superato il xmsiz o la RAM, si ottiene un database a malapena utilizzabile. Qualcun altro ha già riscontrato questo problema? Sei riuscito a risolverlo?

Answer 1

Credo di aver incrinato questo, e non ho visto questa soluzione in qualsiasi altro luogo. Su Linux, ci sono generalmente due ragioni per cui Tokyo inizia a rallentare. Passiamo attraverso i soliti colpevoli. Innanzitutto, se si imposta il bnum troppo basso, si desidera che sia almeno uguale alla metà del numero di elementi nell'hash. (Preferibilmente di più.) In secondo luogo, si desidera provare a impostare il proprio xmsiz in modo che sia vicino alla dimensione dell'array di bucket. Per ottenere la dimensione dell'array bucket, basta creare un db vuoto con il bnum corretto e Tokyo inizializzerà il file alla dimensione appropriata. (Ad esempio, bnum = 200000000 è circa 1,5 GB per un db vuoto.)

Ma ora, noterete che rallenta ancora, anche se un po 'più avanti. Abbiamo scoperto che il trucco consisteva nel disattivare journalling nel filesystem - per qualche ragione i picchi di journalling (su ext3) quando le dimensioni del tuo file hash crescono oltre i 2-3 GB. (Il modo in cui ci siamo resi conto dei picchi di I/O non corrispondevano alle modifiche del file su disco, a fianco dei demoni CPU burst di kjournald)

Per Linux, basta smontare e rimontare la partizione ext3 come ext2. Costruisci il tuo db e rimonta come ext3. Quando il journaling era disabilitato potevamo costruire un db di dimensioni di 180M senza problemi.

Answer 2

Sto iniziando a lavorare su una soluzione per aggiungere sharding al cabinet di tokyo chiamato Shardy.

http://github.com/cardmagic/shardy/tree/master

Answer 3

Il negozio di valore chiave di Tokyo Cabinet è davvero buono. Penso che le persone lo chiamino lento perché usano il negozio simile a un tavolo di Tokyo Cabinet.

Se si desidera memorizzare i dati del documento, utilizzare mongodb o qualche altro motore nosql.

Answer 4

Tokyo squama meravigliosamente !! Ma devi impostare il tuo bnum e xmsiz in modo appropriato. Il bnum dovrebbe essere da 0,025 a 4 volte maggiore dei record che si intende memorizzare. xmsiz dovrebbe corrispondere alla dimensione di BNUM. Impostare anche opts = l se si prevede di memorizzare più di 2 GB.

Vedere il post di Greg Fodor in alto su come ottenere il valore per la dimensione di xmsiz. Fai attenzione a notare che quando si imposta xmsiz il valore è in byte.

Infine, se si utilizza un hash basato su disco, è molto, molto, MOLTO importante disattivare l'inserimento nel journal sul filesystem su cui vivono i dati di tokyo. Questo è vero per Linux, Mac OSX e probabilmente Windows anche se non l'ho ancora testato lì.

Se l'inserimento del diario è attivato, si noteranno forti cali di prestazioni quando ci si avvicina a oltre 30 milioni di righe. Con il journaling disattivato e altre opzioni impostate correttamente, Tokyo è un ottimo strumento.