Applicazione intensiva computazionale: caricamento e interrogazione del database

Is our architecture hurting us?

No.

Are there any papers/work/test on the subject-- tradeoffs between database reading as-you-go and a database copy in memory?

Sì. Centinaia.

Questo è il motivo per cui i database nascondono le cose. Più il database è in memoria più velocemente funziona il database.

Tutti gli algoritmi di caching intelligente (LRU, ecc.) sono progettati per ottenere prestazioni piuttosto buone con un uso abbastanza buono della memoria. Per un prodotto di database generico, questo può comportare alcuni compromessi interessanti.

Per la tua applicazione, tuttavia, mettere tutto in memoria è chiaramente ottimale. Non c'è compromesso. Hai già raggiunto il limite massimo del rendimento.

Any comments or insight would be appreciated.

Sostituire la tua memoria all-in con qualsiasi altra cosa può comportare più I / O e quindi essere più lento.

Ci sono alcune cose che puoi fare se vuoi accelerare le cose.

1. Non caricare file in un database e quindi eseguire query sul database per creare la struttura in memoria. Basta caricare i file in memoria. Molto più veloce.

2. Se possibile, interrompi l'elaborazione per creare una pipeline a livello di sistema operativo in cui vengono letti i risultati parziali da stdin e i risultati vengono scritti su stdout. Una serie di stadi della pipeline userà più core e più memoria, spesso portando a un miglioramento del throughput.

Un database in memoria ha il potenziale per essere più veloce di uno su un disco rigido. Ci sono anche opzioni per fare una miscela.

Indipendentemente da ciò, ci sono molti altri fattori che potrebbero eliminare l'opzione del disco rigido. Suggerirei di lasciare che il capo architetto si occupasse dell'architettura (sarà duro se cerchi di fare il suo lavoro). Invece, concentrati sulla limitazione delle dimensioni e sul piano aziendale. Portagli il problema (devi simulare set di dati più grandi di 1 GB) e fagli capire una soluzione.

Non sono un esperto in questa particolare area, ma non riesco a vedere nulla che batte l'approccio "in memoria". Sì, hai il lento avvio del caricamento di tutti quei dati, ma una volta lì il tuo tempo di recupero dei dati è fondamentalmente 0. Se stai eseguendo il database su qualcosa di diverso dalla stessa macchina della simulazione, introduci la latenza di rete nell'equazione.

Senza una vera comprensione dei dati e di ciò che si sta simulando e in che modo, questo suggerimento può o non può valerne la pena. È possibile caricare grandi blocchi di dati alla volta, ad esempio caricare 100 MB / X righe di dati, avviare l'elaborazione e quindi avere i successivi 100 MB pronti per essere elaborati entro la fine del primo lotto.

Il problema è che è necessario lavorare con set di dati superiori a 1 GB. Per fare questo, dovrai suddividere i dati in blocchi più piccoli e più gestibili. Quindi il tuo problema principale sarà se gli algoritmi possono lavorare su dati parziali o no.

Se richiedono che tutti i dati vengano letti in memoria, sarà necessario eseguire una grande riscrittura dell'applicazione per modificarlo. Dovrai essere in grado di leggere un sottoinsieme del processo di dati che poi ripetere finché tutti i dati non vengono elaborati. Una volta elaborata ogni parte, dovrai combinare i risultati.

Non è così semplice come cambiare il modo in cui leggi i dati dal database.