Comments 8
Интересно ваше мнение о clickhouse против pg — заточенного под быструю вставку. Например таблицы в pg можно сделать узкими, разбить на партиции и использовать компактный brin index. Будет ли click house выигрывать и за счёт чего?
В общем если у вас OLTP нагрузка PG хорош, для OLAP можно использовать только на небольшом кол-ве данных, с млрд. строк и ТБ данных будет плохо.
И кстати, а как вам помогут узкие таблицы? Это такой суррогат для замены широкой колоночной таблицы? )
Вот я и пытаюсь понять почему будет плохо. Clickhouse, насколько я понимаю, хорош за счёт быстрого сканирования таблицы. Для этого он сжимает данные, имеет своеобразные «неточные» индексы и хранит данные колонками, а не рядами.
Насколько я понял, партицирование не подойдёт, потому что тысячи партиций это плохо. Но, теоретически, можно свести аналитический запрос к нескольким index only scan. Думаю 5-10 миллионов строк в секунду так можно сканировать, даже на desktop железе.
В общем, хочется разобраться чего такого clickhouse делает, чего pg точно не сможет и для чего нормальной имитации тоже не сделать или сделать, но слишком муторно. С точки зрения стороннего наблюдателя, кажется нужно (и можно) pg заставить последовательно сканировать узкую таблицу/индекс и тогда скорость будет аналогична CH.
А аналитику нельзя свести к нескольким полям, там как там нужны данные по многим полям, иногда даже по всем. Postgres хорошая БД, и она хороша в большинстве случаев, не зря же в её пользу отказываются от Oracle. Но есть случаи когда её возможностей не хватает даже используя разные расширения. Поэтому и создали другие БД для работы с большими данными, аналитикой, и так называемой Big Data и Data Science.
А вообще можете генерировать данные для узких таблиц в Postgres, и сравнить с KH по производительности.
Потом напишите статью на хабре )
Для увеличения шансов postgresql можно добавить еще timescaledb extention, но он не сильно поможет.
А если отвечать серьезно, то за счет сжатия данных, параллельном исполнении запросов, поколоночном хранении данных, удобном партицировании.
Но речь конечно идет о тех нагрузках, под которые оптимизирован clickhouse: относительно редкие запросы которые затрагивают сразу большой объем данных.
Дергать значения по ключу скорее всего postgresql будет быстрее.
На вставке с ним может InfluxDB соперничать. Ну и может TimescaleDB, но сомневаюсь.
CH молодой продукт и с 2018 довольно сильно изменился. Поэтому ценность статей двухлетней выдержки не очень высока на мой взгляд...
Что нужно знать об архитектуре ClickHouse, чтобы его эффективно использовать. Алексей Зателепин (2018г)