то есть стоит под эти данные держать отдельно mysql?

угу.

$ tail /var/log/clickhouse-server/clickhouse-server.log
2020.05.26 16:52:36.687968 [ 15 ] {} <Debug> projectname.impressions (MergerMutator): Merging 2 parts: from 202005_3224258_3230563_5243 to 202005_3230564_3230564_0 into tmp_merge_202005_3224258_3230564_5244
2020.05.26 16:52:36.688803 [ 15 ] {} <Debug> projectname.impressions (MergerMutator): Selected MergeAlgorithm: Horizontal
2020.05.26 16:52:36.688852 [ 15 ] {} <Trace> MergeTreeSequentialBlockInputStream: Reading 13 marks from part 202005_3224258_3230563_5243, total 94697 rows starting from the beginning of the part, columns: timestamp, id, impression_name, network_id, offer_id, ad_id, promo_id, merchant, affiliate, utm_source, utm_medium, utm_campaign, utm_term, utm_content, subid1, subid2, subid3, subid4, subid5, subid6, country, traffic_source, af_utm_source, af_utm_medium, af_utm_campaign, af_utm_term, af_utm_content, af_subid1, af_subid2, af_subid3, af_subid4, af_subid5, af_subid6
2020.05.26 16:52:36.689626 [ 15 ] {} <Trace> MergeTreeSequentialBlockInputStream: Reading 2 marks from part 202005_3230564_3230564_0, total 92 rows starting from the beginning of the part, columns: timestamp, id, impression_name, network_id, offer_id, ad_id, promo_id, merchant, affiliate, utm_source, utm_medium, utm_campaign, utm_term, utm_content, subid1, subid2, subid3, subid4, subid5, subid6, country, traffic_source, af_utm_source, af_utm_medium, af_utm_campaign, af_utm_term, af_utm_content, af_subid1, af_subid2, af_subid3, af_subid4, af_subid5, af_subid6
2020.05.26 16:52:36.704694 [ 8 ] {} <Debug> projectname.impression_views (MergerMutator): Merge sorted 42940 rows, containing 34 columns (34 merged, 0 gathered) in 0.03 sec., 1323663.17 rows/sec., 412.98 MB/sec.
2020.05.26 16:52:36.707770 [ 8 ] {} <Trace> projectname.impression_views: Renaming temporary part tmp_merge_202005_3880395_3880986_305 to 202005_3880395_3880986_305.
2020.05.26 16:52:36.707997 [ 8 ] {} <Trace> projectname.impression_views (MergerMutator): Merged 2 parts: from 202005_3880395_3880985_304 to 202005_3880986_3880986_0
2020.05.26 16:52:36.731593 [ 15 ] {} <Debug> projectname.impressions (MergerMutator): Merge sorted 94789 rows, containing 33 columns (33 merged, 0 gathered) in 0.04 sec., 2173338.84 rows/sec., 643.28 MB/sec.
2020.05.26 16:52:36.734150 [ 15 ] {} <Trace> projectname.impressions: Renaming temporary part tmp_merge_202005_3224258_3230564_5244 to 202005_3224258_3230564_5244.
2020.05.26 16:52:36.734377 [ 15 ] {} <Trace> projectname.impressions (MergerMutator): Merged 2 parts: from 202005_3224258_3230563_5243 to 202005_3230564_3230564_0

и что? тут никакой проблемы нет, надо несколько десятков мегабайт лога вокруг ошибки

А в кх имеется поддержка HA режима при работе с hdfs?Если да, то где можно пример рабочий найти?

Насколько оправданно использовать кх в ситуациях , когда туда нужно совершать миллионы запросов в день (селект в одну табл)? Столкнулся с проблемой, что LA вырос до 20-25 на второй день тестов. Первый день ничего не происходило. Выполняя идентичные запросы вручную , отвечают они моментально

кликхаус не очень подходит для высокого кол-ва rps, тк любой запрос это сканирование некоторого диапазона

Выходит всю информацию агрегированную необходимо выносить в mysql( проект на нем )? Ее достаточно много :(

А возвращаются всегда разные данные, или как-то перекрываются?
Я бы партиционировал их по каком-нибудь критерию, типа времени и запрашивал только аддитивно, кусочками

Данные меняются. Там логируется инфа пользовательская, по которой я рассчитываю их процент отклика на рассылки. А так же сколько писем было отправлено за период какой либо

вряд ли это нужно, скорее или запрашивать сразу пачкой если они слишком мелкие, либо что-то неправильно работает и надо подкрутить например block_size или granularity

А где можно почитать про то, под какие нагрузки он подходит? В доках я читал , что для онлайн запросов он годится , но про рпс не нашёл

Пачкой это не совсем подходит кажется, потому что в момент времени расчёт идёт для одного определенного юзера

и что? ну считайте сразу для сотни юзеров

ClickHouse/ClickHouse tagged: v20.4.4.18-stable
Link: https://github.com/ClickHouse/ClickHouse/releases/tag/v20.4.4.18-stable
Release notes:

v20.4.4.18-stable

для сотни юзеров посчитать можно, если эта сотня известна 🙂 но у меня она не известна, либо это накапливать и заставлять очереди ждать

миллион запросов если ровненько разделить на 12 часов, то будет примерно 23 запроса в секунду

в общем я бы для начала посчитал, сколько выполняется 1 средний запрос по времени

запросы по факту отправки делаются, т.е. есть например есть пара рассылок по крону, генерится пачка юзеров большая, например 100К разом кидает их в раббит , в воркерах уже делается запрос в кх. Не только в кх, но и в том числе. Там еще логика есть всякая. Воркеры так устроены, что задание обрабатывает одного конкретного юзера