2012-11-18 13 views
6

Sto cercando un archivio di valori chiave che possa essere utilizzato da un'istanza EC2.Scrivere un archivio di valori-chiave pesante, replicato, più grande della memoria

  • voce è solo una stringa non strutturato, senza indicizzazione richiesto
  • elemento dimensione fino a ~ 5 MB, ma di solito sotto 10kB
  • un sacco di scrittura
  • lettura non ha bisogno di essere veloce, può essere memcache messo di fronte che le cache necessari frequentemente legge
  • dati è troppo grande per entrare in memoria
  • coerenza eventuale va bene
  • demone che si può accedere fr macchine multiple om è richiesto

Idealmente qualcosa AWS ospitato sarebbe perfetto, ma:

  • S3 non si adatta a causa delle troppe scritture
  • SimpleDB/DynamoDB non si adattano a causa delle dimensioni voce limiti e indicizzazione non sono richiesti

Poiché ci sono molti negozi con valore chiave sul mercato, è difficile scegliere il migliore. Quale raccomanderesti?

+0

Non dire se – clh

+0

@ caius.howcroft: cosa intendi con questo? –

+0

sorry typo, non mi sono accorto di averlo commesso – clh

risposta

6

ho trovato la soluzione perfetta per il mio caso d'uso: memcachedb

Non fa fantasia documento/indicizzazione, è solo un semplice negozio di valore chiave.

Non ho ancora eseguito alcun test delle prestazioni.

Edit:

abbiamo abbassato memcachedb a causa di problemi con la replica. Invece corriamo ora mongodb. Mongodb richiede molto più spazio su disco e più risorse in generale. Ma i set di repliche funzionano in modo molto affidabile e sono facili da configurare.

+0

È possibile utilizzare Couchbase che consente un accesso molto rapido alla chiave utilizzando il protocollo memcached. Couchbase ti consente di memorizzare qualsiasi tipo di contenuto associato alla chiave. Couchbase 2.0 è un DB orientato al documento ma è possibile memorizzare qualsiasi tipo di contenuto binario. Dai uno sguardo a questo documento che ti aiuterà a vedere alcuni dei principali vantaggi: http://www.couchbase.com/memcached –

+0

@TugGrall: Penso che non funzionerà con il mio caso, dato che i dati sono troppo grandi per adattarsi alla memoria. –

+0

Se si sceglie un "Couchbase Bucket", esso memorizzerà automaticamente il contenuto sul disco quando necessario: http://www.couchbase.com/docs/couchbase-manual-1.8/couchbase-architecture-buckets.html –

2

Forse si dovrebbe cercare MongoDB:
http://www.mongodb.org/display/DOCS/Amazon+EC2

Avvio rapido:
http://www.mongodb.org/display/DOCS/Amazon+EC2+Quickstart

corsi gratuiti su 10gen e video presentazioni:
http://www.10gen.com/presentations/nyc-meetup-group/mongodb-and-ec2-a-love-story

Altri stoccaggi chiave-valore:
http://google-opensource.blogspot.com/2011/07/leveldb-fast-persistent-key-value-store.html

Commenti su Riak ed i loro depositi in particolare bitcask e innostore:
http://basho.com/blog/technical/2011/07/01/Leveling-the-Field/

RaptorDB: Una dimensioni estremamente ridotte e veloce incorporato, NoSQL, persistevano database di dizionario con b + albero o mormorare hash indicizzazione. È stato progettato principalmente per archiviare dati JSON (vedere la mia implementazione fastJSON), ma può memorizzare qualsiasi tipo di dati che gli viene fornito.

Hamsterdb: Un delizioso motore scritto in C++, il che mi ha colpito molto per la sua velocità, mentre stavo usando il codice Aarons Watters per l'indicizzazione. (RaptorDB lo mangia vivo ora ... ehm!) È abbastanza grande a 600KB per l'edizione a 64 bit di .

ESENT PersistentDictionary: Un progetto su CodePlex, che fa parte di un un altro progetto che implementa un wrapper gestito sul costruito nel di Windows motore di archiviazione dei dati ESE.Le prestazioni del dizionario vanno in modo esponenziale dopo 40.000 elementi indicizzati e il file indice appena cresce su chiavi guida. Apparentemente dopo i colloqui con i proprietari del progetto, al momento è un problema noto.

Tokyo/Kyoto Cabinet: A C++ implementazione di keystore che è molto veloce. Il cabinet di Tokyo è un indexer b + tree mentre il cabinet di Kyoto è un indicizzatore di hash MurMur2.

4aTech Dizionario: questo è un altro articolo su CodeProject che fa la stessa cosa, la versione commerciale presso il sito web è enorme (450KB) e fallisce miseramente Performance saggio sui tasti GUID dopo 50.000 articoli indicizzati.

BerkeleyDB: The Grand Daddy di tutti i database che è di proprietà di Oracle ed è disponibile in 3 gusti, C++ chiavi, Java e XML chiavi database.

(fonte Quotazione: http://www.codeproject.com/Articles/190504/RaptorDB)

+0

Ho preso in considerazione mongodb - ma sembra troppo progettato per me: non ho bisogno di archiviazione dei documenti, indicizzazione, riduzione della mappa ecc. –

+0

Forse Redis o sth menzionati qui: http: // stackoverflow.com/questions/1733619/writing-a-key-value-store – 42n4

+0

Ho bisogno di un server. Redis non funziona in quanto i miei dati sono troppo grandi per essere archiviati in memoria. –

2

Sembra una custodia perfetta per HBase. Offre un ottimo throughput di scrittura, soprattutto se le chiavi di inserimento sono alquanto casuali. HBase non è solitamente pubblicizzato come un negozio K/V, ma dovrebbe funzionare bene. Il AWS documentation presenta alcuni casi d'uso che si potrebbe voler dare un'occhiata più da vicino. Il rovescio della medaglia è che HBase può fare molto più che solo K/V, quindi potrebbe essere più complesso (e complicato) di quello che ti serve.

1

Couchbase sembra una buona corrispondenza per le vostre esigenze. È come avere memcached con l'archiviazione su disco.

Pro:

  • Si tratta di un database chiave/valore. È possibile memorizzare qualunque blob binario che si desidera. A partire dalla versione 2.0 ha il supporto per l'archiviazione dei dati come json e l'esecuzione di alcune query e mappa/riduzione su di esso. Ma se non ne hai bisogno, usarlo come chiave/valore funziona alla grande.

  • Di tutti i database NoSQL che ho provato, è il più veloce. Ciò potrebbe essere dovuto al fatto che le tue scritture non vengono immediatamente trasferite sul disco. Invece, si ottiene un riconoscimento una volta che una scrittura viene replicata nel cluster. I dati vengono scritti sul disco in modo asincrono. Quindi, uno svantaggio potenziale è che se tutti i nodi si bloccano contemporaneamente (ad esempio, il tuo data center perde potenza), potresti perdere i dati. A seconda dell'applicazione, questo può o non può essere un problema (e se tutto il tuo cluster va giù, probabilmente hai problemi più grandi).

  • Nella mia esperienza è stato affidabile. Se un nodo si interrompe, il cluster continua a funzionare ed è molto facile eseguire un failover. Anche aggiungere nuovi nodi è abbastanza facile.

  • I dati non devono essere memorizzati. Viene memorizzato su disco e inserito e disinserito come necessario.

  • L'interfaccia di amministrazione è molto, molto bella. Ha grafici live nifty per monitorare il cluster.

  • È retrocompatibile con il protocollo memcached. Se hai già un codice che usa memcached, sarebbe piuttosto semplice usare invece Couchbase.

Contro:

  • Il prodotto è ancora un po 'giovane, quindi documentazione e supporto strumenti sono un po' carente. Questo può essere un po 'fastidioso a volte.
Problemi correlati