Сбор, хранение и извлечение большого количества числовых данных

Question

Я собираюсь начать сбор больших объемов числовых данных в режиме реального времени (для тех, кто заинтересован: bid / ask / last или 'tape' для различных акций и фьючерсов). Данные будут позже получены для анализа и моделирования. Это совсем не сложно, но я хотел бы сделать это эффективно, и это вызывает много вопросов. Мне не нужно лучшее решение (и в любом случае, в зависимости от метрики, вероятно, много «лучших»). Я просто хотел бы решение, которое одобрил бы ученый. (Или не смейся?)

(1) Оптимизировать для дискового пространства, скорости ввода-вывода или памяти?

Для симуляции важна общая скорость. Мы хотим, чтобы скорость ввода / вывода (на самом деле, I) данных была выше, чем вычислительная машина, поэтому мы не ограничены в вводе / выводе.

(2) Сохранить текст или что-то еще (двоичное число)?

(3) Учитывая набор вариантов из (1) - (2), существуют ли какие-либо выдающиеся комбинации языка / библиотеки для выполнения работы - Java, Python, C ++ или что-то еще?

Я бы классифицировал этот код как «пиши и забывай», так что больше баллов за эффективность по сравнению с ясностью / компактностью кода. Я очень, очень хотел бы придерживаться Python для кода симуляции (потому что симы сильно меняются и должны быть ясны). Так что бонусные баллы за хорошие решения Pythonic.

Редактировать: это для системы Linux (Ubuntu)

Спасибо

Answer 1

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

2. Двоичный код более компактен (и, следовательно, быстрее). Учитывая количество данных, я сомневаюсь, что читаемость имеет какое-то значение. Единственное преимущество текстового формата состоит в том, что его легче выяснить и исправить, если он поврежден или вы потеряете код синтаксического анализа.

Answer 2

Использование формата D-Bus для отправки информации может быть вашим преимуществом. Формат является стандартным, двоичным, и D-Bus реализован на нескольких языках и может использоваться для отправки по сети и между процессами на одном компьютере.

Answer 3

На самом деле, это очень похоже на то, что я делаю, это мониторинг изменений, которые игроки вносят в мир в игре.В настоящее время я использую базу данных sqlite с python.В начале программы я загружаю базу данных диска в память для быстрой записи.Каждое изменение заносится в два списка.Эти списки предназначены как для базы данных памяти, так и для базы данных диска.Каждый х или около того обновляется, база данных памяти обновляется, и счетчик увеличивается на единицу.Это повторяется, и когда счетчик равен 5, он сбрасывается, и список с изменениями для диска сбрасывается в базу данных диска, и список очищается. Я обнаружил, что это работает хорошо, если я также установил запись больше на WOL (ЗаписьВпереди ведение журнала).Этот метод может выдерживать около 100-300 обновлений в секунду, если я обновляю память каждые 100 обновлений, а счетчик диска настроен на обновление каждые 5 обновлений памяти.Вы должны, вероятно, выбрать двоичный файл, смысл, если у вас нет ошибок в ваших источниках данных, будет наиболее логичным

Answer 4

Fame - это часто используемое коммерческое решение для хранения временных рядов.

Если вы серьезно относитесь к этому, создание собственного будет большой работой. HDF может быть полезным, они утверждают, что он подходит для обработки тиковых данных и имеют доступ к C ++.Здесь есть поддержка Python здесь .

Полезный реальный опыт от кого-то с такой же проблемой здесь , включая ссылки HDF5.

Answer 5

Мне только что пришло в голову прочитать эту ветку о эффективном хранении целых чисел при определенных условиях , что мы теряем много битов, когда храним данные о тиках как удвоенные или плавающие числа или что-то еще. ЦЕНЫ КОЛИЧЕСТВЕННО ЦЕНЫ! И довольно серьезно.Например, вчерашний диапазон NQ был около 2175-2191, или около 26 пунктов, квантованных на 0,25.Таким образом, тики ограничиваются до ~ 100 разных цен.Видишь, куда я иду с этим?Вам нужен только один байт для каждой цены.Акции квантуются на 0,01, поэтому вам потребуется ~ 1 байт на каждый доллар в дневном диапазоне.

Итак, метод, который я обрисовал в общих чертах: (1) хранить высокую цену, низкую цену и приращение как один заголовок строки (2) сохранять данные тика после этого в виде двух байтов с двумя крайними левыми битамииспользуется для кодирования типа тика (00 = последний, 01 = ставка, 11 = спрос)

Я думаю, это то, что CS одобрил бы!

Answer 6

Если вы просто храните, используйте системные инструменты. Не пиши свое. Если вам необходимо выполнить некоторую обработку данных в реальном времени до того, как они будут сохранены, тогда это нечто совершенно другое.