Оказывается у меня Twir всё же имеет какой-то кастомный статус на твиче.

На него нельзя warning накинуть, и он может писать в followers-only чат.

Хммм, получается всё таки какие-то скрытые фильтры у них есть, которые бог есть как работают.
Может и банов больше не будет акка бота?

Коллаба века.

https://www.youtube.com/watch?v=KEMVgy51kPE

Так как вы донатите чутка больше, чем надо на сервера — включил acrcloud для определения музыки в твире, чтобы лучше детектил музыку со стрима без подключения сторонних интеграций по типу vk, last.fm, spotify.

Посмотрим сколько за месяц накапает в биллинг.

C.A.2K - Factory
Deezer | SoundCloud | Yandex Music | Spotify | YouTube Music | YouTube | Apple Music | Tidal

https://youtu.be/DHA_HuGA-Mc

Какой шедевр, я не могу.

Легендарная crowd (я не знаю как на русском так же ёмко сказать).

Хайлоад. 😄

Это я попросил человека нафлудить 60к сообщений в чате твича, и у меня 1.7кк запросов к редису на это тригерится, и 60к+ к постгресу.

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

Оч доволен тем, как побустил перформанс. Это всё происходит на shared vcpu виртуалках от хетзнера с 4мя ядрами. Думаю с dedicated или просто большим кол-вом ядер — было бы ещё больше по запасу ресурсов.

А теперь чутка детальнее.

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

🤯 Проблема

Есть такие ребята, которые просто флудят смайликами, сообщениями, наградами — чтобы накручивать активность в сторонних сервисах (типа StreamElements).

Один из таких товарищей недавно отправил ~3 млн запросов. В итоге:

- traefik лёг
- postgres задохнулся
- система трижды падала

🛠 Что сделал для улучшения:

- Свап traefik → haproxy в критичных местах (EventSub webhooks)
Почему Haproxy?
1. без GC
2. без компрессии
3. стабилен под нагрузкой (написан на C)


- Добавил batch-сохранения в базу
1. Раньше: один INSERT на каждое сообщение.
2. Теперь: всё уходит в очередь и раз в X мс заливается в базу одной пачкой через COPY.

Своя либка под это:
👉 https://github.com/twirapp/batch-processor

- Кэширование READ-запросов через Redis
Написал обёртку GenericCacher, которая кэширует по ключу, TTL и умеет делать invalidate. Если в кэше данных нет — вызывается LoadFn, и данные записываются в кэш.
🧱 Пример использования:

c.channelsCache.Get(ctx, channelId)
c.channelsCache.Invalidate(ctx, channelId)

Создания:

go
c.channelsCache = generic_cacher.New[channelmodel.Channel](
  generic_cacher.Opts[channelmodel.Channel]{
    Redis:     redis,
    KeyPrefix: "cache:twir:channel:",
    LoadFn:    repo.GetByID,
    Ttl:       24 * time.Hour,
  },
)

✅ Результат:

Теперь даже при диком флуде — система не ложится.
Нагрузка снижена, всё живёт.
Да, редис стал принимать на себя на порядок больше, но за-то теперь нагрузки более правильные что-ли, бот даже не теряет во времени ответа на команды в моменте оверлоада системы.

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

Есть тут кто по ИП работал?

Хочу вас вопросами подоставать.

https://t.iss.one/savdevops

Канал моего друга, червечка-девопсера.

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

Пока постов не много, но человек дал кровную клятву развиваться.

На правах антирекламы ерид 133722888005553535.

Ладно, давайте так — за каждого подписчика увеличиваю время некст стрима на 20 минут.

✨ Добавил ClickHouse в twir.app! 🚀

Пока записываю туда только:
- сообщения с чата

- использование команд
Что дало:
1. почти моментальный count() квери.

- использование смайликов
Что дало:
1. почти моментальный count().
2. меньший размер таблички.
3. быстрое аггрегирование таймсерии для смайлов, для года данных — 30мс с клиента, а это значит общее затраченное время на запрос, нетворк раундтрипы, скан, вообщем весь цикл.
4. быстрая выборка топа, истории.

Есть ещё что туда писать, но пока не переделывал.

Подтюнил конфиг чтобы не писалось гигибайты логов, а то на работе есть некоторые таблички логов, которые вестя 70гб. Можно было бы просто выставить ttl, но мне пока эти данные не нужны.

Так же человек с чата подсказал на счёт того, чтобы для колонок использовать тип данных LowCardinality(String) на часто повторяющиеся строки, что уменьшило их размер на диске в разы. Не знаю даёт ли это что-то в перформансе.

Мигрировал данные из постгреса очень легко, просто выполнил:

INSERT INTO chat_messages
SELECT *
FROM postgresql('postgres:5432', 'twir_prod', 'chat_messages', 'twir', 'twir');

INSERT INTO channels_emotes_usages
SELECT id, "channelId" as channel_id, "userId" as user_id, "createdAt" as created_at, emote
FROM postgresql('postgres:5432', 'twir_prod', 'channels_emotes_usages', 'twir', 'twir')

Так как clickhouse очень быстрый, 13млн записей загрузилось что-то типо за 2 секунды.

Пока ограничил ему 2cpu и 3GB ram, что коненчо же смешно для клика, но больше гига оперативы он не потребляет на моих размерах.

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

Прикрутил opentelemetry к клиенту клика, могу видеть query, их время.

С метриками чутка пришлось повозиться, потому как из коробки клиент не имеет инструментария внятного, но всё же всё работает как я хочу.

Даже для batch запросов могу видеть сколько rows было внесено.

Ещё из прикольного — у меня для создания\запуска миграций используется собственная cli.

Докинул туда clickhouse, и теперь одним и тем же способом могу создавать\запускать миграции для этих бд.

Отвечая на вопрос вообще ПОЧЕМУ было принятно решение мигрировать эти данные из postgres:

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

Вторая
Я просто хочу чуть глубже поиспользовать ClickHouse. Twir всегда был тем проектом, где я обкатываю технологии для себя, если нахожу им пременением. Мне кажется тут хорошее применение.

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