Обновить

Комментарии 16

Зачем вкатываться в Clickhouse при живом Postgres-е?

Я извиняюсь , а вы статью читали? )

Postgres — OLTP база, Clickhouse — OLAP. Это разные БД для разных задач.

Ну так все равно- зачем КХ для хранения котировок? Мне тоже не очень понятно.

Расскажите пожалуйста, как вы вообще пришли к необходимости КХ?

Я занимаюсь примерно таким же анализом, что описывается у вас- моя бд наверняка не такая большая как у вас- всего 638 ГБ, 2.52 млрд строк. Крутится под MariaDB пятилетней давности на достаточно слабой машине бытового уровня. Вопрос- зачем вам КХ? Я не ёрничаю, я реально хочу понять на каких задачах вам начало не хватать постгреса?

Вопрос хороший, спасибо. По поводу, как КХ появился у нас – так исторически сложилось. То есть пример "было так, не устраивало вот это - перешли на КХ" – привести не смогу.

У нас не только хранение котировок, а всевозможные агрегаты по этим данным (свечи разных интервалов, объемы торгов в разных разрезах, исторические параметры в разных разрезах и всякие такие штуки). Наверное, можно сделать это разными способами на разных БД, но в долгосрок OLAP БД тут выиграет.

Приведу один пример – объем хранилища (и зависящая от этого скорость выполнения запросов). В КХ данные хранятся по столбцам, в Postgres – по строкам. Если данные хранятся по столбцам, то КХ их эффективно сжимает – разница может в несколько раз быть, тк. LZ4/ZSTD хорошо работает на повторяющихся данных. Вот тут подробнее можно почитать https://clickhouse.com/docs/data-compression/compression-in-clickhouse У вас как данные хранятся, по столбцам или по колонкам?

Спасибо за ответ!

У вас как данные хранятся, по столбцам или по колонкам?

В mysql обычное строчное хранение.

А кроме уменьшения объема какие есть еще преимущества столбчатого хранения?

И если позволите нескромный вопрос- если не секрет- большая у вас команда? И что вообще за команда- вы есть в публичном поле? Хотел бы почитать про вас.

Успехов в Новом году!

А кроме уменьшения объема какие есть еще преимущества столбчатого хранения?

Сильно быстрее запросы, т.к. читать нужно меньше с диска: (1) данные по колонкам хранятся, то есть чтобы SUM(amount*price) сделать, БД отдельно читает 2 колонки, а не все строчки в случае построчного хранения (2) колонки сжаты по умолчанию LZ4/ZSDT кодеком, что тоже уменьшает объем считываемых данных.

По скорости тут кто-то бенчмарки проводил https://www.fiveonefour.com/blog/PostgreSQL-vs-ClickHouse

И что вообще за команда- вы есть в публичном поле? 

Да, работаю в одной из tier-1 команд в блокчейн данных и индексинге – если перейти в профиле в ТГ/Твиттер, можно инфу найти, тут не буду рекламировать )

Вам тоже огромных успехов!

Дополню, возможно, это не совсем понятно из текста. Мы не используем КХ для всего, только для вышеперечисленных задач аналитики и агрегации. Постгрес у нас тоже есть, но для транзакционных данных – юзеры, тарифные планы, статусы воркеров / задач и т.п.

Добавил в начало статьи немного конкретики про сжатие.

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

Под операционку все же нужна постгря и условный redis

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

Да, CH — это про аналитику. Ну мы его так используем. Там есть еще Log engine как раз для логов , но я его не использовал.

Log, как ни странно, не для логов - это скорее как временные маленькие таблицы. Для логов обычные *MergeTree, плюс можно пробовать всякие новые фичи типа полнотекстовых индексов.

Спасибо за уточнение!

Бесплатный мониторинг от nginx amplify отключается 31 января 2026 , поэтому пришлось настраивать другое решение.

Использую clickhouse для хранения веб логов nginx, отлично справляется. Поставил TTL 2 года для хранения записей.

В nginx настроил расширенные логи с geoip, статистика по ASN, странам.

Связка такая:

nginx -> vector (vector.dev ) -> clickhouse -> grafana

  1. nginx сохраняет логи в файл

  2. vector читает файлы логов и отправляет в clickhouse.

  3. grafana читает из clickhouse и отображает dashboard с необходимыми параметрами.

Огромный плюс в том, что можно построить любой dashboard в grafana, намного стало больше возможностей, чем просто с nginx amplify.

Автоматически выявляю ботов и подозрительные ASN.
Вижу замедления http запросов по каждому uri path и бэкенду.

По размеру данных:

100 млн строк расширенных логов nginx ≈ 6.2 ГБ хранилища clickhouse.

Конкретно под логи и их аналитику очень советую.

Пушка, спасибо за идею!

Тоже так делаю, только nginx в vector передает логи через syslog:unix-socket чтобы совсем уж быстро.

Ничё не понял, но тоже за компанию поставлю лайк и скажу, что идея бомба!

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации