Ok, quindi questo è un po 'lontano dalle altre risposte, ma ... mi sembra che se hai i dati in un file system (uno stock per file, forse) con una dimensione di record fissa, puoi ottenere i dati veramente facilmente: data una query per un particolare stock e intervallo di tempo, puoi cercare nel posto giusto, recuperare tutti i dati di cui hai bisogno (saprai esattamente quanti byte), trasformare i dati nel formato di cui hai bisogno (che potrebbe essere molto veloce a seconda del formato di archiviazione) e sei via.
Non so nulla dell'archiviazione Amazon, ma se non hai nulla come l'accesso diretto ai file, potresti fondamentalmente avere BLOB: dovresti bilanciare BLOB di grandi dimensioni (meno record, ma probabilmente leggendo più dati di quanti ne hai bisogno ciascuno time) con piccoli blob (più record che danno più overhead e probabilmente più richieste per ottenerli, ma ogni volta vengono restituiti meno dati inutili).
Successivamente aggiungi il caching - suggerirei di dare a diversi server diversi stock da gestire, ad esempio - e puoi praticamente servire solo dalla memoria. Se puoi permetterti abbastanza memoria su abbastanza server, ignora la parte "carica su richiesta" e carica tutti i file all'avvio. Ciò semplificherebbe le cose, a costo di un avvio più lento (che ovviamente influisce sul failover, a meno che non ci si possa permettere di avere sempre due server per un particolare stock, il che sarebbe utile).
Nota che non è necessario memorizzare il simbolo di borsa, la data o il minuto per ogni record, perché sono impliciti nel file che stai caricando e nella posizione all'interno del file. Dovresti anche considerare di quale precisione hai bisogno per ciascun valore e come archiviarlo in modo efficiente: hai fornito 6SF nella tua domanda, che potresti memorizzare in 20 bit. Memorizza potenzialmente tre interi a 20 bit in 64 bit di memoria: leggilo come long(o qualunque sia il tuo valore intero a 64 bit) e usa mascheramento / spostamento per riportarlo a tre numeri interi. Avrai bisogno di sapere quale scala usare, ovviamente, che potresti probabilmente codificare nei 4 bit di riserva, se non riesci a renderla costante.
Non hai detto come sono le altre tre colonne di numeri interi, ma se riuscissi a farla franca anche con 64 bit per quelle tre, potresti memorizzare un intero record in 16 byte. Sono solo ~ 110 GB per l'intero database, il che non è molto ...
EDIT: L'altra cosa da considerare è che presumibilmente le azioni non cambiano durante il fine settimana, o addirittura dall'oggi al domani. Se il mercato azionario è aperto solo 8 ore al giorno, 5 giorni alla settimana, hai bisogno solo di 40 valori a settimana invece di 168. A quel punto potresti finire con solo circa 28 GB di dati nei tuoi file ... il che suona molto più piccolo di quanto probabilmente stavi pensando in origine. Avere così tanti dati in memoria è molto ragionevole.
EDIT: Penso di aver perso la spiegazione del motivo per cui questo approccio si adatta bene qui: hai un aspetto molto prevedibile per gran parte dei tuoi dati: il ticker di borsa, la data e l'ora. Esprimendo il ticker una volta (come nome del file) e lasciando la data / ora interamente implicita nella posizione dei dati, stai rimuovendo un sacco di lavoro. È un po 'come la differenza tra a String[]e a Map<Integer, String>: sapere che l'indice dell'array inizia sempre da 0 e sale con incrementi di 1 fino alla lunghezza dell'array consente un accesso rapido e un'archiviazione più efficiente.
