Come implementare le code persistenti ricercabili?

Question

Come implementare le code persistenti ricercabili?

#1 da (2 voti)

1

Implementeremo un sistema che riceverà un sacco di richieste attraverso l'interfaccia del servizio web. Dovremo accodare le richieste ed elaborarle in modo asincrono. Di conseguenza dovremo avere anche qualche coda di output con le risposte (QR). Il client del servizio web avrà la possibilità di interrogare le sue (e solo le sue) richieste elaborate in QR utilizzando un altro metodo di servizio web. Inoltre, il cliente avrà la possibilità di trovare la risposta esatta dal QR fornendo l'id della richiesta (restituita dopo aver inviato la richiesta). Inoltre, il cliente sarà abel cancellare la richiesta dal QR. Ci saranno 60 richieste al secondo.

La domanda è come implementare il QR. Abbiamo bisogno di affidabilità e durata (nulla è permesso di essere perso).

Ora la domanda su come questo può essere implementato .... Ci sono diverse opzioni, che mi vengono in mente:

Uso di RDBMS - ma questo è tutt'altro che ideale in quanto le prestazioni non sarebbero ideali
impiegano qualcosa come Redis o memcached - con una coda in entrata in redis e per ogni elenco di client con elementi elaborati (risposte), ma sono scettico sull'affidabilità e la durabilità. Non possiamo permetterci di perdere nessuna delle richieste o risposte.
Qualche altra soluzione noSQL?

database architecture nosql web-services redis

posta Ondrej Peterka 06.06.2016 - 17:05

fonte

1 risposta

Leggi altre domande sui tag database architecture nosql web-services redis

Licenza per le funzioni di visualizzazione intestazione in una clausola con licenza BSD 3 Come funziona esattamente l'integrazione USB dal microcontrollore?

score 2 · Answer 1

Penso che tu stia pensando troppo a qualcosa. È possibile utilizzare un RDBMS basato su SQL tradizionale. Potrebbe essere o non essere abbastanza veloce (anche se sospetto che ti preoccupi prematuramente dell'ottimizzazione), ma l'unico modo per dirlo è provarlo .

Assicurati di scrivere il codice che interagisce con il sistema di archiviazione in modo astratto, in modo tale che è semplice cambiare in un altro metodo di archiviazione in un secondo momento se il tuo RDBMS risulta non buono sufficiente.

Per inciso, non vedo nulla nella descrizione del problema che sia adatto per un database NoSQL di qualsiasi tipo. Non hai dati non persistenti o facilmente riproducibili (quindi non è appropriato per un database basato sulla memoria). Avete bisogno di forti garanzie di coerenza (quindi non è appropriato per i vari sistemi che consentono la conformità ACID per ottenere un incremento delle prestazioni). I tuoi dati sembrano strutturati in modo relativamente semplice (quindi non avrai problemi di "mancata corrispondenza impedenza" tra oggetto / relazione che potrebbero spingerti verso un archivio di documenti o un database di oggetti). Non sembra che la relazione tra gli articoli sia più importante degli oggetti stessi (quindi è improbabile che un database di grafici sia la scelta migliore). Sembra che tu abbia scelto NoSQL perché NoSQL ha la reputazione di essere più scalabile degli RDBMS - questo è un po 'vero, ma solo per le applicazioni in cui è naturale . Valutare se l'applicazione utilizza una delle caratteristiche specifiche di una soluzione NoSQL prima di assumere che creerà un aumento delle prestazioni.