Как мы переехали с PostgreSQL на ClickHouse — и госзакуп-аналитика начала летать

Коротко для тех, кто спешит

1. Что это вообще такое, на пальцах

Представьте обычную базу вроде PostgreSQL как толстую тетрадь, где данные записаны по строкам: одна строка — один лот, и все его поля (номер, заказчик, сумма, дата, статус…) лежат рядом, одной записью. Удобно, когда нужно достать или поправить одну конкретную запись целиком. Но когда ты хочешь просто сумму по одной колонке за год, приходится пролистать каждую строку целиком — вместе со всеми ненужными полями.

ClickHouse хранит данные по колонкам: все суммы лотов лежат подряд в одном месте, все даты — в другом, все имена заказчиков — в третьем. Нужна сумма по одной колонке — ClickHouse читает только её, а не всю таблицу. Плюс есть бонус: значения одного типа, лежащие подряд, жмутся в разы лучше, чем перемешанные поля строки. Отсюда вся магия — меньше читаем с диска, значит, быстрее отвечаем. Это и называется колоночной базой данных (хороший разбор темы есть и у MotherDuck, и у Fivetran).

Конкретный пример из моей боевой таблицы лотов (31,4 млн строк, 5,9 ГиБ). Один и тот же GROUP BY: если запросу нужны только 2 числовые колонки, ClickHouse читает с диска 330 МиБ вместо 5,9 ГиБ — примерно в 18 раз меньше. Строчной базе в любом случае пришлось бы поднять строки целиком.

2. Вчера опенсорс, сегодня компания за $15 млрд

Мне нравится эта история, потому что она про силу простой идеи. В 2009 году инженер-математик Алексей Миловидов в Яндексе затеял эксперимент: можно ли строить аналитические отчёты в реальном времени прямо из сырых, неагрегированных данных, которые к тому же постоянно доливаются. Три года он доказывал гипотезу — и в 2012-м ClickHouse пошёл в прод как движок Яндекс.Метрики, второй по величине системы веб-аналитики в мире.

В июне 2016-го проект открыли под лицензией Apache 2. В сентябре 2021-го из него выросла отдельная компания ClickHouse Inc. в Сан-Франциско (основатели — Aaron Katz, Alexey Milovidov и Yury Izrailevsky; стартовые $50 млн дали Index Ventures и Benchmark, среди участников был и Яндекс). А в январе 2026-го ClickHouse привлёк $400 млн при оценке $15 млрд (раунд Series D во главе с Dragoneer) — вдвое больше, чем годом раньше ($6,35 млрд в мае 2025). Всего компания подняла более $1 млрд.

3. Честно: это не замена PostgreSQL

Скажу прямо, потому что сам долго думал, что выбрать под свой агрегатор. Главное, что я понял: ClickHouse — это НЕ замена PostgreSQL, это другой инструмент под другую задачу. Это не «лучше/хуже», это «для разного».

Разницу OLTP vs OLAP проще всего запомнить так: OLTP — это «много мелких операций над отдельными записями» (банкомат), OLAP — «одна тяжёлая операция над всей историей» (годовой отчёт). ClickHouse не нужен, если данных мало, и он не про частые точечные апдейты.

4. Наша схема: 781 млн строк на одной VPS

Теперь как это выглядит у меня в бою. Мы парсим официальный API goszakup.gov.kz (плюс Самрук, казначейство, планы). Раньше сырьё было в PostgreSQL, и аналитика упиралась в полные сканы и тяжёлые GROUP BY. Сейчас всё в ClickHouse, организованном как многослойная (medallion) ELT-архитектура — сырьё очищается и превращается в витрины слой за слоем:

Ключевые таблицы — вот из чего складываются эти 781 млн строк и 192 ГиБ. Обратите внимание на движок: MergeTree для стабильных данных и ReplacingMergeTree там, где ETL постоянно доливает новые версии строк.

5. Железо и конфигурация

Никакого кластера. Одна машина. Вот вся правда о железе:

ОС — Ubuntu 24.04 LTS, ClickHouse 25.12 под systemd, аптайм на момент замеров — 4 недели. Главный нюанс: сервер «горячий» — рядом на этой же машине молотит Python-ETL, который тоже хочет память. Поэтому я подрезал ClickHouse, чтобы он не съел всё под кэши и не подрался с ETL за RAM:

<!-- /etc/clickhouse-server/config.d/memory.xml -->
<clickhouse>
    <!-- не забирать под сервер больше 60% RAM: рядом работает ETL -->
    <max_server_memory_usage_to_ram_ratio>0.6</max_server_memory_usage_to_ram_ratio>

    <!-- кэш засечек (primary index marks) -->
    <mark_cache_size>5368709120</mark_cache_size>        <!-- 5 ГиБ -->

    <!-- кэш распакованных блоков -->
    <uncompressed_cache_size>8589934592</uncompressed_cache_size>  <!-- 8 ГиБ -->
</clickhouse>

И ещё одна деталь, которая и даёт «полёт»: max_threads = auto(16). По умолчанию каждый запрос параллелится на все 16 ядер — одинGROUP BY раскладывается на 16 потоков и молотит данные векторно, блоками. Отсюда и сотни миллионов строк в секунду на одной VPS.

6. Два козыря: сжатие и column pruning

Козырь №1 — сжатие 4.8×. 355 ГиБ логических данных превращаются в 74 ГиБ на диске. Колоночное хранение + кодек LZ4: значения одного типа лежат подряд и жмутся кратно лучше, чем перемешанные поля строки. Меньше читать с диска = быстрее запросы. Это ровно то, за что колоночные базы обгоняют строчные на аналитике.

Козырь №2 — column pruning (читается только нужное). Один и тот же GROUP BY по таблице лотов (31,4 млн строк, 5,9 ГиБ), но с разным набором колонок:

Строчный PostgreSQL в обоих случаях поднимал бы строки целиком — а значит, «дешёвый» запрос на 2 колонки стоил бы ему столько же, сколько «дорогой». В этом и вся разница.

7. Живые бенчмарки

Все замеры — на боевом сервере, во время работающего ETL. Никаких синтетических датасетов, только продовые таблицы. Начнём с классики — годовая динамика по 31,4 млн лотов:

SELECT
    toYear(tender_publish_date_day) AS y,
    count()                         AS lots,
    round(sum(lot_amount) / 1e9, 1) AS bln_tenge
FROM goszakup_dmrt.lots
GROUP BY y
ORDER BY y DESC;

-- 2025: 3 869 168 лотов / 15 750 млрд ₸
-- 2024: 3 694 027 лотов / 15 910 млрд ₸
-- 2023: 3 910 433 лота  / 12 150 млрд ₸
-- ⏱ 0,08 с · 31,4 млн строк · 378 млн строк/сек · 3,9 ГиБ/сек

Дальше — топ-10 заказчиков по сумме лотов. Тут в GROUP BY уходит длинная строка (имя заказчика), поэтому чтение тяжелее, но всё равно доли секунды:

SELECT
    customer_name_ru,
    round(sum(lot_amount) / 1e9, 0) AS bln_tenge
FROM goszakup_dmrt.lots
GROUP BY customer_name_ru
ORDER BY bln_tenge DESC
LIMIT 10;

-- АО «НК ҚазАвтоЖол» ................. 3 805 млрд ₸
-- КГУ «Управление строительства
--     г. Алматы» ..................... 2 538 млрд ₸
-- МЧС РК ............................. 1 584 млрд ₸
-- ⏱ 0,46 с · 31,4 млн строк · 69 млн строк/сек

А вот полнотекстовый поиск честным полным сканом — ILIKE '%компьютер%' по 31,4 млн названий лотов, без всякого индекса:

SELECT count()
FROM goszakup_dmrt.lots
WHERE lot_name_ru ILIKE '%компьютер%';

-- 191 310 совпадений
-- ⏱ 0,32 с · полный скан 31,4 млн строк · 98 млн строк/сек

Сводка по пяти боевым запросам — агрегация, top-N по строке, сумма платежей, JOIN двух больших таблиц и полнотекстовый скан:

8. Почему это вообще работает — 4 причины

Именно четвёртый пункт и был для меня главной причиной ухода с PostgreSQL в самом пайплайне: ReplacingMergeTree заменил всю возню с INSERT ... ON CONFLICT и блокировками на апдейтах. А общий выигрыш по скорости на аналитике для колоночных баз хорошо известен — они и считаются самыми быстрыми под аналитику именно за счёт трёх множителей: сжатие в 5–10 раз, сокращение I/O на 90%+ на широких таблицах и векторизованное выполнение.

9. Как повторить у себя — просто скопируй промпт

Не обязательно быть дата-инженером. Если у тебя есть данные в PostgreSQL (или обычные csv/excel-файлы) и тормозящая аналитика — просто открой Claude Code (или Cursor) в папке проекта и скопируй промпт ниже. Агент сам поставит ClickHouse, сам перельёт туда данные и покажет, стало ли быстрее. От тебя — один клик «Копировать» и один ответ на вопрос агента, где лежат данные.

Ты — мой дата-инженер. Объясняй всё ПРОСТО, шаг за шагом, без жаргона.
Задача: ускорить мою аналитику, переехав на ClickHouse. Сделай всё сам.

ШАГ 0 — ДАННЫЕ.
Мои данные лежат здесь: <PostgreSQL-строка подключения ИЛИ путь к csv/parquet/xlsx>.
Если я не указал — поищи сам в текущей папке и стандартных местах (Desktop,
Downloads) csv/parquet/xlsx или локальную базу Postgres. Если ничего не нашёл —
просто спроси меня, где данные и что я обычно по ним считаю.

ШАГ 1 — ПОСТАВЬ CLICKHOUSE ЛОКАЛЬНО.
Установи ClickHouse самым простым способом для моей ОС
(на Linux/Mac: curl https://clickhouse.com/ | sh, затем ./clickhouse server;
на Windows — через Docker: docker run -d --name ch -p 8123:8123 -p 9000:9000
clickhouse/clickhouse-server). Проверь, что сервер поднялся, и покажи мне команду
подключения (clickhouse-client).

ШАГ 2 — ПЕРЕЛЕЙ ДАННЫЕ.
Создай таблицу с движком MergeTree под мои данные (сам подбери типы колонок и
разумный ORDER BY — обычно это дата или id). Если данные обновляются по ключу —
используй ReplacingMergeTree вместо UPSERT. Залей мои данные в ClickHouse.

ШАГ 3 — ЗАМЕРЬ «БЫЛО / СТАЛО».
Возьми 3-4 моих типичных аналитических запроса (агрегации, GROUP BY, суммы по
периодам, топ-N, полнотекстовый поиск). Прогони их и в старой базе (если это
Postgres), и в ClickHouse. Замерь время каждого. Покажи размер данных на диске
до и после (у ClickHouse он будет в разы меньше из-за сжатия).

ШАГ 4 — ВЕРДИКT (просто и по-человечески):
  • Насколько быстрее стало (во сколько раз), таблицей «запрос / было / стало».
  • Сколько сэкономили места на диске.
  • Стоит ли мне переезжать на ClickHouse ПОЛНОСТЬЮ или держать его рядом с
    Postgres только под аналитику. Ответь прямо: ДА или НЕТ и почему.

ВАЖНО помни: ClickHouse — для аналитики (много чтения, отчёты, дашборды), а НЕ
для транзакций и частых точечных апдейтов — их оставь Postgres. Если данных мало
(меньше пары миллионов строк) — честно скажи, что ClickHouse мне пока не нужен.

Итог

Одна VPS за копейки, 16 ядер, ноль шардов — и интерактивная аналитика по сотням миллионов строк госзакупок РК. Для аналитической нагрузки (много чтения, агрегации, полные сканы, редкие точечные апдейты) ClickHouse обходит классический PostgreSQL не на проценты, а в разы — и ещё экономит диск за счёт сжатия.

Но помню и повторю: это OLAP-инструмент. Для транзакций, точечных апдейтов и консистентности каждой записи оставляй PostgreSQL. А если данных реально много и нагрузка аналитическая — бери ClickHouse, накатывай MergeTree-схему слоями, и твоя аналитика тоже полетит. Проверено на 781 млн строк.