Как настроить сбор данных для небольшого алгоритмического торгового программного обеспечения

Question

Это вопрос на концептуальном уровне.

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

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

Мой первый вопрос: учитывая тот факт, что данные будут в режиме реального времени, могу ли я использовать CSV-файл для хранения в начале или вы порекомендуете что-нибудь более существенное?

Вв любом случае, сбор данных будет выполняться в моем приложении как демон.

Мой второй вопрос: существуют ли какие-либо платформы для обработки входящих данных в реальном времени, чтобы поддерживать постоянную базу данных, пока остальная часть программного обеспечения запрашивает ее, чтобы избежать конфликтов?

Мой третий иИ последний вопрос: считаете ли вы, что в этом случае разумно использовать веб-сокет, или лучше запрашивать каждый раз, когда данные требуются для приложения?

Answer 1

Man Group, один из основных игроков в алго-трейдинге, открыла свое хранилище данных под названием Artic, разработанное специально для временных рядов и тиковых данных.Вы можете найти это здесь .

Answer 2

CSV - хороший формат обмена, но поскольку он основан на текстовом файле, он не подходит для обновлений в реальном времени. Только мое мнение, но я не могу представить себе причину, чтобы предпочесть это базе данных.

Для разрешения конфликтов в реальном времени вам потребуется база данных профессионального уровня. PostgreSQL имеет репутацию надежного сервера, и MariaDB, вероятно, также является правильным выбором. Вы можете использовать литровую базу данных в режиме разработки, таком как SQLite, но остерегайтесь небольших различий: легко написать что-то, что будет работать в одной базе данных и сломаться в другой. С другой стороны, если важна переносимость между базами данных, вам следует использовать как минимум две базы данных: одну во время разработки и другую во время интеграции.

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