Нет, речь пойдет не про высокочастотную торговлю на бирже, но я буду использовать аналогию, чтобы стало понятно почему и как я думал. Собственно, мое мнение HFT прошел полный путь холодной войны. Изначально суть высокочастотной торговли заключалась в алгоритмах, они должны были быть достаточно простыми и при этом максимально эффективными. Выигрыш получал тот, кто успел «просчитать» быстрее других. Сначала это были секунды, потом доли секунд и в итоге алгоритмы начали зашивать в процессоры сетевых карт, чтобы максимально быстро реагировать на входящие данные и генерировать нужные сделки. На настоящий момент можно признать, что этот способ заработка практически умер, поскольку у всех приблизительно одна скорость обсчета и генерации, а следовательно результат начал зависеть от непредсказуемых факторов — по сути рулетка. Где сейчас живет HFT правильно, он ушел в более сложные FPGA и арбитраж на десятки бирж. Алгоритмы стали значительно сложнее, разнообразней и ушли от простых формул с простыми решениями.

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

Для начала рассмотрим как обстояли дела в прошлом, скажем честно очень недалеком прошлом, буквально вчера...

У нас есть разработчик который пилит какой‑то сервис, для нас сейчас не столь важно какой, но пусть это будет FTP‑сервер, тем более что это близко к тому что творилось в wuftp в недалеком прошлом. Разработчика будут звать Роб, вполне себе разработческое имя. И он пилит его не тяп‑ляп, а нормально. Тестирует все что может, старается оберегать свое детище от взломов, переполнений и при этом сохранить скорость и вменяемый размер.

В далеком 2010 году я решил вступить в партию GameDev ибо на рынке было глухо средь космических стратегий. Знаменитый СтарКвейк на стратегию никак не тянул, в сети главенствовал Огейм и его бесчисленные клоны. Но три ископаемых и достаточно простенький вариант развития колоний давил на меня отсутствием реалистичности. Немного пройдясь по гитхабам было решено писать с нуля.

Вариантов на тот момент особо не было, фронт на Flash бэк на PHP + MySQL - классика того времени. Писалось в одно лицо с привлечением художника и дизайнера, за что им бесконечное спасибо! Проект сначала жил на моем ноутбуке, затем на скромном VPS и под конец перебрался на качественный дедик в хецнере (да, были времена : ) с кучей ядер, памяти и диска. В период расцвета онлайн был 100-150 игроков. Но, как обычно, донат начал снижаться, и когда проект перестал оплачивать сервер я подождал пару лет и понял что "лошадь умерла, можно с нее слезать"

Параллельно проект ушел в 2019 на гитхаб, где был доступен абсолютно всем вплоть до недавнего времени. Единственная проблема - бэкап БД не уцелел, точнее уцелела версия 2012 года, в которой много чего не хватало.

Примерно месяц назад мне закралась мысль, а почему бы не использовать курсор для реанимации БД, ну он же может пройти по коду и все вернуть как надо? Оказалось может...

И тут все понеслось... Сначала мы разобрали исходники Flash и перепилили фронт, потом добили в БД то, чего не хватало, затем обработал напильником все картинки и "мультики", стараясь не уничтожить геймплей. Переработали ископаемые и элементы, все же 60 ископаемых оказались оверкилом. Поправили баланс кораблей и колоний...

Давайте попробуем еще раз, в прошлый раз как-то не задалось, но много воды утекло с тех пор. Проект начался как простой способ "заглянуть в БД сервера" собственно таким он и остается до сих пор. Но по мере развития ИИ в нем появились новые фишки.

Как гласит слоган на главной странице: Panopticum — место, откуда видно всё. Собственно я старался сделать его именно таким, чтобы можно было посмотреть и проверить как можно больше из одного места, желательно с одинаковым интерфейсом.

Сначала я просто начал наращивать количество коннекторов. И если сначала это было четыре вида БД, потом шесть, то теперь это 26 разных БД, логи из Kuberneties и просмотр S3 бакетов.

Приложение тормозит. Где узкое место? Почему растёт память? Есть ли дедлок?

Я написал JavaPerf — MCP-сервер, который даёт ИИ-инструментам прямой доступ к нативным утилитам JDK для профилирования. Без графических интерфейсов, без ручного CLI — только диалог с ассистентом.

В проекте часто бывает некий data-flow, который идет через ETL или даже отдельные серверы обогащения данных. Собственно и наш проект не исключение. Что было нужно? Данные из интернета летят в PostgreSQL, но только если в Redis не валяется хэш таких же. Далее несколько ETL проводит стандартный OLTP - OLAP преобразование и складывает все это в MongoDB — откуда клиент дергает эти данные и сравнивает их со своей PostgreSQL попутно складируя кэш в Redis. Все это периодически летает через RabbitMQ.

Что бесило? DBeaver + MongoExpress + redis‑cli все это в разных местах с разными учетками, экспресс постоянно падал по невыясненной причине, неправильный запрос в редиску подвисал, а затем улетал в космос. Мелькнула мысль: «ну почему никто не написал чего‑то более стабильного и удобного?», — собственно это и стало драйвером выходного дня.

Спасибо древним грекам, над названием долго думать не пришлось: Паноптикум — в оригинале «место откуда видно все», но также «сборище жутких и необычных артефактов».

Собственно дальше все очень просто, можно читать, можно искать, можно обновить отдельную запись (если DevOps разрешит) собственно это не production‑ready софт, а простой и надежный инструмент для QA и разрабов. Примитивная basic‑auth которую обязательно надо прятать под TLS и желательно за корп‑VPN, чтобы только свои могли запороть. Для прода и около можно сделать READ_ONLY — но тут каждый сам решает надо оно вообще ему или нет.

Наконец‑то можно проследить все преобразования данных и найти кто потерялся, можно открывать несколько вкладок, можно давать ссылку на конкретный объект. Ставится самым стандартным образом: берем образ — разворачиваем, ничего необычного.

Началось все весьма прозаично, клиент позвонить к нам в техподдержку и спросил «а как бы мне поставить ваш софт но в другую схему БД». Собственно вопрос проще некуда — мы писали на спринге, а значит лезем в application.yml и ставим схему. Но, клиент не из тупых и уже это попробовал — не сработало.

Начинаем разбираться что сломалось и кто виноват. Первым делом ДевОпс повторяет кульбиты клиента и выдает простой вердикт: «В 151 миграции лажа». Я открываю и: «батюшки родный, да это же лосенок явное указание схемы!»