Безусловно часть сделок может теряться — это связано с тем, что REST API не предоставляет котировки в реальном времени. В результате возможны и ложные срабатывания: мы сравниваем не актуальные данные с биржи, а кэшированную копию, которая могла устареть.
Тем не менее, важно понимать: если сделка все же найдена, она проходит в сканере регулярную повторную проверку. И каждый раз — уже на обновленных данных. Это позволяет с высокой (практически 100%) уверенностью утверждать, что сделка действительно существует.
Ну может быть и повезло. Но думаю что если такие ограничения и вводят, это больше маркетинг. Типа привилегированным пользователям - больше плюшек. Чисто технически вебсокеты вообще лучше размещать на отдельной ноде и они никак не должны влиять на rest-api интерфейсы.
Это не так. Вы не совсем правильно понимаете работу WebSocket-каналов. Они не имеют таких ограничений как REST. В REST каждый запрос требует отдельного соединения, его каждый раз инициирует клиент. И каждое такое соединение дает нагрузку на сервер. Поэтому их кол-во в единицу времени ограничивают. При использовании WebSocket, соединение устанавливается одно на каждый тип данных, и оно постоянно открыто. Практически нет накладных расходов. Передачу данных по каналу инициирует сервер. Это позволяет транслировать котировки постоянным потоком в режиме реального времени. Тут больше вопрос к клиенту - он должен успевать их обрабатывать. Тысяч соединений не требуется, для одной биржи достаточно 3-4 каналов. И еще никаких лимитов по WebSocket со стороны сервера не существует. И их использование не приводит к ограничениям по REST. Эти сервисы обычно никак не связаны.
Да, действительно ограничения есть, и у каждой биржи они разные. У OKX например максимум 10 запросов в 2 секунды. Но хитрость в том, что поиск проходит в 2 этапа. На первом - мы выкачиваем все тикеты оптом, в одном запросе и производим первоначальное сравнение цен. Происходит отсев подавляющего большинства комбинаций. А по найденным сделкам уже полностью запрашиваем весь стакан и проверяем более тщательно с учетом глубины и комиссий. Их не так много на самом деле остается. На 16 бирж уходит меньше минуты. Кроме того, как я писал, в используемую библиотеку ccxt авторами включена система таймингов. И она сама знает к какой бирже, как часто можно обращаться. Если просишь слишком часто - выдаст данные из кэша. А вот если бирж подключить больше - тут без вебсокетов не обойдешься. Но это уже другая история.
2 870 — это общее количество криптовалютных пар, которые сканировались на 16 биржах. Как работает алгоритм: Сканер попарно сравнивает цены покупки и продажи между биржами по всем доступным валютам: сначала между двумя, затем следующими двумя, и так далее по списку. Общее число сравнений получается значительно больше — вручную такой объём проверить невозможно. Если находится положительная разница в ценах (когда можно купить дешевле, а продать дороже), сканер уведомляет пользователя о потенциально прибыльной сделке. Однако важно понимать: число действительно подходящих сделок на выходе существенно меньше, чем общее количество проверок. Цель проекта чисто академическая - проверить существуют ли реально арбитражные возможности и можно ли их использовать. API у бирж бесплатный, но некоторые требуют регистрацию. По частоте запросов так же могут быть ограничения, но это не критично.
Да, стратегия с распределёнными депозитами на нескольких биржах — действительно, позволяет обойти необходимость в on-chain переводах и существенно снизить задержки. Однако у этой схемы есть свои особенности:
Требуется заранее держать ликвидность на всех целевых биржах, что увеличивает нагрузку на капитал по крайне мере вдвое.
Необходима синхронизация сделок, чтобы избежать перекоса в позициях (например, закупился, но не успел продать). В своем эксперименте я намеренно пошёл по пути "классического" арбитража с физическим перемещением активов, чтобы понять, насколько вообще сейчас доступны такие возможности для розничного участника без больших финансовых затрат.
Но такой подход, безусловно, имеет практическую ценность. Спасибо за мысль!
Искусственный интеллект способен заменить половину чиновников, считает глава Минцифры РФ Максут Шадаев. При этом он уточнил, что человека, особенно врачей и учителей, нейросети все же не заменят.
Дальность связи Wi-Fi даже для прямой видимости в условиях отсутствия помех не превышает нескольких километров, какая может быть связь с самолетами? Конечно внутренняя.
Вы не поняли посыла моего сообщения. Дело не в корректности цифр в принципе, дело в их наличии. Мы говорили о важности производительности как фактора выбора. То что цифры публикуют - говорит о том что разработчики и пользователи считают этот фактор достаточно важным. Вот и все.
Я не сказал что он основной, но это один из основных факторов выбора, особенно когда речь идёт о BigData. Посмотрите на описания ORM на сайтах разработчиков или, например, на GitHub — в первых абзацах вы увидите бенчмарки и таблицы сравнения производительности. Как вы думаете, почему они там?
Тут важно понимать что сравнивать производительность запроса в БД с ORM и SQL смысла нет.
Сравнивать скрипты в БД действительно нет смысла, но не забывайте, что ORM - это как правило, инструмент маппинга данных внутри приложения и он неизбежно вносит свои накладные расходы. Это снижает скорость работы кода в обмен на удобство и простоту. Поэтому сравнивать нужно именно производительность внутри приложения.
По опыту могу сказать - обычно начинаешь проект с выбора одного из ORM, но как только решение достигает определенного уровня зрелости, в процессе очередного рефакторинга от этого дополнительного слоя часто приходится отказываться. Иногда по причине недостаточной гибкости, или же к примеру, когда надо ускорить ETL-процесс, чтобы миграция укладывалась в часовой период перерыва персонала и начинаешь бороться за каждый процент прироста производительности.
Как-то не очень раскрыта у вас тема: SQL vs ORM. Только тестируемость и безопасность затронули. А где сравнение производительности? Ведь это ж один из основных факторов при выборе. Можно также и скорость разработки сравнить и кросс-СУБД совместимость. А то информации хотите много собрать, а взамен даёте, на мой взгляд, недостаточно.
У меня примерно такая же история, только профиль другой - радиоэлектронная техника. Лепили курсовые как могли, да и дипломные тоже. Сто процентов эти изделия ни за что бы не заработали, хотя и выглядели на чертежах презентабельно. Помню как восхищался собой - что так ловко удалось провести преподавателей. Но только вот по прошедствии времени осознал, что им и не нужно было чтобы это работало. Не главное что чертежи - липа, главное - научить студента понимать процесс - что, за чем, в какой последовательности делать - поиск аналогов, конструкция, технология, испытания и т.д. И это основа успешных проектов в будущем.
Из российских еще Кандинского от Сбера забыли. Дли графики и видео.
https://www.sberbank.com/promo/kandinsky/
Безусловно часть сделок может теряться — это связано с тем, что REST API не предоставляет котировки в реальном времени. В результате возможны и ложные срабатывания: мы сравниваем не актуальные данные с биржи, а кэшированную копию, которая могла устареть.
Тем не менее, важно понимать: если сделка все же найдена, она проходит в сканере регулярную повторную проверку. И каждый раз — уже на обновленных данных. Это позволяет с высокой (практически 100%) уверенностью утверждать, что сделка действительно существует.
Ну может быть и повезло. Но думаю что если такие ограничения и вводят, это больше маркетинг. Типа привилегированным пользователям - больше плюшек. Чисто технически вебсокеты вообще лучше размещать на отдельной ноде и они никак не должны влиять на rest-api интерфейсы.
Это не так. Вы не совсем правильно понимаете работу WebSocket-каналов. Они не имеют таких ограничений как REST.
В REST каждый запрос требует отдельного соединения, его каждый раз инициирует клиент. И каждое такое соединение дает нагрузку на сервер. Поэтому их кол-во в единицу времени ограничивают.
При использовании WebSocket, соединение устанавливается одно на каждый тип данных, и оно постоянно открыто. Практически нет накладных расходов. Передачу данных по каналу инициирует сервер. Это позволяет транслировать котировки постоянным потоком в режиме реального времени. Тут больше вопрос к клиенту - он должен успевать их обрабатывать. Тысяч соединений не требуется, для одной биржи достаточно 3-4 каналов.
И еще никаких лимитов по WebSocket со стороны сервера не существует. И их использование не приводит к ограничениям по REST. Эти сервисы обычно никак не связаны.
Много бирж просто чтоб статистику собрать-изучить. В реальности то конечно много не надо.
Да, действительно ограничения есть, и у каждой биржи они разные. У OKX например максимум 10 запросов в 2 секунды. Но хитрость в том, что поиск проходит в 2 этапа. На первом - мы выкачиваем все тикеты оптом, в одном запросе и производим первоначальное сравнение цен. Происходит отсев подавляющего большинства комбинаций. А по найденным сделкам уже полностью запрашиваем весь стакан и проверяем более тщательно с учетом глубины и комиссий. Их не так много на самом деле остается. На 16 бирж уходит меньше минуты.
Кроме того, как я писал, в используемую библиотеку ccxt авторами включена система таймингов. И она сама знает к какой бирже, как часто можно обращаться. Если просишь слишком часто - выдаст данные из кэша.
А вот если бирж подключить больше - тут без вебсокетов не обойдешься. Но это уже другая история.
2 870 — это общее количество криптовалютных пар, которые сканировались на 16 биржах.
Как работает алгоритм:
Сканер попарно сравнивает цены покупки и продажи между биржами по всем доступным валютам: сначала между двумя, затем следующими двумя, и так далее по списку. Общее число сравнений получается значительно больше — вручную такой объём проверить невозможно.
Если находится положительная разница в ценах (когда можно купить дешевле, а продать дороже), сканер уведомляет пользователя о потенциально прибыльной сделке.
Однако важно понимать: число действительно подходящих сделок на выходе существенно меньше, чем общее количество проверок.
Цель проекта чисто академическая - проверить существуют ли реально арбитражные возможности и можно ли их использовать.
API у бирж бесплатный, но некоторые требуют регистрацию. По частоте запросов так же могут быть ограничения, но это не критично.
Да, стратегия с распределёнными депозитами на нескольких биржах — действительно, позволяет обойти необходимость в on-chain переводах и существенно снизить задержки. Однако у этой схемы есть свои особенности:
Требуется заранее держать ликвидность на всех целевых биржах, что увеличивает нагрузку на капитал по крайне мере вдвое.
Необходима синхронизация сделок, чтобы избежать перекоса в позициях (например, закупился, но не успел продать). В своем эксперименте я намеренно пошёл по пути "классического" арбитража с физическим перемещением активов, чтобы понять, насколько вообще сейчас доступны такие возможности для розничного участника без больших финансовых затрат.
Но такой подход, безусловно, имеет практическую ценность. Спасибо за мысль!
Я не специалист, но возможно они в действительности имели ввиду максимальную скорость выброса рабочего тела двигателем.
Почти поверил что это и правда ваша статья для дочери, но реклама в конце испортила впечатление.
Хотя в любом случае написано неплохо.
В смысле чиновник не человек...?
Да уж... надо было уговорить сингапурцев маску на кристалле поменять. Но никто ж не думал что так глубоко копать будут.
Скорее всего это лишние детали. И без них будет работать.
Дальность связи Wi-Fi даже для прямой видимости в условиях отсутствия помех не превышает нескольких километров, какая может быть связь с самолетами? Конечно внутренняя.
Ну это только если плохо припаяны или кисточка с железной проволокой )
Некоторые так и делают, я таких знаю. ))
Вы не поняли посыла моего сообщения. Дело не в корректности цифр в принципе, дело в их наличии. Мы говорили о важности производительности как фактора выбора. То что цифры публикуют - говорит о том что разработчики и пользователи считают этот фактор достаточно важным. Вот и все.
Я не сказал что он основной, но это один из основных факторов выбора, особенно когда речь идёт о BigData. Посмотрите на описания ORM на сайтах разработчиков или, например, на GitHub — в первых абзацах вы увидите бенчмарки и таблицы сравнения производительности. Как вы думаете, почему они там?
Сравнивать скрипты в БД действительно нет смысла, но не забывайте, что ORM - это как правило, инструмент маппинга данных внутри приложения и он неизбежно вносит свои накладные расходы. Это снижает скорость работы кода в обмен на удобство и простоту. Поэтому сравнивать нужно именно производительность внутри приложения.
По опыту могу сказать - обычно начинаешь проект с выбора одного из ORM, но как только решение достигает определенного уровня зрелости, в процессе очередного рефакторинга от этого дополнительного слоя часто приходится отказываться. Иногда по причине недостаточной гибкости, или же к примеру, когда надо ускорить ETL-процесс, чтобы миграция укладывалась в часовой период перерыва персонала и начинаешь бороться за каждый процент прироста производительности.
Как-то не очень раскрыта у вас тема: SQL vs ORM.
Только тестируемость и безопасность затронули. А где сравнение производительности? Ведь это ж один из основных факторов при выборе. Можно также и скорость разработки сравнить и кросс-СУБД совместимость. А то информации хотите много собрать, а взамен даёте, на мой взгляд, недостаточно.
У меня примерно такая же история, только профиль другой - радиоэлектронная техника. Лепили курсовые как могли, да и дипломные тоже. Сто процентов эти изделия ни за что бы не заработали, хотя и выглядели на чертежах презентабельно. Помню как восхищался собой - что так ловко удалось провести преподавателей. Но только вот по прошедствии времени осознал, что им и не нужно было чтобы это работало. Не главное что чертежи - липа, главное - научить студента понимать процесс - что, за чем, в какой последовательности делать - поиск аналогов, конструкция, технология, испытания и т.д. И это основа успешных проектов в будущем.