Metodi efficienti per la memorizzazione di decine di milioni di oggetti per l'interrogazione, con un numero elevato di inserti al secondo?

Invece di avere un dizionario e cercare quel dizionario per voci troppo vecchie; avere 10 dizionari. Ogni 30 secondi circa crea un nuovo dizionario "attuale" e scarta il dizionario più vecchio senza alcuna ricerca.

Successivamente, quando scarti il dizionario più vecchio, metti tutti i vecchi oggetti su una coda FILO per dopo, e invece di usare "nuovo" per creare nuovi oggetti estrai un vecchio oggetto dalla coda FILO e usa un metodo per ricostruire il vecchio oggetto (a meno che la coda dei vecchi oggetti non sia vuota). Questo può evitare un sacco di allocazioni e un sacco di spese generali per la raccolta dei dati inutili.

Il primo pensiero che ti viene in mente è perché aspetti 5 minuti. Potresti fare gli snapshot più spesso e quindi ridurre il grande sovraccarico che vedi al limite dei 5 minuti?

In secondo luogo, LINQ è ottimo per il codice conciso, ma in realtà LINQ è zucchero sintattico su C "normale" e non vi è alcuna garanzia che genererà il codice più ottimale. Come esercizio puoi provare a riscrivere i punti caldi senza LINQ, potresti non migliorare le prestazioni ma avrai un'idea più chiara di ciò che stai facendo e renderà più semplice il lavoro di profilazione.

Un'altra cosa da considerare sono le strutture dati. Non so cosa fai con i tuoi dati, ma potresti semplificare i dati che archivi in qualche modo? Potresti usare una stringa o una matrice di byte e quindi estrarre le parti pertinenti da quegli elementi quando ne hai bisogno? Potresti usare una struct al posto di una classe e persino fare qualcosa di male con stackalloc per mettere da parte la memoria ed evitare le esecuzioni di GC?

Approccio semplice: prova memcached .

• È ottimizzato per eseguire attività come questa.
• Può riutilizzare la memoria di riserva su caselle meno trafficate, non solo sulla casella dedicata.
• Ha un meccanismo di scadenza della cache integrato, che è pigro, quindi non c'è intoppi.

Lo svantaggio è che è basato sulla memoria e non ha alcuna persistenza. Se un'istanza è inattiva, i dati sono spariti. Se hai bisogno di persistenza, serializza i dati da solo.

Approccio più complesso: prova Redis .

• È ottimizzato per eseguire attività come questa.
• Ha un meccanismo di scadenza della cache incorporato
.
• Scala / divide facilmente.
• Ha persistenza.

Il lato negativo è che è leggermente più complesso.

Non è necessario memorizzare tutti i pacchetti per le query che hai menzionato. Ad esempio - contatore del tipo di pacchetto:

Hai bisogno di due array:

int[] packageCounters = new int[NumberOfTotalTypes];
int[,] counterDifferencePerMinute = new int[6, NumberOfTotalTypes];

Il primo array tiene traccia del numero di pacchetti in diversi tipi. Il secondo array tiene traccia di quanti più pacchetti sono stati aggiunti ogni minuto in modo tale da sapere quanti pacchetti devono essere rimossi ad ogni intervallo di minuti. Spero che tu possa dire che il secondo array è usato come coda FIFO rotonda.

Quindi per ogni pacchetto, vengono eseguite le seguenti operazioni:

packageCounters[packageType] += 1;
counterDifferencePerMinute[current, packageType] += 1;
if (oneMinutePassed) {
  current = (current + 1) % 6;
  for (int i = 0; i < NumberOfTotalTypes; i++) {
    packageCounters[i] -= counterDifferencePerMinute[current, i];
    counterDifferencePerMinute[current, i] = 0;
}

In qualsiasi momento, i contatori dei pacchetti possono essere recuperati dall'indice all'istante e non memorizzare tutti i pacchetti.

(So che questa è una vecchia domanda, ma l'ho incontrata mentre cercavo una soluzione a un problema simile in cui il pass di raccolta della seconda generazione stava sospendendo l'app per diversi secondi, quindi la registrazione per altre persone in situazioni simili) .

Usa una struct piuttosto che una classe per i tuoi dati (ma ricorda che viene trattata come un valore con semantica pass-by-copy). Questo elimina un livello di ricerca nel gc che deve fare ogni passaggio del segno.

Usa gli array (se conosci la dimensione dei dati che stai memorizzando) o List - che usa gli array internamente. Se hai veramente bisogno dell'accesso casuale veloce, usa un dizionario di indici di array. Questo elimina un altro paio di livelli (o una dozzina o più se usi un SortedDictionary) affinché il gc debba cercare.

A seconda di ciò che si sta facendo, la ricerca in un elenco di strutture potrebbe essere più veloce della ricerca del dizionario (a causa della localizzazione della memoria) - profilo per la propria applicazione specifica.

La combinazione di struct & list riduce sia l'utilizzo della memoria sia le dimensioni dello sweep del garbage collector in modo significativo.