Хорошо, так что это несколько отличается от других ответов, но ... мне кажется, что если у вас есть данные в файловой системе (возможно, один запас на файл) с фиксированным размером записи, вы можете получить данные действительно легко: при запросе определенного запаса и временного диапазона вы можете найти нужное место, получить все необходимые данные (вы точно знаете, сколько байтов), преобразовать данные в нужный вам формат (который может будьте очень быстры в зависимости от вашего формата хранения), и вы далеко.
Я ничего не знаю о хранилище Amazon, но если у вас нет ничего похожего на прямой доступ к файлам, у вас могут быть большие двоичные объекты - вам нужно будет сбалансировать большие двоичные объекты (меньше записей, но, вероятно, читать больше данных, чем вам нужно каждый time) с небольшими каплями (большее количество записей дает больше накладных расходов и, вероятно, больше запросов для их получения, но каждый раз возвращается меньше бесполезных данных).
Затем вы добавляете кэширование - например, я предлагаю предоставить разным серверам разные запасы для обработки - и вы можете в значительной степени просто обслуживать из памяти. Если вы можете позволить себе достаточно памяти на достаточном количестве серверов, пропустите часть «загрузка по запросу» и просто загрузите все файлы при запуске. Это упростило бы задачу за счет более медленного запуска (что, очевидно, влияет на отработку отказа, если только вы не можете позволить себе всегда иметь два сервера для любого конкретного запаса, что было бы полезно).
Обратите внимание, что вам не нужно хранить биржевой символ, дату или минуту для каждой записи, потому что они неявны в загружаемом файле и позиции в файле. Вы также должны подумать, какая точность вам нужна для каждого значения и как ее эффективно хранить - вы указали 6SF в своем вопросе, который вы можете сохранить в 20 битах. Потенциально храните три 20-битных целых числа в 64-битном хранилище: прочтите его как long(или любое другое 64-битное целочисленное значение) и используйте маскировку / сдвиг, чтобы вернуть его к трем целым числам. Конечно, вам нужно знать, какой масштаб использовать - который вы, вероятно, могли бы закодировать в 4 запасных бита, если не можете сделать его постоянным.
Вы не сказали, на что похожи другие три целочисленных столбца, но если бы вы могли обойтись и для этих трех 64 бита, вы могли бы сохранить всю запись в 16 байтах. Это всего лишь ~ 110 ГБ для всей базы данных, что на самом деле не очень много ...
РЕДАКТИРОВАТЬ: Еще одна вещь, которую следует учитывать, заключается в том, что, по-видимому, акции не меняются за выходные - или, действительно, за ночь. Если фондовый рынок открыт только 8 часов в день, 5 дней в неделю, тогда вам нужно всего 40 значений в неделю вместо 168. На этом этапе вы можете получить только около 28 ГБ данных в ваших файлах ... намного меньше, чем вы, вероятно, думали изначально. Наличие такого количества данных в памяти очень разумно.
РЕДАКТИРОВАТЬ: Я думаю, что пропустил объяснение того, почему этот подход подходит здесь: у вас есть очень предсказуемый аспект для большой части ваших данных - биржевой тикер, дата и время. Выражая тикер один раз (как имя файла) и оставляя дату / время полностью неявными в позиции данных, вы удаляете целую кучу работы. Это немного похоже на разницу между a String[]и a Map<Integer, String>- знание того, что ваш индекс массива всегда начинается с 0 и увеличивается с шагом 1 до длины массива, обеспечивает быстрый доступ и более эффективное хранение.
