design per il buffering o l'accodamento dei flussi di dati per sostituire il database

0

Abbiamo un sistema (ms stack, .net, sql) che riceve dati da migliaia di dispositivi remoti (diverse letture indipendenti / min). Attualmente salviamo tutti i dati in un db che arriva e un secondo servizio legge ed elabora i dati, utilizzando il database per "bufferizzare" l'input.

Vogliamo che il secondo processo sia scalabile in quanto potrebbe richiedere un po 'di tempo per essere completato. Idealmente dovremmo essere in grado di eseguire più istanze del secondo processo, ma dobbiamo assicurarci che i dati siano elaborati in un ordine specifico (non è possibile avere due processi che lavorano su dati dallo stesso dispositivo remoto nello stesso momento). Abbiamo utilizzato il database per gestirlo leggendo tutti i dati da un dispositivo alla volta e impedendo ad altri processi di leggere i dati da quel dispositivo fino al suo completamento.

Si sta affermando di mostrare problemi di prestazioni e ha un elevato traffico di db, quindi stiamo cercando architetture alternative per usare il DB come buffer.

I sistemi di memorizzazione nella cache degli oggetti come memcache consentono di recuperare tutti i dati per 1 dispositivo in un unico processo e impedire che i dati vengano utilizzati da un altro processo?

O ci sono sistemi di accodamento dei messaggi che farebbero questo?

O qualcos'altro?

-Edit -

La lettura dei dati da elaborare deve essere eseguita da macchine su server diversi, quindi cerco qualcosa che possa attraversare i confini di applicazioni / processi e mantenere blocchi su alcuni elementi di dati per preservare l'ordine in cui vengono elaborati

    
posta Matt 02.10.2014 - 12:04
fonte

1 risposta

2

Il problema con "un database" è che generalmente è un singolo punto di errore / scalabilità. Puoi scalare i database, ma è difficile e costoso a seconda della scala di cui stai parlando.

In genere, ciò che descrivi sono implementati come messaggi. Le code di messaggi quindi memorizzerebbero e inoltreranno i messaggi a più lettori o client. È possibile ridimensionare il numero di lettori (oltre al numero di code e comunicazioni tra le code) che è generalmente considerato un'architettura molto scalabile.

Ho lavorato con RabbitMQ per fare esattamente questo tipo di cose; ma ci sono molti venditori con varie funzionalità.

    
risposta data 03.10.2014 - 01:20
fonte

Leggi altre domande sui tag