Bien, esto está algo alejado de las otras respuestas, pero ... me parece que si tiene los datos en un sistema de archivos (un stock por archivo, tal vez) con un tamaño de registro fijo, puede obtener los datos De Verdad fácil: dada una consulta para un stock y un rango de tiempo en particular, puede buscar el lugar correcto, obtener todos los datos que necesita (sabrá exactamente cuántos bytes), transformar los datos en el formato que necesita (que podría sea muy rápido dependiendo de su formato de almacenamiento) y ya no está.
No sé nada sobre el almacenamiento de Amazon, pero si no tiene nada como acceso directo a archivos, básicamente podría tener blobs; necesitaría equilibrar blobs grandes (menos registros, pero probablemente leyendo más datos de los que necesita cada uno time) con pequeñas manchas (más registros dan más sobrecarga y probablemente más solicitudes para acceder a ellos, pero cada vez se devuelven menos datos inútiles).
A continuación, agregue el almacenamiento en caché (le sugiero que, por ejemplo, asigne diferentes valores a diferentes servidores para manejar), y puede prácticamente servir desde la memoria. Si puede permitirse suficiente memoria en suficientes servidores, omita la parte de "carga a pedido" y simplemente cargue todos los archivos al inicio. Eso simplificaría las cosas, a costa de una puesta en marcha más lenta (lo que obviamente afecta la conmutación por error, a menos que pueda permitirse tener siempre dos servidores para cualquier stock en particular, lo que sería útil).
Tenga en cuenta que no necesita almacenar el símbolo de cotización, la fecha o el minuto de cada registro, porque están implícitos en el archivo que está cargando y la posición dentro del archivo. También debe considerar qué precisión necesita para cada valor y cómo almacenar eso de manera eficiente: ha dado 6SF en su pregunta, que podría almacenar en 20 bits. Potencialmente almacene tres enteros de 20 bits en 64 bits de almacenamiento: léalo como un long(o cualquiera que sea su valor entero de 64 bits) y use enmascaramiento / desplazamiento para volverlo a tres enteros. Necesitará saber qué escala usar, por supuesto, que probablemente podría codificar en los 4 bits de repuesto, si no puede hacerlo constante.
No ha dicho cómo son las otras tres columnas enteras, pero si pudiera salirse con 64 bits para esas tres también, podría almacenar un registro completo en 16 bytes. Eso es solo ~ 110GB para toda la base de datos, que en realidad no es mucho ...
EDITAR: La otra cosa a considerar es que presumiblemente las acciones no cambian durante el fin de semana, o de hecho durante la noche. Si el mercado de valores solo está abierto 8 horas al día, 5 días a la semana, entonces solo necesita 40 valores por semana en lugar de 168. En ese momento, podría terminar con solo alrededor de 28 GB de datos en sus archivos ... lo que suena mucho más pequeño de lo que probablemente pensabas originalmente. Tener tantos datos en la memoria es muy razonable.
EDITAR: Creo que me he perdido la explicación de por qué este enfoque encaja bien aquí: tiene un aspecto muy predecible para una gran parte de sus datos: el indicador de cotización, la fecha y la hora. Al expresar el ticker una vez (como nombre de archivo) y dejar la fecha / hora totalmente implícita en la posición de los datos, está eliminando un montón de trabajo. Es un poco como la diferencia entre una String[]y una Map<Integer, String>- a sabiendas de que su índice de la matriz siempre empieza en 0 y sube en incrementos de 1 hasta la longitud de la matriz permite un acceso rápido y un almacenamiento más eficiente.
