Архитектура и шаблон для крупномасштабных, временных рядов, операция агрегации

Question

Я постараюсь описать мой вызов и работу: Мне нужно рассчитать индексы цен акций за исторический период. Например, я возьму 100 акций и вычислю их совокупную среднюю цену каждую секунду (или даже меньше) за последний год. Мне нужно создать много разных индексов, таких как этот, где акции динамически выбираются из 30 000 различных инструментов.

Основное внимание уделяется скорости. Мне нужно вывести несколько месяцев такого рода индексов как можно быстрее.

По этой причине я думаю, что традиционные СУБД слишком медленные, и поэтому я ищу сложное и оригинальное решение.

Вот что я имел в виду, используя NoSql или подход, ориентированный на столбцы: Распределите все акции по неким парам ключевых значений времени: цена с соответствующими временными рядами на всех них. Затем используйте какой-либо шаблон уменьшения карты, чтобы выбрать только требуемые акции и агрегировать их цены, читая их построчно.

Я хотел бы получить отзыв о моем подходе, предложениях по инструментам и сценариям использования или предложении совершенно другого шаблона проектирования. Моими рекомендациями для решения является цена (хотелось бы использовать открытый исходный код), возможность обрабатывать огромные объемы данных и, опять же, быстрый поиск (мне не нужны вставки, поскольку они сделаны только один раз и никогда не меняются)

Обновление: под быстрым поиском я подразумеваю не реальное время, а довольно быструю операцию. В настоящее время у меня уходит несколько минут на обработку каждого дня данных, что составляет несколько часов в год. Я хочу достичь этого в течение нескольких минут.

Answer 1

В прошлом я работал над несколькими проектами, которые включали хранение и обработку временных рядов с использованием различных методов хранения (файлы, RDBMS, базы данных NoSQL).Во всех этих проектах существенным моментом было убедиться, что образцы временных рядов хранятся последовательно на диске.Это обеспечило быстрое считывание нескольких тысяч последовательных сэмплов.

Поскольку у вас, по-видимому, имеется умеренное количество временных рядов (около 30 000), в каждом из которых содержится большое количество сэмплов (1 цена в секунду), простой, ноЭффективным подходом может быть запись каждого временного ряда в отдельный файл.Внутри файла цены упорядочены по времени.

Затем вам нужен индекс для каждого файла, чтобы вы могли быстро найти определенные моменты времени в файле и не нужно читать файл с самого начала.когда вам просто нужен определенный промежуток времени.

При таком подходе вы можете в полной мере воспользоваться преимуществами современных операционных систем, которые имеют большой файловый кэш и оптимизированы для последовательного чтения (обычно чтение вперед в файле при обнаружениипоследовательный шаблон).

Агрегирование нескольких временных рядов включает считывание определенного периода из каждого из этих файлов в память, вычисление агрегированных чисел и их запись куда-то.Чтобы полностью использовать операционную систему, прочитайте полный требуемый период каждого временного ряда один за другим и не пытайтесь читать их параллельно.Если вам нужно рассчитать длительный период, не разбивайте его на более мелкие периоды.

Вы упоминаете, что у вас есть 25 000 цен в день, когда вы уменьшаете их до одной в секунду.Мне кажется, что в таком временном ряду многие последовательные цены будут такими же, как торгуются (или даже оцениваются) немногие инструменты чаще, чем раз в секунду (если только вы не обрабатываете только акции S & P 500 и их производные).Таким образом, дополнительная оптимизация могла бы заключаться в дальнейшем сокращении ваших временных рядов путем сохранения нового образца, только когда цена действительно изменилась.

На более низком уровне файлы временных рядов могут быть организованы в виде двоичных файлов, состоящих из образцапробеги.Каждый прогон начинается с отметки времени первой цены и продолжительности пробега.После этого следуют цены в течение нескольких последовательных секунд.Смещение файла каждого прогона может быть сохранено в индексе, который может быть реализован с помощью реляционной СУБД (такой как MySQL).Эта база данных также будет содержать все метаданные для каждого временного ряда.

(Держитесь подальше от файлов, отображаемых в памяти. Они работают медленнее, поскольку не оптимизированы для последовательного доступа.)

Answer 2

Что вам действительно нужно, так это реляционная база данных, которая имеет встроенную функциональность временных рядов, IBM недавно выпустила одну Informix 11.7 (обратите внимание, что для получения этой функции должно быть 11.7).Еще лучше то, что для бесплатной версии Informix Innovator-C будет более чем достаточно.http://www.freeinformix.com/time-series-presentation-technical.html

Answer 3

Если сценарий, который вы описали, является ЕДИНСТВЕННЫМ требованием, то существуют простые «низкотехнологичные» решения, которые дешевле и проще в реализации. Первое, что приходит на ум - это LogParser. Если вы еще не слышали об этом, это инструмент, который запускает SQL-запросы для простых файлов CSV. Это невероятно быстро - обычно около 500K строк / сек, в зависимости от размера строки и пропускной способности ввода-вывода HD.

Сброс необработанных данных в CSV, выполнение простого агрегированного SQL-запроса через командную строку, и все готово. Трудно поверить, что это может быть так просто, но это так.

Подробнее о logparser:

• Википедия
• Код ужаса