Блог им. MadMaddy

Первые сдвиги в Go + SQL

    • 24 октября 2025, 15:01
    • |
    • ADT
  • Еще

В общем долго я маялся, мучился, ленился и, таки себя пересилив, в конечном счете сел за программирование. Кое-как, со скрипом, но сел. Начал буквально через силу: думаю «блин, мне под сраку лет уже, а я пишу какие-то задачки для 5 класса, какого...?». Но это гонор, я засунул его в Ж. и стал тупо брать и делать. Цель есть и надо идти вперед.

Сначала по видео учился, благо недавно у Нильчанпаба вышел четкий курс по Go в 2 частях, большой объемный, хорошо рассказанный с кодом и большой аргументацией. На ютубе лежит, кому надо — найдёте. В принципе вот именно он меня и сдвинул с мертвой точки. Хорошо парень рассказывает, стал его подробно проходить, с тетрадкой, записывая все важное (а там — всё важное!). 2х13 часов видео курс по основам (недели 3-4 заняло по 5-6 часов в день).

Потом стал пробовать писать код, написал всяких простеньких залипух порядка 1.5 сотен. Теперь полностью (почти полностью) понимаю код и пробую писать бота по своей ТС, благо я эту систему сам придумал и знаю ее всю досконально. Все подводные камни помню и предвижу после работы с наемными программистами ранее. ИИ помогает с ошибками и интерфейсом, книгу уже использую как справочник (ага использую, это громко сказано), в общем первые сдвиги есть. А все очень непросто, но интересно. Однако, приятно понимать, что уже что-то можешь. Ладно, как я там говорил, дорогу осилит идущий? Вот-вот.

Тружусь, надеюсь за год приду к простенькой базовой реализации (хотя хрен его знает, там впереди столько всего, а я еще SQL задумал, но по SQL опыт у меня хороший по работе). А БТ пусть пока питоновский остаётся. Он исправен и буду из него сетапы брать. 

Такие дела. Впереди долгий путь, но мне уже не привыкать :) Хвастовство в картинках приложил :) 

Первые сдвиги в Go + SQL

Первые сдвиги в Go + SQL

Первые сдвиги в Go + SQL

434
30 комментариев
Go ужасный язык, неудобный, многословный и весьма ограниченный. Хорош только для задач с многопоточностью. 

Почему такой выбор?
avatar
Alexs, компилируемый, многопоточный, со строгой типизацией, относительно простой по синтаксису, с автоматическим сборщиком мусора (RAMой сам управляет). Вкусовщину опустим. Многопоточность — главное. Жизненно необходимо для скорости бота.
avatar
И как язык программирования можно выучить по видео, это тоже великая загадка. Ну купите книжку то на озоне, епрст. Все равно читать писать придётся раз уж взялись за это дело ) 
avatar
Alexs, Азы по видео, удобнее чем книгу читать. А теперь и видео, и книга (пока одна) и гитхаб, и хабр, и ИИ, и еще много всего. Конечно не только видео. Ничего я вообще еще не выучил… только самые азы. Я пока добился чтобы с ключами отправлялись запросы на bybit — перематерился 10 раз. Кореша программеры помогают. Самому всё учить — это невозможно.
avatar
Go-Go! Happy hour! Или вы не об этом?!
avatar
myaucha, что?
avatar
Зачем Go? Почему не Python?
avatar

Михаил Михалёв, приветствую земляка. Уже есть мой бот на питоне, от 5 сетапов и более вообще опухает бот. Написано, как оказалось, монолитом, что мягко говоря не быстро. Плюс мой однокурсник из техунивера (программист со стажем 25+, живет в Европе знает кучу языков) порекомендовал почитать это, чтобы снять все вопросы по выбору языка для HFT:

habr.com/ru/companies/geekfactor/articles/682084/

Спорить не буду.

avatar
ADT, Сам питон может и тормоз (есть пути значительно ускорить), но у него куча библиотек, которые написаны на плюсах. Те же pandas/numpy, ведь наверняка почти все Ваши алгоритмы сводятся к использованию массивов данных и операций над ними. Да и tensorflow keras проще использовать, а он тоже внутри написан на плюсах и может использовать gpu. Плюс многопроцессорность, корутины. Не спорю, просто пытаюсь понять выбор:)
avatar
ADT, там есть правильный комментарий — Статья то про выбор языка для компании.

Go — хороший язык для написание продуктового кода с использованием микросервисов в большой компании
Если это маленькая компания или один человек или не классический продуктовый код про перекладывание json-ов — очень спорное решение
Если много математики и статистики — в Go c этим очень плохо, так как нет нормальных библиотек
Если нужна очень большая скорость, то тоже есть варианты получше

ИМХО если скорость не важна (не надо укладываться в микросекунды и с сервером на колокейшене), но много математики (стат тесты, ML/DL), то лучше Python
Если чего-то очень быстрое, то Rust или С и сервер на колокейшене

Чего у вас на Python тормозит дистанционно сложно понять — при правильной реализации, все тормозное выполняется в библиотеках вроде numpy или pytorch со скоростью недостижимой на Go, а для io операций есть asyncio
avatar

Михаил, мне трудно спорить, я начинающий совсем. Да и зачем об этом спорить, холивары программеров давно известны. Выбор языка это же ВЫБОР, вот я и выбрал Go. Скорость ОЧЕНЬ важна. На Питоне мне писали, результат очень слабый по скорости. На Rust писать сильно сложнее, сказали опытные ребята, вообще не лезь в это. Плюсы — тем более. Предлагали еще C#, тоже хороший и быстрый язык, но я выбрал Go, dot.Net может потом, если понадобится. Так и сказали, если надо быстро и многопоточно, то по скорости после плюсов и раста — только Go. Я уже вижу как летает Go в агрегации свечей параллельно в 10 потоков — это раз в 20 быстрее, чем делал код на питоне. Может быть его так написали, возможно. Не вижу смысла дальше обсуждать, думаю вопрос можно закрыть. И я — не компания, я сам по себе, пока что.

P.S. Упомянутый вами комментарий являлся ответом про зарплаты программистов в компании, а не про то, лучше go или хуже. Зарплаты программистов мне не актуальны пока.

avatar
ADT, мне просто кажется вы видите проблему, там где ее реально нет, а реальную проблему не видите. Вы можете пояснить, чего за агрегация свечей, которую вам нужно все время делать и как быстро эти свечи появляются?
avatar

Михаил, а вы посмотрите внимательно на картинку с командной строкой и командами SQL, там видно какие свечи собираются (по продолжительности) и из каких они собираются. И почему собираются такие нестандартные интервалы… У меня очень не банальная система и очень нестандартная логика бота. Вот её и предстоит реализовать. Это все подготовка, тут еще даже условия входа не начал прописывать. Впереди много труда.

А сетапов у меня в интерфейсе будет примерно 50 (это когда я буду уверен что логика бота работает хорошо — пока я не дошел до этого). Пайтон на 10 уже опухал в плане отправки ордеров, опроса позиций, слежкой за ценой, а когда добавили сетку… вообще туши свет. Скорость как на бейсике.
А еще представьте у меня на одном и том же тикере одновременно торгуется 3-4 разных торговых сетапа с разными условиями. Если вы со стороны посмотрите что бот там делает с ордерами — вам это покажется вовсе каким-то мракобесием! но тем не менее. Поверьте в торговых системах я далеко ушел и обсчитывать их научился давно. Это вовсе не то, чтобы гадать куда пойдет цена.

Зачем вам в это вникать? Я то одну и ту же задачу реализую на другом языке по той же логике, и уже вижу разницу, даже на этапе параллельного сбора данных и их агрегации — все делается сразу, есть только небольшие вопросы над усилением конфигурации сервера. Смысл спорить с этим?

avatar
ADT, 
> вы посмотрите внимательно на картинку с командной строкой и командами SQL, там видно какие свечи собираются

Я видел картинки с часовыми и более редкими свечками, видел ваши рассказы про пинг до сервера под 100 мс в предыдущем посте и большие конфиги (не понимаю, как это вообще может влиять), 50 сетапов — это кажется крайне несущественной нагрузкой. Поэтому у меня большое подозрение, что вы не очень понимаете в чем реальная причина торможения, и что совершаете какие-то простые, но совершенно неочевидные вам ошибки

Я не спорю с вами, что тупое переписывание на Go может некоторые вещи ускорить, но есть подозрение, что ускорение там совсем не из-за потоков, как вы думаете, а из-за не блокирующих io-операций, которые вполне успешно делаются в Питоне. И если вы реально поймете, в чем причина торможения, то вероятно ускоритесь гораздо существеннее

Считаю, что всегда неплохо, когда кто-то осваивает, что-то новое, и просто хотел вам помочь разобраться. Если есть желание, то можно попробовать обсудить без погружение в конфидециальные делали, что вы делаете и попробовать разобраться, как это ускорить. Ну а если желания нет и интересно копаться самому — могу вам пожелать только успехов
avatar

Михаил, спасибо вам за добрые слова!

Благодарен Вам за желание помочь, правда, но все же тут без погружения в нюансы бота помочь не получится — а их много, бот не простой.

Подытожим: я сам пайтон не писал, мне на пайтоне код писал другой программист. Я тестировал. Написано монолитом, файлы бота огромные и трудночитаемые, по 900-1200 строк. Все последовательно, даже свечи загружаются последовательно, один тикер за другим, баз данных там нет, все в RAM, именно по этому при 2 и более сетапах на одном тикере возникают долгие задержки и даже ошибки логики. но там отдельная песня, продолжу по теме.

Для сравнения, на Го сейчас уже параллельно все тикеры в базу залетают, на 5-летней истории часовики например (а это порядка 45 тыс. свечей на тикер) залетают около 20 секунд включая запросы и запись в SQL параллельно! А там на 10 сетапах сбор составляет 4-5 минут. Это раз.

Дописывание часовиков в реалтайме происходит менее секунды в записью а базу, на пайтоне разработчик меня лечил что биржа долго отдает свечу, поэтому только через 10 секунд ордер ставится, а мог ставится через 1 секунду. 

Далее: при торговле, в пайтоне используется конфиг.пай, там мы прописываем все параметры торговой системы и торгуем например 10 тикеров. Пайтон идет последовательно по коду конфига, опрашивая один сетап за другим, проверяя позиции, следя за ценой, раскидывая ордеры (а вход там стоп-лимитами, иначе математика ТС «поедет»), и проход по одному конфигу (для 10 сетапов) занимает около минуты! Минута, «Карл»! Частенько возникали ситуации, когда цена была рядом — она могла и убегала от ентри поинта, приходилось покупать маркетами, иначе пропуски входов… В общем проблемы, проблемы, проблемы… Именно из-за быстродействия. Я решал это всё примерно год, но в итоге все заканчивалось фразой разработчика «сделаю в несколько потоков, дай денег». Объяснять думаю не надо, как дальше наглели разработчики.

Го может параллельно разными рутинами все это делать. На агрегаторе торговых ТФ я уже убедился как это быстро может работать и уже (!) работает. Часть параметров слушаем вебсокетом, позициями управляем через REST API. и так далее. 

Может и пайтон так умеет, спору нет, думаю мне просто написали все криво. Но я хотел изучать именно компилируемый язык со строгой типизацией и многопоточностью. Выбор пал на Go.

Ладно, думаю — понятно. Дальше расписывать не буду. Быстродействие кода во главе угла. И спасибо за помощь, еще раз.  

avatar
ADT, ключевая проблема — «разработчик меня лечил», а не в Питоне. В Питоне есть потоки, есть процессы, асинхронные не блокирующие запросы в одном потоке. Не знаю, что там за разработчик, но нормальный сейчас получает от 25к в час. Возможно писать самому вполне разумный выбор для саморазвития и экономии средств, тем более там еще поди пойми нормальный разработчик или нет, если в этом не разбираешься

Если у вас много запросов по сети, то потоки особо не нужны, если у вас не десятки тысяч запросов в секунду. Потоки скорее нужны для тяжелой математики, с чем у Go есть проблемы в отличии от Питона. В общем-то у Go со всем проблемы кроме сетевых вызовов. Нарисовать какой-то банальный график или быстро покрутить данные в разных разрезах — отдельных большая задача, хотя в Питоне это делается на щелчок пальцев. Ну если нужно только делать запросы к удаленному серверу и сохранять в базу + какие-то примитивные операции уровня сложить поделить несколько чисел, то Go вполне нормальный вариант

Я на Go пишу каждый день, но вот для трейдинга пишу на Python. Пытался на Go, но плюнул — пользы мало, а постоянно спотыкаешься об какие-то ограничения языка, но у меня много всякой не простой математики + нейронные сеточки

Успехов вам. Освоить язык и писать небольшие программы достаточно легко, но поддерживать кодовую базу по мере ее разрастания совсем другого уровня задача, которую гораздо сложнее осилить
avatar

Михаил, ну вот о том и речь, разрабер такой и был (не тот, который друг, а тот который дальше мне проект развивал): ушлый и не великих скиллов, получается. Много считать мне наверное не понадобится, по крайней мере в боте. А вот в бэктесте (БТ)… Там сплошь расчеты. БТ на питоне работает у меня сейчас, но тоже медленно.

Пример: рассчитываю один торговый набор по одному тикеру в одном БэкТесте, с разными тейками и стопами и разными параметрами входа просчитываю таймфрейм и тикер. Это примерно 15000 сетапов для расчета (бывает и больше). А главная задача бэктесту — это разбирать свечи на более мелкие и смотреть где точно был вход, что случилось раньше тейк или стоп, время в сделке, просадки до тейка и т.д… Там много ценного можно увидеть.

Так вот: считаем всю историю какого нибудь LINK, это 3 года и 9.5 месяцев, сделок примерно 150 (±). Один сетап и 15000 рассчитывается сильно по-разному, зависит от конфигурации компа напрямую!
1) на core i3-13XXX один сетап считается около 20 секунд, и расчет не тупит пока нагрузка не превышает запущенных задач до 3 шт., дальше 100% загруз и замедляет частоты.
2) на core i7-13XXX уже 12 секунд на тот же сетап и задачек можно запустить до 7-8 штук без потери времени на каждую. Ну то есть они конечно суммируются, и при 7 запущенных бэктестах сетап считается не 12 секунд, а примерно 80 сек., но так как их запущено 7, то на 1 получается примерно то же самое.
3) а вот на камне i9-14900 один сетап считается уже за 9 секунд, а не за 12, и нагрузку камень тянет в 13 задач!

Это то, на чем я уже считал и фиксировал быстродействие. Горизонты обсчета параметров можно сильно расширить.

Как будет на Go — не знаю. БТ в планах пока. Может скормить код ИИшке и попросить переделать его в многопоточный режим? Посмотрим. Пока я ботом занят. Ну вот… Примерно так. Спасибо за добрые слова!

 

avatar
ADT, если вы можете несколько задач запускать, то зачем вам потоки — по сути вы руками потоки запускаете. С матрасчетами очень все зависит от используемого алгоритма. Иногда есть приемы, которые позволяют их ускорять на несколько порядков. Плюс в современных процессорах есть так называемые векторные инструкции, когда процессор делает одновременно несколько похожих операций (например, если в процессоре есть AVX-512 может 16 одновременно). Хорошие библиотеки для математических операций прокручивают оба этих приема, но руками это самому не удастся написать. Плюс есть вариант на GPU расчеты перекинуть. Но Go под это все не предназначен — это не язык для расчетов. Он прежде всего про сетевое взаимодействие — ордеры выставлять, в базу и очереди писать самое то, а для бектестов скорее Python c numpy и pytorch, которые умеют под капотом всякую вычислительную магию делать очень эффективно. Часто для разных задач нужно разное использовать
avatar
ADT, кстати думаю полезно сделать следующий эксперимент — в самое начало функции main() добавить fmt.Println(runtime.GOMAXPROCS(1)). Результате при запуске у вас напечатает во сколько потоков обычно работает программа на Go и переключит Go в работу в одном потоке (на обычном бытовом компьютере там будут что-то около 8-16). Если следовать вашей логике про потоки, то программа должна замедлится в напечатанное количество раз. Но есть подозрение, что вы не заметите сколько-нибудь существенного замедления
avatar

Михаил, да, об этом читал, но пока не применял Пометил себе на будущее попробовать использовать.

СПАСИБО!

avatar
Хоть я и люблю Go, но выбор на мой взгляд странный
avatar
Михаил, аргументируйте.
avatar
ADT, выше написал, где вы на статью сослались
avatar
Здесь явно не ради прибыли и денег трудитесь. Если ради опыта — оставьте надежды переметнуться в ИТ. Наш любимый ГПТ почти закрыл нишу для слабых программистов. Требования ввентил до небес.
avatar
Просто трейдер, я полез в это чтобы сделать то, что наемный программист на пайтоне так и не смог сделать, требуя денег за каждый чих. Его более-менее надежный, но крайне ТУПОЙ по скорости код вызывает удручающее впечатление. А сколько было рекламы, и в итоге пшик. Как говорится: «хочешь сделать хорошо — делай сам!». И на будущее задел хороший, у меня в запасе еще 2 торговые системы есть, которые отлично руками показывают результаты, по ним буду сам писать БэкТесты. Про работу программиста — мысли были, но понимаю что я а) старый, б) только полуджун в) придумайте сами :) но я учусь, с конкретным проектом, а не с помощью онлайн-школы.
avatar
ADT, не знаю ваших конкретных задач но 99% их можно решить на питоне используя numpy и получив скорость не меньше чем вы накодите на go. 

Я не люблю ни питон ни го, но такова истина. 



avatar
Alexs, а для кого истина, не подскажете? И кто её глаголит? Истина, знаете ли, это нечто бОльшее, чем ваши заявления. Без обид.
avatar
ADT, да ну какие обиды.

Конечно это не истина, а моё мнение. Как человека который знает хорошо оба языка (и еще много других). Конечно же вы можете его игнорировать и мне в общем то пофиг.
 
На питоне есть куча инструментов именно для числодробилок. Всякие нейронки и научные вычисления на нем делают. И они наверняка будут работать даже быстрее чем банальный код на go за счет глубокой оптимизации библиотечек.
avatar
__rtx, Да, путь долгий, буду осваивать дальше. Про разводил да, согласен, кругом враги. Поэтому сам. Спасибо за поддержку!
avatar

Читайте на SMART-LAB:
Фото
Норникель - в топ-10 акций портфеля ВТБ Инвестиции
💼На днях в рамках инвестиционного форума ВТБ «РОССИЯ ЗОВЕТ!» команда аналитиков ВТБ Инвестиции представила свою обновленную стратегию на рынках...
Фото
2025 – год трансформации и развития компетенций
За последние 3 года к Софтлайн присоединились порядка 20 компаний , которые расширили наш портфель мощными компетенциями — от ИИ и робототехники...
Фото
Коммерческий директор «Озон Фармацевтика» о доверии к отечественным производителям
🔍 В интервью для Российской ассоциации аптечных сетей коммерческий директор «Озон Фармацевтика» Ольга Ларина поделилась мыслями о...

теги блога ADT

....все тэги



UPDONW
Новый дизайн