Quanto è significativa la differenza di prestazioni tra l'archiviazione in memoria e quella nel database [chiuso]

Question

Chiuso.Questa domanda deve essere più approfondita focalizzata.Al momento non accetta risposte.

---

Vuoi migliorare questa domanda? Aggiorna la domanda in modo che si concentri su un solo problema modificando questo post.

Chiuso 5 anni fa.

Sto creando un'applicazione di chat in Signalr.Attualmente ha alcune funzionalità con l'archiviazione in un database per l'archiviazione permanente dei messaggi.Voglio implementare elenchi di utenti e ho riletto questo articolo:

http://www.asp.net/signalr/overview/signalr-20/hubs-api/mapping-users-to-connections#inmemory

Quanto è significativa questa differenza tra l'archiviazione in memoria?È probabile che ci sia più di un secondo di differenza tra, ad esempio, 1000 utenti e 10.000 utenti che si scambiano messaggi a una velocità normale di, diciamo, 1 msg al secondo (hanno avuto molto zucchero)?E quanto è utile?Qualsiasi riferimento a test precedenti sulle prestazioni sarebbe estremamente apprezzato.

In secondo luogo, potrei farlo nel modo sbagliato, ma se voglio memorizzare un elenco di utenti e ci sono più chat room, presumo che avrò bisogno di un dizionario separato per stanza?E se è così, è fattibile poiché voglio che anche gli utenti siano in grado di generare le proprie stanze.Semplicemente non vedo come sia possibile ottenere in-memory in questo modo.

Grazie

Answer 1

Odio fornire un unico collegamento per una risposta, ma questa chat room OSS è perfettamente funzionante https://jabbr.net affronta tutto ciò di cui sei preoccupato.

Fonte: https://github.com/jabbr/jabbr

Per commentare la tua preoccupazione principale in memoria rispetto a db:DB aggiunge la possibilità di rendere persistenti i dati o addirittura di ridimensionare l'applicazione MA è MOLTO meno performante rispetto a quello in memoria.Ora non fraintendermi, anche se è MOLTO meno performante non significa che ci vorranno pochi secondi per inviare messaggi a seconda della tua app...È tutta una questione di compromessi.

Per quanto riguarda l'applicazione di un'architettura orientata al DB a 1000 o 10.000 utenti, tutto dipende da come la implementi.Ad esempio, il provider di scalabilità orizzontale REDIS esegue tutto in memoria ma poi persiste sul disco a intervalli.Questo è ovviamente estremamente veloce ma consente una "parte" della perdita di dati.

Answer 2

Questo non è direttamente correlato alla tua domanda originale.

Penso che non sia possibile salvarli nella memoria in-memory. Il problema è che se il pool di applicazioni viene riciclato, tutti i messaggi archiviati in memoria scompariranno.

Non è possibile prevedere quando il pool di app verrà riciclato (nel complesso è possibile impostare manualmente un orario specifico per il riciclo).Può succedere in pochi giorni o poche ore.

Idealmente, si desidera archiviare in una posizione persistente come Banca dati.Se sei preoccupato delle prestazioni del salvataggio nel database, puoi farlo asincrono l'attività di salvataggio del database.

Answer 3

Dai un'occhiata a questo confronto:

http://ruturaj.net/redis-memcached-tokyo-tyrant-and-mysql-comparision/

Redis (in memoria) supera MySQL (classico DB) Ovviamente, i loro campi di applicazione sono fortemente diversi, quindi non possiamo dire che, in generale, Redis sia migliore di MySQL.Ogni progetto software è un mondo a sé e si possono applicare molte soluzioni diverse.In alcune situazioni, Redis e MySQL vengono utilizzati insieme per diverse parti di una piattaforma (ad es.eCommerce Magento)

Sta a te valutare se hai bisogno di una soluzione in-memory o di un database standard.Penso che un throughput di 1 inserto/secondo possa essere ottenuto facilmente tramite MySQL, ma questa è solo un'opinione.Ti suggerisco di scrivere un'implementazione del tuo prodotto che sia "Redis aware":inizia a usare MySQL, ma usalo attraverso un livello di astrazione che si adatta sia a MySQL che a Redis (non so se tale livello sia disponibile open source, ma puoi rilasciarne uno tuo...)