Quale DB NoSQL in cluster per uno scopo di memorizzazione dei messaggi?

Question

Ancora un'altra domanda su quale NoSQL scegliere. Tuttavia, non ho ancora trovato qualcuno che chiede questo tipo di scopo, memorizzazione dei messaggi ...

Ho un Erlang Chat Server fatto, sto già usando MySQL per memorizzare la lista di amici, e "JOIN needed" informazioni.

Vorrei memorizzare Messaggi (che l'utente non ha ricevuto perché era offline ...) e recuperarli.

Ho fatto una pre-selezione di NoSQL, non posso usare cose come MongoDB a causa del suo paradigma orientato alla RAM, e non riesco a cluster come gli altri. Ho la mia lista a 3 scelte immagino:

• HBase
• Riak
• Cassandra

So che il loro modello sono smettere diverso, uno che utilizza chiave/valore, l'altra usando SuperColumns e co.

Fino ad ora avevo una preferenza per Riak a causa della libreria client stabile per Erlang.

So che posso usare Cassandra con parsimonia, ma non sembra molto stabile con Erlang (non ho buoni rendimenti su di esso)

Io in realtà non so nulla di HBase in questo momento, solo sapere che esiste e si basa su Dynamo come Cassandra e Riak.

Quindi, ecco cosa devo fare:

• Store dal 1 ai messaggi X A utente registrato.
• Ottieni il numero di messaggi memorizzati per utente.
• recupera tutti i messaggi da un utente in una volta.
• elimina tutti i messaggi da un utente in una volta.
• eliminare tutti i messaggi più vecchi di X mesi

In questo momento, sono davvero una novità per coloro NoSQL DB, ho sempre stato un aficionados di MySQL, questo è il motivo per cui vi chiedo questa domanda, come un novizio , qualcuno che ha più esperienza di me potrebbe aiutarmi a scegliere quale è migliore, e vorrei lasciarmi fare tutto ciò che voglio senza molto fastidio ...

Grazie!

Answer 1

Non riesco a parlare per Cassandra o Hbase, ma lasciatemi indirizzare la parte Riak.

Sì, Riak sarebbe appropriato per il tuo scenario (e ho visto diverse aziende e social network usarlo per uno scopo simile).

Per implementare ciò, sono necessarie le normali operazioni Chiave/Valore Riak, oltre a una sorta di motore di indicizzazione. Le opzioni disponibili sono (in ordine di massima di preferenza):

1. CRDT Imposta. Se la dimensione della raccolta 1-N è di dimensioni ragionevoli (diciamo, ci sono meno di 50 messaggi per utente o altro), è possibile memorizzare le chiavi della collezione figlio in un CRDT Set Data Type.

2. Riak Cerca. Se la dimensione della raccolta è grande e, in particolare, se è necessario cercare i propri oggetti su campi arbitrari, è possibile utilizzare Riak Search. Spiega Apache Solr in background e indicizza gli oggetti secondo uno schema definito dall'utente. Ha una ricerca, aggregazione e statistica, capacità geospaziali ecc. Davvero straordinarie

3. Indici secondari. È possibile eseguire Riak su un eLevelDB storage back end e abilitare la funzionalità Secondary Index (2i).

Eseguire alcuni test delle prestazioni, per scegliere l'approccio più rapido.

Per quanto riguarda lo schema, è consigliabile utilizzare due bucket (per l'impostazione che si descrive): un bucket utente e un bucket di messaggi.

Indicizzare il bucket del messaggio. (O associando un indice di ricerca con esso, o memorizzando un user_key tramite 2i). Ciò consente di fare tutte le operazioni necessarie (e il log dei messaggi non deve entrare nella memoria):

• Store dal 1 ai messaggi X A utente registrato - Una volta che si crea un oggetto utente e ottenere un chiave utente, memorizzare una quantità arbitraria di messaggi per utente è facile, dovrebbero scrivere direttamente nel bucket del messaggio, ogni messaggio memorizza la chiave_utente appropriata come indice secondario.
• Ottieni il numero di messaggi memorizzati per utente - Nessun problema. Ottieni l'elenco delle chiavi dei messaggi appartenenti a un utente (tramite una query di ricerca, recuperando l'oggetto Set in cui si tengono le chiavi o tramite una query 2i su user_key). Questo ti consente di ottenere il conteggio sul lato client.
• recuperare tutti i messaggi da un utente in una volta - Vedere l'elemento precedente. Ottieni l'elenco delle chiavi di tutti i messaggi appartenenti all'utente (tramite Cerca, Imposta o 2i), quindi recupera i messaggi effettivi per tali chiavi recuperando più volte i valori per ciascuna chiave (tutti i client Riak ufficiali hanno una capacità multiFetch, dalla parte del cliente).
• eliminare tutti i messaggi da un utente in una volta - Molto simile. Ottieni l'elenco delle chiavi dei messaggi per l'utente, problema Elimina a loro dal lato client.
• eliminare tutti i messaggi precedenti a X mesi - È possibile aggiungere un indice su Data. Quindi, recupera tutte le chiavi dei messaggi più vecchie di X mesi (tramite Ricerca o 2i), ed emette le cancellazioni lato client per loro.

Answer 2

Non posso parlare a Riak affatto, ma dubito della tua scelta di scartare Mongo. È abbastanza buono se lasci il diario spento e non lo affoghi completamente per la RAM.

So parecchio su HBase e sembra che soddisfi facilmente le vostre esigenze. Potrebbe essere eccessivo a seconda di quanti utenti hai. Supporta banalmente cose come la memorizzazione di molti messaggi per utente e ha funzionalità per la scadenza automatica delle scritture. A seconda di come si progetta il proprio schema, potrebbe essere o meno atomico, ma ciò non dovrebbe avere importanza per il proprio caso d'uso.

Gli svantaggi sono che c'è un sovraccarico per configurarlo correttamente.Devi conoscere Hadoop, far funzionare HDFS, assicurarti che il tuo namenode sia affidabile, ecc. Prima di alzarti in piedi con HBase.

Answer 3

Si consiglia di utilizzare l'archivio chiavi/valore distribuito come Riak o Couchbase e mantenere l'intero registro dei messaggi per ogni utente serializzato (in termini di binario di erlang o JSON/BSON) come un valore.

Quindi, con i vostri casi d'uso che sarà del tipo:

• Store dal 1 ai messaggi X A utente registrato - quando l'utente viene di spawn on-line un stateful gen_server, che ottiene dallo stoccaggio e deserializza intero messaggio accedere all'avvio, ricevere nuovi messaggi, accodarli alla sua copia del log, alla fine della sessione termina, serializza il log modificato e lo invia all'archiviazione.
• Ottenere il numero di messaggi memorizzati per utente - ottenere il logout, deserializzare, contare; o magari memorizzare il conto a fianco in una coppia k/v separata.
• recuperare tutti i messaggi da un utente in una volta - basta estrarlo dalla memoria.
• eliminare tutti i messaggi da un utente in una volta - è sufficiente eliminare il valore dalla memoria.
• Elimina tutti i messaggi precedenti a X mesi - get, filter, put back.

La limitazione ovvia: il registro dei messaggi deve essere inserito nella memoria.

Se si decide di archiviare ciascun messaggio singolarmente, sarà necessario dal database distribuito per ordinarli dopo il recupero se si desidera che siano in ordine cronologico, quindi difficilmente sarà di aiuto gestire i set di dati di memoria maggiore della memoria. Se è necessario, arriverà comunque a uno schema più complicato.