Il nostro sistema ha un modello strutturato (circa 30 diverse entità con diversi tipi di relazioni) interamente conservato in memoria (circa 10 Gb) per motivi di prestazioni. Su questo modello che dobbiamo fare 3 tipi di funzionamento:Si dovrebbe usare Disruptor (LMAX) con un grande modello in memoria e CQRS?
- aggiornamento uno o pochi soggetti
- query per un particolare di dati (questo di solito richiede di leggere migliaia di entità)
- ottenere dati statistici (quanta memoria viene utilizzata, quante query per genere ecc.)
Attualmente l'architettura è piuttosto standard, con un pool di thread per servlet che utilizzano un modello condiviso. All'interno del modello ci sono molte raccolte simultanee, ma ci sono ancora molte attese perché alcune entità sono "più calde" e la maggior parte delle discussioni vuole leggerle/scriverle. Si noti inoltre che le query di solito sono molto più efficienti in termini di CPU e tempo rispetto alle scritture.
Sto studiando la possibilità di passare a un'architettura Disruptor mantenendo il modello in un singolo thread, spostando tutto il possibile (controlli di validità, auditing, ecc.) Dal modello in consumatori separati.
La prima domanda è: ha senso?
Secondo domanda: idealmente le richieste di scrittura dovrebbero avere la precedenza su quelle di lettura. Qual è il modo migliore per avere una priorità nel disgregatore? Stavo pensando ai buffer a 2 anelli e poi provo a leggere da quello più in alto uno più spesso rispetto a quello a bassa priorità.
Per chiarire la domanda è più architettonico rispetto al codice effettivo di LMAX Disruptor.
aggiornamento con maggiori dettagli
dei dati è un dominio complesso, con molte entità (> 100k) di molti tipi diversi (~ 20) collegate tra di loro in una struttura ad albero con molte collezioni differenti.
Le query di solito comportano l'attraversamento di migliaia di entità per trovare i dati corretti. Gli aggiornamenti sono frequenti ma abbastanza limitati come 10 entità alla volta, quindi nell'intero i dati non cambiano molto (come il 20% all'ora).
Ho eseguito alcuni test preliminari e sembra che i vantaggi in termini di velocità di interrogare il modello in parallelo superino i ritardi occasionali dei blocchi di scrittura.
Ciao Uberto - Puoi aggiungere qualche dettaglio. Che tipo di domande stai facendo? E l'aggiornamento delle entità sta avvenendo sulle stesse poche entità o su molte entità diverse? Le entità sono collegate tra loro o per lo più indipendenti e in che modo sono correlate? – jasonk
Riguardo alla domanda 2: precisioni delle letture rispetto alle scritture, LMAX è naturalmente adatto per il sourcing di eventi, che dice che si mantengono gli eventi non quei modelli, i modelli attuali (o più ottimizzati che sono super veloci sulle operazioni di lettura) saranno ancora lì non cambi mai mai ciò che è accaduto quando, se hai un'operazione di lettura prima della scrittura, dovresti elaborarla per ottenerla, in modo da poter riprodurre lo stesso stato se riesegui la catena di eventi ... Quindi in In questo caso, questa priorità è errata qui, lo fai quando due thread scrivono in una raccolta, forse ... – vach