Database di documenti NoSQL come coda di messaggi

Question

Database di documenti NoSQL come coda di messaggi

#1 da (4 voti)
#2 da (2 voti)
#3 da (1 voti)

5

Sto prendendo in considerazione l'utilizzo di un database di documenti NoSQL come coda di messaggistica.

Ecco perché:

Voglio che un client pubblichi un messaggio (qualche oggetto serializzato) sul server e non debba attendere una risposta sincrona.
Voglio essere in grado di estrarre i messaggi dalla "coda" in base a determinati criteri, che possono essere più sofisticati di un semplice livello di priorità (sto lavorando su un'app Web ospitata, quindi voglio dare a tutti i miei clienti una buona quantità di "tempo di calcolo", e non lasciare che un cliente manchi tutta l'elaborazione).
Voglio che la coda sia duratura: se il server si interrompe, desidero che tutti i messaggi rimanenti vengano gestiti al momento del backup.

Quindi, sto considerando di usare MongoDB o RavenDB come una coda di messaggi. Il client può inviare l'oggetto messaggio a un servizio Web che lo scrive nel database. Quindi, il servizio che esegue il lavoro può richiamare i vari tipi di messaggi in base a qualsiasi criterio che possa insorgere. Posso creare indici attorno agli scenari per renderlo più veloce.

Quindi - sto cercando qualcuno che faccia un buco in questo. Qualcuno l'ha fatto con successo? Qualcuno ha provato questo e ha fallito in qualche modo?

nosql message-queue document-databases

posta MattW 07.03.2013 - 21:06

fonte

3 risposte

2

Non ci sono buchi visibili in quanto il tuo elenco dei requisiti è piuttosto breve :-). In pratica quanto più i requisiti sono lunghi, maggiori sono le possibilità di trovare buchi nella scrittura personale.

A mio parere, l'utilizzo di un database NoSQL per questo scenario si adatterebbe:

se i requisiti non sono per una coda con funzionalità complete
se l'app non dovrà spostarsi dal modello pull a un modello push (coda v pub / sub)
la struttura dei messaggi è piuttosto variabile e cambia nel tempo
l'app deve recuperare i messaggi in base a diversi criteri
riutilizzare il database NoSQL ridurrebbe il numero di sistemi da cui l'app dipenderebbe

Come nota a margine, ti incoraggerei (in modo imparziale) anche a dare un'occhiata a RethinkDB.

risposta data 08.03.2013 - 23:04

fonte

1

Sono d'accordo con MrFox. È necessario considerare che se si hanno diversi thread che aggiornano gli stessi dati nella coda, il database deve supportare la transazione ACID vera o si rischia lo stesso articolo in coda per essere elaborato più di una volta, oltre a ottenere duplicati dello stesso elemento in la coda.

Se i dati totali inviati alla coda non si trovano in grandi dimensioni (> PB) di dati, consiglierei di selezionare un altro tipo di database, almeno un database che supporti la coerenza reale.

La coda di processo sarà più adatta per un tipo di database OLTP poiché in pratica stai facendo più inserimenti / aggiornamenti piuttosto che qualsiasi altra cosa.

risposta data 08.03.2013 - 09:32

fonte

Leggi altre domande sui tag nosql message-queue document-databases

Richiede la gestione di riferimento Null esplicita App SourceTree, come faccio a sapere qual è il mio attuale ramo?

score 4 · Accepted Answer

Controlla la risposta accettata su questa domanda: link

La mia opinione di aver lavorato con entrambi i tipi di database è che i vantaggi reali di NoSQL risiedono nella loro scalabilità. Si adattano bene a un numero crescente di elementi che devono esistere su molti nodi. Dopotutto, queste sono le applicazioni da cui sono nati (Facebook, Google ...).

Hanno anche aspetti negativi e sono specifici per l'implementazione. Personalmente, ho sofferto di alcuni errori di replica quando più nodi eliminano e ri-popolano gli oggetti in un breve lasso di tempo. Non sto necessariamente suggerendo che sia sempre pervasivo, ma il vantaggio di velocità spesso viene fornito con meno garanzie di coerenza (cioè, avrai una consistenza definitiva, ma non vuoi dipendere da esso) .

Se tutto quello che stai facendo è creare una coda, allora non vedo nulla di specifico per NoSQL che li renda la scelta preferita. La velocità / affidabilità / efficienza di esso si ridurrà maggiormente alla configurazione di qualsiasi implementazione che si decide di adottare.