Best practice per la registrazione di dati in tempo reale in un DB NoSQL

Question

Ho un'applicazione Java che riceve alcuni eventi in tempo reale e li spinge al livello dell'interfaccia utente. Voglio registrare tutti gli eventi percepiti e dal momento che il volume delle informazioni sarà enorme, preferisco usare un db NoSQL.

Ho installato un mongodb per questo scopo che inserisce un documento per evento. Il problema è che questo approccio (un accesso al disco per evento) rallenta notevolmente l'intero processo.

Quindi, quale approccio posso adottare in questa situazione? quali opzioni sono disponibili in mongodb per questo (ad esempio l'inserimento di massa, l'inserimento asincrono, il caching, ...)? passare ad un'altra implementazione di db NoSQL può fare la differenza? quali sono le migliori pratiche qui?

Answer 1

Ho atteso un po 'di tempo per vedere altre risposte, ma ho perso la pazienza. Ho usato MongoDB come archivio di log per 3 progetti (due per Java e uno per C#). Sulla base di questo posso capire seguendo le regole importanti per organizzare la registrazione:

1. Non utilizzare indici. Se si scrive principalmente, gli indici causano un peggioramento delle prestazioni. Se hai bisogno di analisi dei log post-processo, copia le informazioni in un altro database o raccolta. Sfortunatamente non è possibile eliminare la chiave primaria _id - lasciarla come è (GUID) o sostituirla con l'incremento automatico NumberLong.

2. Limite di scrittura. MongoDB ha molte opzioni per controllare la consapevolezza delle operazioni di scrittura. È possibile impostare la corrispondenza tra LogLevel e regole di scrittura. Ad esempio DEBUG, INFO, WARN possono andare con WriteConcern.UNACKNOWLEDGED e ERROR, FATAL possono essere memorizzati con WriteConcern.ACKNOWLEDGED. In tal modo si migliora la prestazione dell'applicazione evitando la pausa durante la scrittura di messaggi con priorità bassa. Allo stesso tempo, sei sicuro che i messaggi importanti (che raramente) vengono archiviati.

3. Cache l'istanza di raccolta. Voglio dire evitare di risolvere gli oggetti di Mongo su getDB o getCollection ogni volta che arriva il messaggio.

4. Minima quantità di dati trasmessi dalla rete. Limita il tuo messaggio con un set minimo di campi. Tronca traccia di stack troppo lunga. Guarda come 3.x Primavera accorcia nome completo della classe s.w.s.m.m.a.RequestMappingHandlerMapping invece di some.whatever.sub.main.minimal.agent.RequestMappingHandlerMapping