È possibile copiare i contenuti di un database nella memoria di un programma, se più query richiedono tempo?

"Is it viable to copy contents ... into a program's memory"

"vitale"? Certo, la tecnica si chiama cache e sono sicuro che ne hai sentito parlare. Tuttavia, dovresti investire alcuni pensieri in cose come

• è la memoria disponibile per intero, nell'ambiente di produzione, in esclusiva per il tuo programma?

• cosa succederà quando le dimensioni della tabella cresceranno, come hai detto? Ad esempio, puoi dividere efficacemente i dati in porzioni che possono essere elaborate in memoria contemporaneamente?

Sarà più veloce di altri approcci? Non c'è altro buon modo se non provare questo e misurare, dipende da un mucchio di cose che non conosciamo, e forse alcune cose anche se non lo sai ancora. Si consiglia di iniziare con un set di dati più piccolo ed estrapolare.

Tuttavia, l'invio di 1,2 miliardi di query singole non sembra troppo promettente e, come regola generale, fare cose "in memoria" è in genere molto più veloce di fare "cose equivalenti" su un supporto di archiviazione esterno, con un gestione del database in mezzo. A seconda del tipo di query, puoi provare a utilizzare le funzionalità di indicizzazione del tuo database, che potrebbero migliorare le cose da quella parte. D'altra parte, se l'indicizzazione è possibile nel database, anche l'uso di hash / dizionari potrebbe essere possibile in memoria.

Dopo aver letto il tuo commento, la memorizzazione dei risultati mi sembra un candidato per un collo di bottiglia. Anche se puoi interrogare i dati completi di queste cinque tabelle AE in meno di un secondo, esegui l'elaborazione principale completamente in memoria, e risulta essere più veloce di qualsiasi altro approccio ti venga in mente, devi finalmente creare questi 240 milioni di file, che richiederà del tempo. Cose da considerare qui:

• quando fai cose "in memoria", vuol dire che dovrai inviare i dati su una rete (potenzialmente lenta) al server del database? O usi qualcosa come un database locale, dove il programma + db si trova sulla stessa macchina?

• il traffico di rete presunto diventa un problema: che ne è dell'utilizzo di stored procedure per ridurre il traffico di rete? Che ne dici di usare un enorme JOIN sui tavoli A, B, C, D, E con qualche funzione aggregata? Hai provato quanto bene funziona?

• quando si esegue l'elaborazione non in memoria, significa che sono necessarie 240 milioni di operazioni INSERT, seguite da 240 milioni * di operazioni UPDATE? Potrebbe rallentare.

• o la preelaborazione in memoria ti consentirà di trovare prima i risultati e poi di trasferirli "tutto-in-una volta" al database utilizzando una sorta di meccanismo di inserimento in blocco?

Tuttavia alla fine, in memoria o meno, si riduce al database specifico disponibile, alla rete, all'hardware, a molti dettagli dell'attività e all'implementazione scelta, nulla che possa essere valutato qui senza sapere la "cosa reale".

For every combination of AB, ABC and ABCD, I'm required to check all rows of E to see if there is some information relevant to the combination, and store a count of the relevant info. The count will be eventually written into an SQL table.

In realtà, questo suona (per me) più come un lavoro per il database da fare, senza riportare nulla nell'applicazione client!

Sei "ogni riga combinata con l'altro" è un Join Cartesiano (o Cross-Product) e generalmente dovrebbe essere evitato a causa dell'enorme [enorme] numero di tuple che può generare ma, in questo caso, dici esplicitamente che è quello che vuoi, quindi dai al tuo database molti (e molti) lotti di memoria e spazio di swap (e una nuova tazza di tè bollente) e lascialo andare.