Esiste qualcosa come Redis DB, ma non limitato alla dimensione della RAM?

Question

Sto cercando un database corrisponde ai criteri richiesti:

• può essere non-persistente;
• Quasi tutte le chiavi di DB devono essere aggiornati una volta ogni 3-6 ore (100m + tasti con dimensione totale di 100GB)
• Possibilità di selezionare rapidamente i dati di chiave (o chiave primaria)
• Questo deve essere un DBMS (così LevelDB non va bene)
• Quando i dati vengono scritti, gruppo DB deve essere in grado di servire le query (singoli nodi possono essere bloccati però)
• non in memoria - il nostro set di dati supererà i limiti di RAM
• Ridimensionamento orizzontale e replica
• Supporto completo riscrittura e di tutti i dati (MongoDB non lo fa spazio libero dopo l'eliminazione dei dati)
• C# e il supporto Java

Ecco il mio processo di lavoro con tale banca dati: Abbiamo un gruppo di analisi che produce dischi 100M (50 GB) di dati ogni 4-6 ore. Il dato è un "key - array [20]". Questi dati devono essere distribuiti agli utenti attraverso un sistema front-end con una frequenza di 1-10k di richieste al secondo. In media, viene richiesto solo il ~ 15% dei dati, il resto verrà riscritto in 4-6 ore quando viene generato il set di dati successivo.

quello che ho provato:

1. MongoDB. Sovraccarico di Datastorage, costi elevati di deframmentazione.
2. Redis. Sembra perfetto, ma è limitato alla RAM e i nostri dati lo superano.

Quindi la domanda è: c'è qualcosa come Redis, ma non limitato con la dimensione della RAM?

Answer 1

In questi giorni è possibile trovare facilmente server con più di 100 GB di RAM per ospitare una singola istanza, oppure è possibile suddividere i dati e utilizzare diversi server con meno RAM. Memorizzare 100 GB con Redis (in RAM) non è davvero un problema.

Ora, se si vuole veramente provare un clone di bleeding-edge di Redis non limitato alla memoria di lavoro, c'è NDS (da Matt Palmer):

• http://www.anchor.com.au/blog/2013/04/redis-rethought-exciting-extremes-with-larger-than-memory-datasets/

• https://github.com/mpalmer/redis/tree/nds-2.6

Si noti che il backend di archiviazione di NDS si è spostato da Kyoto Cabinet a LMDB (un ottimo pacchetto, che alimenta anche OpenLDAP), precisamente perché uso dei problemi di recupero dello spazio dopo le chiavi cancellate.

Altre soluzioni - non compatibili con Redis - possono anche soddisfare le vostre esigenze: Couchbase e Aerospike, ad esempio, potrebbero facilmente supportare il vostro throughput. Cassandra e Riak probabilmente funzionerebbero anche se hai abbastanza nodi.

Answer 2

Sì, ci sono due alternative al Redis che non si limitano alla memoria di lavoro, pur rimanendo compatibile con Redis protocollo:

Ardb (C++), la replica (master-slave/master-master): https://github.com/yinqiwen/ardb

Un server di archiviazione persistente compatibile con protocollo redis, supporta LevelDB/KyotoCabinet/LMDB come motore di archiviazione.

Edis (Erlang): http://inaka.github.io/edis/

Edis è una sostituzione Server protocollo-compatibile per Redis, scritto in Erlang . L'obiettivo di Edis è di essere un rimpiazzo sostitutivo per Redis quando la persistenza dello è più importante che mantenere il set di dati in memoria. Edis (attualmente) usa il leveldb di Google come back-end.

E per completezza qui è un altro database di strutture dati:

Hyperdex (stringhe, interi, galleggianti, liste, insiemi, Maps): http://hyperdex.org/doc/latest/DataTypes/#chap:data-types

HyperDex è:

• Veloce: HyperDex ha latenza inferiore, velocità effettiva superiore e inferiore a varianza rispetto ao altri negozi con valore chiave.
• Scalabile: HyperDex scala come altre macchine vengono aggiunte al sistema.
• Coerente: HyperDex garantisce la linearizzazione per le operazioni basate su tasti. Pertanto, una lettura restituisce sempre l'ultimo valore inserito nel sistema. Non solo "alla fine", ma immediatamente e sempre.
• Fault Tolerant: HyperDex automaticamente replica i dati su più macchine in modo che i guasti simultanei, fino a a un limite determinato dall'applicazione, non causino la perdita di dati. Disponibile per la ricerca:
• HyperDex consente ricerche efficienti di dati secondari attributi.
• Facile da usare: HyperDex fornisce API per una varietà di script e lingue native.
• Autonomo: un HyperDex è auto-manutenzione e richiede poca manutenzione da parte dell'utente.

Answer 3

Sì, SSDB (https://github.com/ideawu/ssdb), ha API molto simili a Redis: http://www.ideawu.com/ssdb/docs/php/

SSDB supporta hash, zset. Utilizza leveldb come motore di archiviazione, la maggior parte dei dati viene archiviata su disco, la RAM viene utilizzata per la cache. Nella nostra istanza SSDB con dati da 300 GB, utilizza solo 800 MB di RAM.