2014-12-10 26 views
13

Attualmente sto affrontando un problema di grattacapo, sto lavorando con un set di dati di grandi dimensioni (quando dico grande, intendo miliardi di righe di dati) e sono preso tra velocità e scalabilità.C# - Memoria di grandi dimensioni

È possibile memorizzare i miliardi di righe di dati nel database, ma la mia applicazione deve controllare costantemente se una nuova riga di dati esiste nel set di dati, in caso contrario, inserirla, altrimenti recuperarla.

Se dovessi utilizzare una soluzione di database, valuto ogni chiamata al database per recuperare una riga di dati da 10 ms (stima ottimistica), ho bisogno di recuperare circa 800k record per ogni file che elaboro nella mia applicazione , che significa (10ms x 800k = 2.22 hours) per file da elaborare. Tale intervallo è troppo lungo per analizzare ed elaborare 1 file, considerando che la quantità di tempo necessaria per recuperare una riga di dati dal database aumenterà quando il database crescerà a miliardi e miliardi di righe.

ho pensato anche di memorizzare un List o HashSet nella memoria locale per confrontare e recuperare, ma non è andare a lavorare fuori come non sarò in grado di memorizzare miliardi di record (oggetti) in memoria.

Pls un consiglio su cosa dovrei fare per la mia situazione.

Edit: Oh ya, ho dimenticato di dire che ho già implementato un semi-cache, una volta che un record viene recuperato, verrà memorizzato nella cache nella memoria, quindi se lo stesso record ha bisogno di essere recuperato ancora una volta, sarà essere recuperato dalla memoria, invece, ma mi trovo ad affrontare lo stesso problema, raggiungerò un punto nel tempo in cui la memoria non può più contenere altri dati memorizzati nella cache.

+0

Esiste un modo per determinare in modo ragionevole quali righe saranno probabilmente necessarie per il recupero, ad es. più recente, cioè implementare una capacità di memorizzazione nella cache parziale? – StuartLC

+0

Oh ya, ho dimenticato di dire che ho già implementato una semi-cache, una volta che un record è stato recuperato, sarà memorizzato nella cache, quindi se lo stesso record deve essere recuperato nuovamente, verrà recuperato dalla memoria invece, ma devo affrontare lo stesso problema, raggiungerò un punto nel tempo in cui la memoria non può più contenere altri dati memorizzati nella cache. – Dan

+4

Usando un HASH per confrontare ogni file che si crea, associare i file con il codice hash, quindi è necessario confrontare HASH non FILE? –

risposta

2

Idealmente se si sta giocando con un gran numero di dati, è necessario assicurarsi di non esaurire le risorse durante l'elaborazione dei dati. Tuttavia, devi solo trovare un modo ragionevole per aumentare l'utilizzo delle tue risorse.

Vorrei assolutamente andare con il database perché è il modo più conosciuto per interrogare e archiviare i dati nel modo più ottimale. Non hai menzionato che cosa fa esattamente la tua applicazione, quindi posso solo darti delle opinioni generali su come farei in tale scenario;

  1. Se la dimensione dei dati del database è davvero grande come dici tu in miliardi e se si dati da leggere per scopi analitici o di reporting è meglio trovare una tecnica di data mining come cubetti ecc Questo potrebbe aiutare a strutturare i dati in un modo per ridurre il tempo di interrogazione.
  2. Se sopra non è un'opzione, trovare un modo per partizionare i dati in orizzontale o in verticale, beh, dipende anche da come si recuperano effettivamente i dati e come si possono realmente raggrupparli.
  3. Trova un modo per interrogare un gruppo di righe (ad esempio, dove pk in (1,2,3,4, ..., 100), invece di interrogare ogni riga alla volta come accennato in precedenza, il raggruppamento può aumentare la risposta alla query in modo esponenziale
  4. È meglio trovare una chiave primaria all'interno dei dati stessi in modo che i dati vengano ordinati in ordine della chiave primaria fisicamente e conoscerai la tua chiave primaria prima ancora di inserirla. chiave quindi meglio mettere indici ragione-in grado di aumentare il tempo di risposta alle query.
  5. mantenere la connessione database aperto per tutta la vita della vostra applicazione e ricollegare solo in caso di caduta. e utilizzare pool di connessioni se si prevede più connessioni al database.
Problemi correlati