Комментарии 6
ClickHouse — конечно быстрый. Но статья (понимаю, что перевод) нацелена на популяризацию clickhousedb_fdw его автором (кстати, что на счёт выброса при Q14?) с явным пренебрежением способностями PostgreSQL:
- никто так не хранит BigData в PostgreSQL, для этого есть расширения TimescaleDB и pg_pathman как раз для хранения больших временных рядов (логи, данные с датчиков, прочие факты во времени и статистические данные).
- индексы тоже можно создавать по разному и разного типа, так что большой индекс btree может вести себя неоднозначно на большой таблице (к примеру, если страницы индекса не помещаются в памяти)
- настройки postgres по умолчанию рассчитаны на "запуск даже на кофеварке", их нужно тюнить, хотя бы с помощью PgTune.
- для выборки агрегированных хитрых значений могут использоваться дополнительные расширения, к примеру, pipelineDB или другие механизмы.
Конечно, ClickHouse быстрый, и чаще всего разумнее будет не париться, а настроить именно его для хранилища больших данных — чтобы настроить postgres для bigdata, нужно потратить прилично времени, чтобы понять для чего и как это делать. Но бывает так, что таковы правила игры (проекта или легаси-инфраструктура), что есть только postgres и ничего другого быть не может).
Было бы здорово увидеть сравнение этих монстров не "из коробки", а на максимуме своих возможностей)) вот это был бы обзор. В статье есть ссылка на исходный датасет. Если у кого-то дойдут руки до сравнения — то это будет хороший материал для статьи!
TL;DR — ClickHouse будет "как тузик грелку" PostgreSQL во всех своих целевых сценариях использования, ибо именно для этого CH был сделан. Т.е. чем ближе совокупность "данные + запросы" к назначению CH, тем ближе буду результаты сравнительных бенчмарков с PG к "как тузик грелку" (в два и более раз).
Такое моё утверждение может показаться слишком сильным и категоричным, но чем больше кто-либо будет погружаться во внутреннее устройство PG и CH, тем больше будет соглашаться. Причем это нисколько не принижает достоинства PG, просто не каждым микроскопом удобно забивать шурупы ;)
Если совсем грубо и коротко, то в своих целевых сценариях CH почти не делает лишнего и очень эффективно использует железо (SIMD, последовательное чтение, сжатие и т.п.). В таких сценариях Постгресу (мягко говоря) крайне сложно тягаться с CH, оставаясь при этом именно Постресом (сохраняя ACID поверх MVCC путем COW/ShadowPaging). Со стороны CH при этом отсутствуют транзакции и удаление/изменение данных в привычном для PG понимании. Т.е. CH тут быстрее, в частности, потому что много не позволяет.
Какого-либо пренебрежения к "возможностям PG" я не вижу. Точнее говоря, в моем понимании, посыл автора не в "принижении PG", а в демонстрации возможностей FDW. Другими словами, главным я вижу не "насколько PG медленнее CH" (в целевых для CH сценариях это неизбежно), а то что Clickhousedb_fdw позволяет через готовый PG-интерфейс (ODBC и т.д.) в дополнение к PG получить также и часть мощности CH. Причем во многих случаях с относительно небольшой наценкой.
Проседание Q14 показывает текущее положение дел в Clickhousedb_fdw, т.е. не готовность к production. Грубо говоря, Clickhousedb_fdw (пока) умеет "перебрасывать" на сторону CH только относительно простые join-ы (complex join pushdown NOT supported).
Поэтому, чуть более сложный join будет выполняться на стороне PG. Другими словами, если Clickhousedb_fdw не полностью справляется с трансляцией запроса, то сначала будут выполнены подзапросы на стороне CH, затем эти данные будут загружены внутрь PG и уже после будут join-ится. Проседание Q14 как раз хорошо показывает последствия.
Реализация complex join pushdown сводиться к волокитной трансляции из PG-диалекта SQL в CH-SQL. Это местами очень занудная, а местами нетривиальная задача. Причем если делать по-хорошему, то следует обеспечить разумно-оптимальную трансляцию "экс-территориальных" join-ов, когда в одном запросе используются как таблицы из CH, так и из PG, а желательно и из другого FDW. Короче, пока ребята из Percona это отложили, и (мне) понятно почему.
Статья перевод. На счет Q14 от себя ничего не могу сказать.
- Никто так не хранит BigData в PostgreSQL. Не обязательно должна быть BigData. Я в одной команде в живую видел как делали аналитику на чистом PostgreSQL. На счет TimescaleDB согласен, если там временные ряды. Но логи врят ли могу назвать временными рядами. Для данных с датчиков лучше использовать Prometheus/VictoriaMetrics
2-3-4 Согласен
Вы же можете сделать сравнение ClickHouse и PostgreSQL на максимуме своих возможностей. Сообщество будет вам благодарно.
Вчитался в каждый запрос, но, увы, нет ни одного, который бы был вызовом для планировщика. А полтора года назад он был никакой и умел только банальные групбаи быстро считать, и сваливался в 1 поток, как только надо было двинутся на шаг вперёд.
Интересно, с того времени изменилось что-то? Есть ли бенчмарки СН на реально сложных запросах?
Тестирование производительности аналитических запросов в PostgreSQL, ClickHouse и clickhousedb_fdw (PostgreSQL)