Если вас не устраивает процесс найма, то, скорее всего вас не устроят и коллеги, нанятые по этому процессу.
Не вижу прямой связи. Есть коллеги которые работают со дня основания компании. Есть - нанятые другим, более адекватным эйчаром. Автор скорее сетует на проблему субъективности в оценках отдельных HR-менеджеров. От паршивой овцы - все стадо страдает. Имел опыт общения с одной такой.
Интересный подход, спасибо за разбор! Но возникает закономерный вопрос — зачем реализовывать такую логику на 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, безусловно, предпочтительнее.
Не вижу прямой связи. Есть коллеги которые работают со дня основания компании. Есть - нанятые другим, более адекватным эйчаром. Автор скорее сетует на проблему субъективности в оценках отдельных HR-менеджеров. От паршивой овцы - все стадо страдает. Имел опыт общения с одной такой.
ага, а перед этим банк открыть)
Думаю все сгорит при первой же молнии неподалеку. Или есть защита?
Летать и опылять - это хорошо. Но вот когда она мёд давать начнёт — вот это я понимаю будет технология!
Всегда хотел узнать - правда ли что они голову в песок прячут? Ну или хотя бы пытаются?
Интересный подход, спасибо за разбор! Но возникает закономерный вопрос — зачем реализовывать такую логику на 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, безусловно, предпочтительнее.