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

Question

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

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

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

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

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

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

Edit: это для системы Linux (Ubuntu)

Спасибо

Answer 1

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

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

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

Answer 2

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

Answer 3

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

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

Answer 4

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

Answer 5

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

Answer 6

Мне просто пришло в голову, прочитав эту тему по адресу storing integers efficiently given certain conditions, что мы тратим много кусков, когда мы храним данные о тике как удваивает или плавает или что-то еще. ЦЕНЫ ЦЕНЫ! И совсем серьезно, при этом. Например, вчерашний диапазон NQ составлял примерно 2175-2191, или около 26 пунктов, квантован на 0,25. Таким образом, это ограничивает тики до ~ 100 разных цен. Смотрите, где я собираюсь с этим? Для каждой цены вам нужен только один байт. Запасы квантуются на 0,01, поэтому вам нужно ~ 1 байт за каждый доллар в дневном диапазоне.

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

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