Обновить

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

Уровень сложностиСредний
Время на прочтение7 мин
Охват и читатели5.3K
Всего голосов 7: ↑6 и ↓1+7
Комментарии4

Комментарии 4

А вообще, тут в своей статье я 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 не дадут в будущее заглянуть.

А разве сокеты СЕХсы не для этого строили ?

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации