ClickHouse vs PostgreSQL для аналитики — когда уже пора переезжать?

[ivan_omega30]

У нас аналитические дашборды на PostgreSQL, таблица событий растёт на ~50 млн строк в день. Агрегации по неделе уже считаются минутами даже с партициями. Стоит тащить ClickHouse или можно ещё выжать что-то из постгреса?

[svetlana_js]

50 млн в день и агрегации по сырым данным — это прям классический сценарий для колоночной БД. Постгрес тут не его лига, ClickHouse сожрёт это и не заметит. У нас похожие объёмы летают за доли секунды.

[dnscache8196]

Не торопитесь. Сначала попробуйте предагрегаты через materialized views или timescaledb continuous aggregates. Если дашборды смотрят агрегаты, а не сырьё, может и переезжать не надо, инфраструктуру плодить тоже стоит денег.

[sonya2557]

ClickHouse рулит, но имейте в виду: UPDATE/DELETE там боль, нет полноценных транзакций, и JOIN большой таблицы с большой — отдельный навык. Если данные иммутабельные event-логи, идеально. Если надо часто править — подумайте.

[go_gopher]

Данные реально append-only, события не меняются. JOIN-ы есть, но в основном с маленькими справочниками.

[dnscache8196]

Тогда твой кейс прям эталонный. Маленькие справочники держи как dictionary в ClickHouse, JOIN с ними почти бесплатный. MergeTree + правильный ORDER BY ключ — и забудешь про минутные запросы.

[nastya_sql]

Только не поднимайте ClickHouse кластер руками на старте, если команда маленькая. ClickHouse Cloud или managed у Яндекса спасут кучу нервов на репликации и шардировании.

[natalia2402]

Принято, делаем PoC на одной ноде с managed, заливаем месяц данных и сравниваем. Если взлетит — шардируем потом. Спасибо всем!

[alina_msk]

А есть смысл это делать в проде или только для локалки подходит?

[tanya_loop67]

Сделал по гайду, всё ок. Единственное — версию пакета пришлось зафиксировать.