Comments 12
На Clickhouse посмотрите, 32К записей в минуту для него - ерунда. Но нюансов у него куча....
Чел делает трагедию ("Как при всем этом не убить PostgreSQL") там где её нет- для вышеописанных задач и Postgre и, тем более, Clickhouse - явный оверинжиниринг, всё это с лихвой может делать обычный MySql на самой обычной бытовой машине с 16 Гб памяти. Ну с м2ссд под базой и правильными индексами.
А уж удаление "старых" данных - это вообще за пределом разумного. Это то, на чем можно и нужно обучаться, а их удаляют.
А вообще, тут в своей статье я 31 миллион записей читал за 5 секунд, то есть 6 млн в секунду. Файловое хранение.
https://habr.com/ru/articles/706074/
Позже переделал хранение на sql lite, сохраняя записи тоже чанками по суткам в одну запись. Скорость просела незначительно. В общем, 32К записей в минуту - это боль разве что для классических СУБД с хранением по записям в B-деревьях. Для этой задачи такое хранение не нужно. Если к такой классике не привязываться - то 32К даже в секунду - пустяк)
Решается либо несложной настройкой над классической СУБД (как у меня стало), либо - колоночная СУБД, типа кликхауса.
Надеюсь, не сильно расстрою. Но во-первых, для унифицированного доступа к биржам, перечисленным и многим другим, есть библиотека ccxt. Минус куча кода и костыли с verify=False.
Во-вторых, каждая из этих бирж дает более одного запроса в секунду, что абсолютно достаточно для этой задачи. Но есть нюанс, в общем-то гарантируется это только если использовать свой личный API-ключ, достаточно read-only. И тогда не надо будет замедляться до "раз в 5 секунд". Это очень медленно! За эти 5 секунд, другие боты, которые имеют объемы на биржах из связки уже полностью реализуют курсовую разницу. (Кстати, не заметил в статье, есть ли какая-то синхронизация этих интервалов? Потому что, вот сдвинем на 2.5 секунды график растущего актива с одной бижри относительно другой и будем постоянно видеть арбитражную разницу, но на деле ее не будет.)
В-третьих, зачем в этой задаче Postgres? Открываете набор бинарных файлов в append only, следите за seed (при перезапуске программы) и доливаете туда полученную инфу. Так даже 320К записей в секунду не будут проблемой от слова вообще. Зависит от того, что конкретно нужно сохранять, но это буквально десятки (менее сотни) строк кода. Очень хочется перелить это в бд? Пишем отдельный сервис, который делает это в фоне, но тут сильно зависит от того как мы в бд хотим с этими данными работать.
У вас и так очень редкий поллинг, раз в 5 секунд, еще и терять из этой инфы половину? Ну и вот это наводит уже больше на вопрос, а не "в-четвертых, ...". А какую задачу Вы надеетесь решить? Увидеть какое-то долгосрочное и существенное расхождение курсов? Я тоже с этим игрался, отмечу что так бывает, только если либо ввод/вывод актива временно отключен, либо есть существенно проблемный новостной фон. Никакие тогда выдуманные коэффициенты 0.3 и 0.7 не дадут в будущее заглянуть.
во-первых, для унифицированного доступа к биржам, перечисленным и многим другим, есть библиотека
Когда одна из бирж отваливается вы что делаете? Свой коннектор открыл и поправил, а тут что делать? обновление библиотеки ждать?
Открываете набор бинарных файлов в append only, следите за seed (при перезапуске программы) и доливаете туда полученную инфу
Тут надо понимать куда движешься, для узкой задачи- файлы - ок. Но как правило в кустарном финанализе эти данные потом хочется использовать и для других целей и можно застать себя зарывшимся в написание очередной не очень нужной балалайки псевдо-субд для поиска в этих файлах по нужным "полям". Когда пилишь чтото в одно лицо - я за готовую субд. Но это, естественно, зависит от крутости и вовлеченности программера.
очень редкий поллинг, раз в 5 секунд, еще и терять из этой инфы половину?
да, тоже вызвало недоумение, особенно своей якобы обусловленностью обереганием бд..
Когда одна из бирж отваливается вы что делаете? Свой коннектор открыл и поправил, а тут что делать? обновление библиотеки ждать?
В общем случае, да, либо исправляю библиотеку, либо пишу workaround. Другое дело, что API бирж категорически редко меняется, и даже при изменениях, уважающие себя биржи, просто дают эндпоинт /v2 .. /vN и все продолжает работать у тех, кто не желает обновляться. С ccxt проблем не было. Это своего рода стандарт в области.
Когда пилишь чтото в одно лицо - я за готовую субд. Но это, естественно, зависит от крутости и вовлеченности программера.
Если на определенном этапе мы еще не знаем, как конкретно будем обрабатывать данные, то все же БД преждевременна. А бинарные файлы даже без команды штука простая, их логику любой ИИ может запрограммировать на худой конец. Просто так мы сможем позволить себе выбор БД в последствии, исходя из конкретных задач, ничего не потеряем, и сохраним исходный интерфейс. Что у биржи мы могли спросить какая была цена актива/объемы торгов aaa на время xxx, что у бинарного файла. Это чуть лучшее решение, чем когда мы поняли, что в БД нам не достает данных, судорожно запускать догрузку этих данных напрямую с бирж (это может быть очень небыстрым процессом).
Ну и БД мы на самом деле не обязаны писать курс каждого тикера на каждый момент времени, можно группировать все тикеры с одной биржи на момент времени, и записей будет в 200-500 раз меньше. Ценой правда некого дополнительного неудобства работы с ними. В любом случае, не та задача, где нужно как-то обходить проблемы производительности жертвами.
А разве сокеты СЕХсы не для этого строили ?
Автор, большое спасибо за статью, всегда интересно почитать практикующего человека.
Позволю себе нескромный вопрос- есть устойчивый финансовый результат на межбиржевом спреде и если да- то какого порядка суммы? Просто вы с бытовым решением вторгаетесь в область суровых профи HFT, которые зачастую являются подразделением самих бирж и которые там вылизывают всё подчистую. Я для себя решил, что в ту область, где решения нужно принимать меньше чем за 100мс я не иду. Возможно я не прав.
в область суровых профи HFT
Еще добавлю, что они разворачивают свои сервера в тех же дата центрах что и находятся сервера СЕХ так как каждый тик важен.
и всеми правдами и неправдами стараются подключиться к тому же межстоечному свичу)
Я давно помню на крипто форуме с парнем общался, он разработчик веб3 на тот момент был, по общению очень шарящий во всем этом, как-то сказал он, что на банане есть вроде отдел одних из лучших на рынке htf-щиков, в общем лезть в арбитраж самому против лучших в мире высокочастотников полностью бессмысленное занятие, без штанов оставят в итоге.
Занимаюсь очень похожим, только на java.
Два важных момента пропущены.
Какими ордерами входить и выходить в сделки и комиссии при этом.
Проскальзывание. Даже при получении данных через веб сокеты и задержках на исполнение до всех бирж меньше 100мс - очень много теряется.
У меня сложилось впечатление, что весь арбитраж такого типа, "съедается" монстрами с высокими уровнями и низкими комиссиями и новичкам там близко делать нечего, нет там такой возможности для арбитража, где можно выйти хотя бы в ноль...
Как я написал радар межбиржевых спредов на Python и понял, почему 90% публичных ботов считают прибыль неправильно