Utilizzo di NoSQL come MQ e per mantenere lo stato

Question

Utilizzo di NoSQL come MQ e per mantenere lo stato

#1 da (2 voti)
#2 da (1 voti)

-1

Attualmente abbiamo un'applicazione che non si adatta bene a causa di più aggiornamenti simultanei a una tabella che viene bloccata. Lo stack tecnologico è ASP.NET e il backend è in SQL Server.

Per evitare l'accesso al database, sto prendendo in considerazione l'utilizzo di NoSQL come coda di messaggi in cui un servizio di produzione assegna attività basate sulla logica di business in code di messaggi diverse in Redis. Qualsiasi raccomandazione sarebbe apprezzata.

Architettura proposta

Un utente esegue l'accesso e il server crea un processo utente che legge il MQ e inizia a lavorare sull'attività. Rende solo due aggiornamenti del database: uno registra l'utente che ha effettuato l'accesso e altri crea una nuova voce nella tabella delle attività. Tutti gli aggiornamenti successivi (alcuni) vengono aggiornati in Redis. Alla fine dell'attività, l'oggetto task con tutti i nuovi dettagli viene trasferito su un'altra coda per la persistenza su RDMBS in cui la tabella delle attività viene aggiornata con tutti gli altri dati.

design sql nosql redis

posta ganeshran 26.04.2017 - 18:22

fonte

2 risposte

Leggi altre domande sui tag design sql nosql redis

Dovremmo usare 'include' nei diagrammi dei casi d'uso per i casi d'uso che appartengono a diversi attori Pseudocodice per un eco che utilizza la ricorsione [chiuso]

score 2 · Answer 1

Non fornisci informazioni sufficienti sul sistema per raccomandare una soluzione.

Tuttavia, l'uso di un (due!) database come una coda è meno buono rispetto all'utilizzo di una coda come coda.

Inoltre, direi che hai bisogno solo di code in cui hai "processi a lungo termine" che vengono attivati più velocemente di quanto possano completare. Non vedo dove nella tua app hai questo?

Mi sembra che dovresti essere in grado di risolvere un problema di blocco della tabella ridisegnando la tabella e SQL un po ', non introducendo un altro DB e un sistema di cache

score 1 · Answer 2

Non sarebbe meglio scrivere semplicemente del codice per consentire all'app di utilizzare più database e cambiare utente tra i database? Con MQ aggiungerai molta logica, e un altro problema con questo approccio è che probabilmente gli utenti non saranno in grado di riavviare le modifiche già avviate fino a quando tutti i dati non saranno salvati nel DB.

Oppure puoi creare una nuova tabella per ogni accesso utente, quindi inviare modifiche alla fine ... in questo modo probabilmente sarai in grado di limitare le scritture della tabella principale e gli utenti non dovranno attendere fino a quando la coda non sarà vuota prima di caricare il lavoro già salvato, ecc.