PostgreSQL 17 vs ClickHouse для аналитики игровых событий — что выбрали и почему?

[alansmit]

Нужен совет по стеку для аналитики live-service игры. Сейчас пишем все игровые события (матчи, покупки, активность игроков) в PostgreSQL 16, но при 50 млн событий в сутки уже начинает тормозить даже с партиционированием по дате и индексами на player_id. Запросы типа «посчитай retention по когортам за последние 90 дней» висят по 30-40 секунд. Смотрим в сторону ClickHouse. Кто переезжал — какие подводные камни, стоит ли оно того?

[k_egor_s]

Переехали с Postgres на ClickHouse два года назад для аналитических запросов, Postgres оставили только для транзакционных данных (юзеры, инвентарь, платежи). Это правильное разделение — OLTP и OLAP смешивать не нужно. ClickHouse на тех же данных что у тебя — когортный retention за 90 дней считает за 1-3 секунды. Но надо понимать специфику: нет нормальных UPDATE/DELETE, схему надо проектировать под запросы, JOIN-ы работают иначе. Если данные append-only — ClickHouse идеален.

[seniorwarlock]

Можешь попробовать сначала TimescaleDB поверх Postgres — это расширение которое добавляет гипертаблицы и column-store. Если у тебя Postgres 17 и команда хорошо знает SQL, это меньший порог входа чем ClickHouse. Для 50 млн событий в сутки TimescaleDB вполне справится, особенно с компрессией (в типичных time-series данных даёт 5-10x сжатие). Я бы сначала это попробовал перед полной миграцией.

[kingcnut]

ClickHouse хорош, но у него есть одна большая боль в мультитенантных сценариях: изоляция между проектами/играми слабая. Если у вас несколько игр на одном кластере — будешь бороться с тем, что тяжёлый запрос одного проекта влияет на другие. Решается через workload management в новых версиях, но не из коробки. Также: репликация и failover требуют ClickHouse Keeper (замена ZooKeeper), это дополнительная инфраструктура.

[quixtar]

Для retention и воронок в геймдеве ещё смотри в сторону Apache Druid или StarRocks. Оба заточены именно под такие задачи. StarRocks в особенности — у него синтаксис почти PostgreSQL, есть нормальные JOIN-ы, и скорость сравнима с ClickHouse. Но это уже совсем другой уровень сложности операционно.

[makler]

Мы в итоге сделали дуальную запись: все события идут и в Postgres (партиционированный, хранится 30 дней для оперативных запросов), и в ClickHouse через Kafka (хранится 2 года для исторической аналитики). Kafka даёт буфер на случай даунтайма ClickHouse. Немного сложнее, зато Postgres не перегружен долгими аналитическими запросами.