DB ad alte prestazioni per lettura veloce e scrittura veloce. Nessun aggiornamento o eliminazione

Question

Sto cercando il database/meccanismo per memorizzare i dati in cui posso scrivere i dati e leggere i dati con prestazioni elevate.

Questa memoria è utilizzata per memorizzare la registrazione come informazioni importanti su più sistemi. Since it's critical data which will be logged, read performance should be pretty fast as these data will be used to show history. Since we never do update on them/delete on them/or do any kinda joins, I am looking for right solution. Probabilmente potremmo archiviare i dati a lungo, ma è qualcosa di buono da gestire.

ho provato guardando diverse fonti per comprendere diversi database NoSQL, gli esperti parere è sempre meglio :)

Must Have: 
1. Fast Read without fail 
2. Fast Write without fail 
3. Random access Performance 
4. Replication kinda feature, one goes down, immediately another should be up and working 
5. Concurrent write/read data 

Good to Have: 
1. Search content like analysing the data for auditing with/without Indexes 

Don't required: 
1. Transactions are not required at all 
2. Update never happens 
3. Delete never happens 
4. Joins are not required 

Di cui: http://kkovacs.eu/cassandra-vs-mongodb-vs-couchdb-vs-redis

Answer 1

mi permetta di essere il Cassandra sponsor.

Declinazione di responsabilità: Non dico che Cassandra è migliore degli altri perché non conosco nemmeno così profondamente mongo/redis/qualsiasi altra cosa e non voglio nemmeno entrare in questo genere di cose.

Il motivo per cui vi consiglio di Cassandra è perché vostre esigenze si sposano perfettamente con quello che Cassandra offre e la vostra "lista non necessaria" è un insieme di funzionalità che non sono né supportato in Cassandra (si unisce per le istanze) o considerati un anti-pattern (cancella e in alcune situazioni aggiornamenti).

Dal vostro "must have" lista, punto per punto

1. veloce lettura a colpo sicuro: supportati. È possibile scegliere il livello di coerenza di ogni operazione leggere decidere quanto importante è quello di recuperare le informazioni più fresco e quanto importante è la velocità

2. veloce scrittura a colpo sicuro: come il punto 1

3. Random access Performance: Quando entri nel mondo di Cassandra devi considerare molti parametri per ottenere prestazioni di accesso casuale, ma la cosa più importante che mi viene in mente è il modello di dati: se crei un modello di dati che scala orizzontalmente (give a look here) e si evitano gli hotspot si ottiene quello che ti serve. Se si modella vostro DB in senso buono si dovrebbe avere O (1) per ogni operazione in quanto i dati sono strutturati per essere interrogato

4. replica: In questo Cassandra è anche meglio di quanto si possa pensare . Se un nodo scende, nulla cambia nel cluster e tutto (*) continua a funzionare perfettamente. Cassandra non individua un singolo punto di errore. Posso dirvi con vecchia versione Cassandra Ho avuto un uptime di oltre 3 anni

5. scrittura simultanea/leggere i dati: Cassandra utilizza il criterio LWW (ultimo-write-vittorie) per gestire le scritture contemporanee sulla stessa chiave. Il sistema supporta più read-write e con protocolli più recenti anche operazioni asincrone.

Ci sono un sacco di altre caratteristiche interessanti Cassandra offre: ridimensionamento orizzontale lineare è quello che apprezzo di più, ma c'è anche il fatto che si può conoscere l'istante in cui ogni pezzo di dati è stata aggiornata (il timestamp di lww), funzionalità di contatori e così via.

(*) - se non si utilizza il livello di coerenza Tutto ciò che, imho, non deve MAI essere utilizzato in tale sistema.

Answer 2

Assicurarsi di considerare Aerospike; Aerospike domina nello spazio adtech in cui le letture e le scritture high throughput sono obbligatorie. L'aerospike viene spesso pubblicizzato come avente "la velocità di Redis con la scalabilità di Cassandra". Per la ricerca/interrogazione consultare la documentazione di Aerospike secondary index.

Per ulteriori informazioni si veda la discussione/articoli qui sotto:

1. Aerospike vs Cassandra
2. Aerospike vs Redis and Mongo
3. Aerospike Benchmarks

infine verificare le prestazioni per te stesso con la One million TPS on EC2 Instructions.

Answer 3

Ecco un paio di link su come si può estendersi in-memory con Disk (DRAM, SSM e storage su disco) w/Aerospike:

http://www.aerospike.com/hybrid-memory/

http://www.aerospike.com/docs/architecture/storage.html

Credo che ognuno è giusto in termini di abbinamento del DB specifico al tuo caso d'uso specifico. Ad esempio, Aerospike è ottimale per i dati valore-chiave. Altre opzioni potrebbero essere migliori.

A titolo di analogia, ricorderò sempre come, una decina di anni fa, una mia sorella ha preso in prestito il mio computer e ha scritto la sua tesina in Microsoft Excel. Riga dopo riga era una riga diversa di un foglio di calcolo. Sembrava brutto come diamine, ma, okay. Ha fatto il lavoro. Ha imprecato e ha giurato su quanto sia stato difficile modificare la cosa. Non sto scherzando!

La scelta del database NoSQL corretto per l'attività corretta renderà il tuo lavoro un gioco da ragazzi, o potrebbe farti imprecare una striscia blu se hai deciso di utilizzare lo strumento di base sbagliato per il compito da svolgere.

Ovviamente, ogni venditore ha intenzione di difendere il proprio prodotto. Penso che sia meglio che la comunità risponda alla domanda. Ecco un altro thread Stack Overflow rispondere a una domanda simile:

Has anyone worked with Aerospike? How does it compare to MongoDB?

btw: Avete delle intuizioni più specifiche per noi su che tipo di problema che si sta cercando di risolvere?