Интересный подход, спасибо за разбор! Но возникает закономерный вопрос — зачем реализовывать такую логику на C#, если даже базовые SQL-движки справляются с задачами декартова произведения и агрегаций на порядок быстрее?
Например, аналогичная операция в SQL Server (декартово произведение 1 млн × 1 млн и выборка первых 1 млн строк):
WITH T1 AS (
SELECT TOP (1000000) ROW_NUMBER() OVER (ORDER BY (SELECT NULL)) - 1 AS a
FROM sys.all_objects AS a
CROSS JOIN sys.all_objects AS b
),
T2 AS (
SELECT TOP (1000000) ROW_NUMBER() OVER (ORDER BY (SELECT NULL)) - 1 AS b
FROM sys.all_objects AS a
CROSS JOIN sys.all_objects AS b
)
SELECT TOP (1000000) *
FROM T1
CROSS JOIN T2;
У меня этот запрос выполняется за ~4 секунды.
А вот эквивалент для ClickHouse (1 млн × 1 млн, первые 1 млн. строк):
SELECT *
FROM
(
SELECT number AS a
FROM numbers(1000000)
) AS t1
JOIN
(
SELECT number AS b
FROM numbers(1000000)
) AS t2
ON 1 = 1
LIMIT 1000000;
На ClickHouse — ~0.12 сек.
Понятно, что у DaxSharp немного иная цель — эмулировать семантику DAX и SUMMARIZECOLUMNS в .NET-приложениях. Но если говорить исключительно о производительности и объёмах, SQL-инструменты всё ещё выглядят значительно предпочтительнее.
Лично я практически перестал ходить на Stack Overflow, когда модераторы заблокировали несколько моих ответов, которые я по незнанию новых правил отредактировал в ChatGPT. Да нейронка помогла мне их оформить и привести в приличный вид, но идеи то были мои. Видимо детектор все же их зарубил. К тому же информация была просто удалена с сайта, и копии у меня не осталось. Это показалось мне несправедливым, от чего пропало желание вообще посещать это веб-ресурс. Через какое-то время администрация сайта видимо опомнилась и вроде бы разрешила ответы от ИИ, но было уже поздно. Народ вовсю переходил на помощь от LLM.
Хороший вопрос. Чтобы ответить подробно, нужно немного углубиться в реализацию.
В сканере большинство процессов работают асинхронно и параллельно — у каждого этапа своя очередь и свой поток. На первом этапе мы используем так называемые тикеры — это краткая информация по каждой паре (например, текущие bid/ask), но без глубины стакана. При использовании REST большинство бирж позволяют получить тикеры по всем парам одним запросом. Это позволяет быстро пробежать по тысячам пар (например, с 16 бирж) за несколько секунд.
На этом этапе применяется простая проверка: если bid ≤ ask, то арбитража нет — такая пара сразу отбрасывается. Остаются только те, где есть потенциальная разница — их, как правило, немного. Эти пары попадают в отдельную очередь для более глубокой проверки.
На втором этапе для проверки ликвидности мы уже загружаем стакан (orderbook) по каждой отфильтрованной паре — да, тут запросы идут по одной паре, но объём данных гораздо меньше, и вся цепочка проверки по всем биржам обычно укладывается в менее чем минуту.
Такой подход позволяет избежать O(n²) для всех пар — мы сначала отбрасываем "явно неинтересные" комбинации, а затем более точно обрабатываем только потенциально релевантные.
Согласен, гарантировать 100% исполнение сделки невозможно — цепочка действий не является атомарной и содержит неизбежные задержки.
Процесс выглядит следующим образом: изменение цены на бирже → получение данных (REST) → анализ → уведомление пользователя → формирование и отправка ордера → исполнение на бирже.
Основные риски сосредоточены на последних двух этапах: отправка ордера и его исполнение занимают наибольшее время и подвержены внешним факторам — таким как волатильность, задержки на стороне пользователя (человеческий фактор) или отказ API.
Когда я говорил о "практически 100%" - это касалось достоверности сигнала на момент его генерации. Сделка с положительным профитом действительно существовала в рыночных данных, проверялась повторно и подтверждалась на уже обновлённых котировках. Однако это не означает, что её удастся реализовать - вероятность "устаревания" сигнала возрастает именно в момент исполнения, особенно при высокой волатильности. Таким образом, точность детекции близка к 100%, но успех исполнения зависит от внешних условий и скорости реакции.
Вы правы - если рассуждать строго, "реального времени" как такового не существует - любые данные, полученные через API, уже устарели на момент их обработки. Я использовал этот термин условно, имея в виду, что задержки при получении данных через REST, как правило, существенно выше, чем при работе через WebSocket.
Как я уже упоминал, текущий проект — это эксперимент, и REST был выбран в первую очередь ради простоты реализации. Для полноценной работы, особенно если нужно отслеживать множество торговых пар одновременно, использование WSS, безусловно, предпочтительнее.
Безусловно часть сделок может теряться — это связано с тем, что REST API не предоставляет котировки в реальном времени. В результате возможны и ложные срабатывания: мы сравниваем не актуальные данные с биржи, а кэшированную копию, которая могла устареть.
Тем не менее, важно понимать: если сделка все же найдена, она проходит в сканере регулярную повторную проверку. И каждый раз — уже на обновленных данных. Это позволяет с высокой (практически 100%) уверенностью утверждать, что сделка действительно существует.
Ну может быть и повезло. Но думаю что если такие ограничения и вводят, это больше маркетинг. Типа привилегированным пользователям - больше плюшек. Чисто технически вебсокеты вообще лучше размещать на отдельной ноде и они никак не должны влиять на rest-api интерфейсы.
Это не так. Вы не совсем правильно понимаете работу WebSocket-каналов. Они не имеют таких ограничений как REST. В REST каждый запрос требует отдельного соединения, его каждый раз инициирует клиент. И каждое такое соединение дает нагрузку на сервер. Поэтому их кол-во в единицу времени ограничивают. При использовании WebSocket, соединение устанавливается одно на каждый тип данных, и оно постоянно открыто. Практически нет накладных расходов. Передачу данных по каналу инициирует сервер. Это позволяет транслировать котировки постоянным потоком в режиме реального времени. Тут больше вопрос к клиенту - он должен успевать их обрабатывать. Тысяч соединений не требуется, для одной биржи достаточно 3-4 каналов. И еще никаких лимитов по WebSocket со стороны сервера не существует. И их использование не приводит к ограничениям по REST. Эти сервисы обычно никак не связаны.
Интересный подход, спасибо за разбор! Но возникает закономерный вопрос — зачем реализовывать такую логику на C#, если даже базовые SQL-движки справляются с задачами декартова произведения и агрегаций на порядок быстрее?
Например, аналогичная операция в SQL Server (декартово произведение 1 млн × 1 млн и выборка первых 1 млн строк):
У меня этот запрос выполняется за ~4 секунды.
А вот эквивалент для ClickHouse (1 млн × 1 млн, первые 1 млн. строк):
На ClickHouse — ~0.12 сек.
Понятно, что у DaxSharp немного иная цель — эмулировать семантику DAX и SUMMARIZECOLUMNS в .NET-приложениях. Но если говорить исключительно о производительности и объёмах, SQL-инструменты всё ещё выглядят значительно предпочтительнее.
Сканер криптобирж.
🔗 https://github.com/Alex-ok2005/crypto-arbitrage-scanner
🔗 https://habr.com/ru/articles/911056/
Она выбрала быть счастливой...
На самом деле в статье нет ответа на свой же поставленный вопрос. Этот пост как раз все и проясняет. Респект.
Возможно смысл в том, чтобы испытать на максимальной скорости, но не строить длинную трассу для ее достижения.
может все таки дофамин
Так ему ИИ и тесты написал )
Да, но они сначала приняли их, и ответы провисели некоторое время. Удалили без предупреждения, точнее написали уже по факту.
Лично я практически перестал ходить на Stack Overflow, когда модераторы заблокировали несколько моих ответов, которые я по незнанию новых правил отредактировал в ChatGPT. Да нейронка помогла мне их оформить и привести в приличный вид, но идеи то были мои. Видимо детектор все же их зарубил. К тому же информация была просто удалена с сайта, и копии у меня не осталось. Это показалось мне несправедливым, от чего пропало желание вообще посещать это веб-ресурс.
Через какое-то время администрация сайта видимо опомнилась и вроде бы разрешила ответы от ИИ, но было уже поздно. Народ вовсю переходил на помощь от LLM.
Это как кризис физики конца XIX века. Когда многие учёные считали, что основные законы природы уже открыты, а осталось лишь уточнить детали.
Надо на гитхабе посмотреть, может уже есть готовые. ))
Не совсем понял, вы котировки получаемы с mexc переводите на protobuf? Зачем?
Хороший вопрос. Чтобы ответить подробно, нужно немного углубиться в реализацию.
В сканере большинство процессов работают асинхронно и параллельно — у каждого этапа своя очередь и свой поток. На первом этапе мы используем так называемые тикеры — это краткая информация по каждой паре (например, текущие bid/ask), но без глубины стакана. При использовании REST большинство бирж позволяют получить тикеры по всем парам одним запросом. Это позволяет быстро пробежать по тысячам пар (например, с 16 бирж) за несколько секунд.
На этом этапе применяется простая проверка: если bid ≤ ask, то арбитража нет — такая пара сразу отбрасывается. Остаются только те, где есть потенциальная разница — их, как правило, немного. Эти пары попадают в отдельную очередь для более глубокой проверки.
На втором этапе для проверки ликвидности мы уже загружаем стакан (orderbook) по каждой отфильтрованной паре — да, тут запросы идут по одной паре, но объём данных гораздо меньше, и вся цепочка проверки по всем биржам обычно укладывается в менее чем минуту.
Такой подход позволяет избежать O(n²) для всех пар — мы сначала отбрасываем "явно неинтересные" комбинации, а затем более точно обрабатываем только потенциально релевантные.
Согласен, гарантировать 100% исполнение сделки невозможно — цепочка действий не является атомарной и содержит неизбежные задержки.
Процесс выглядит следующим образом:
изменение цены на бирже → получение данных (REST) → анализ → уведомление пользователя → формирование и отправка ордера → исполнение на бирже.
Основные риски сосредоточены на последних двух этапах: отправка ордера и его исполнение занимают наибольшее время и подвержены внешним факторам — таким как волатильность, задержки на стороне пользователя (человеческий фактор) или отказ API.
Когда я говорил о "практически 100%" - это касалось достоверности сигнала на момент его генерации. Сделка с положительным профитом действительно существовала в рыночных данных, проверялась повторно и подтверждалась на уже обновлённых котировках. Однако это не означает, что её удастся реализовать - вероятность "устаревания" сигнала возрастает именно в момент исполнения, особенно при высокой волатильности. Таким образом, точность детекции близка к 100%, но успех исполнения зависит от внешних условий и скорости реакции.
Вы правы - если рассуждать строго, "реального времени" как такового не существует - любые данные, полученные через API, уже устарели на момент их обработки. Я использовал этот термин условно, имея в виду, что задержки при получении данных через REST, как правило, существенно выше, чем при работе через WebSocket.
Как я уже упоминал, текущий проект — это эксперимент, и REST был выбран в первую очередь ради простоты реализации. Для полноценной работы, особенно если нужно отслеживать множество торговых пар одновременно, использование WSS, безусловно, предпочтительнее.
Из российских еще Кандинского от Сбера забыли. Дли графики и видео.
https://www.sberbank.com/promo/kandinsky/
Безусловно часть сделок может теряться — это связано с тем, что REST API не предоставляет котировки в реальном времени. В результате возможны и ложные срабатывания: мы сравниваем не актуальные данные с биржи, а кэшированную копию, которая могла устареть.
Тем не менее, важно понимать: если сделка все же найдена, она проходит в сканере регулярную повторную проверку. И каждый раз — уже на обновленных данных. Это позволяет с высокой (практически 100%) уверенностью утверждать, что сделка действительно существует.
Ну может быть и повезло. Но думаю что если такие ограничения и вводят, это больше маркетинг. Типа привилегированным пользователям - больше плюшек. Чисто технически вебсокеты вообще лучше размещать на отдельной ноде и они никак не должны влиять на rest-api интерфейсы.
Это не так. Вы не совсем правильно понимаете работу WebSocket-каналов. Они не имеют таких ограничений как REST.
В REST каждый запрос требует отдельного соединения, его каждый раз инициирует клиент. И каждое такое соединение дает нагрузку на сервер. Поэтому их кол-во в единицу времени ограничивают.
При использовании WebSocket, соединение устанавливается одно на каждый тип данных, и оно постоянно открыто. Практически нет накладных расходов. Передачу данных по каналу инициирует сервер. Это позволяет транслировать котировки постоянным потоком в режиме реального времени. Тут больше вопрос к клиенту - он должен успевать их обрабатывать. Тысяч соединений не требуется, для одной биржи достаточно 3-4 каналов.
И еще никаких лимитов по WebSocket со стороны сервера не существует. И их использование не приводит к ограничениям по REST. Эти сервисы обычно никак не связаны.
Много бирж просто чтоб статистику собрать-изучить. В реальности то конечно много не надо.