Скажите, пожалуйста, а есть ли какие-нибудь ограничения на максимальное количество кафка-консьюмеров к разным топикам кафки для одного сервера КХ?

У меня есть около 100 топиков кафки (суммарно под 100.000 rps), которые нужно затягивать в КХ. Попробовал и на жирных (4 консьюмера на один топик) и на нескольких сразу (4 параллельных топика по 1 консьюмеру) - проблем нет. Но будет ли всё так же гладко, если включить сразу 100? Какие есть подводные камни?

Думаю настроить реплики и тянуть данные с двух серверов параллельно.

Похоже дело было в другом, починилось отключением compres-data в carbon-clickhouse. Вдруг кому-нибудь ещë поможет.

Привет!
Подскажите, пожалуйста, а можно ли в clickhouse запретить использование SELECT * FROM url()?

Навскидку несколько особенностей, которые приходят в голову.

* Частота вставок.
Если отдельный консюмер 10 раз в секунду что-то отправляет в кликхаус, то 100 консюмеров будут 1000 раз в секунду отправлять.
Соответственно может вырасти потребность в уменьшении частоты инсертов. Либо средствами стороннего буфера, если вы его используете, либо что-то типа Buffer в самом кликхаусе, либо в кафко-параметрах консюмера увеличивать размер забираемых пачек данных ( fetch.min.bytes , fetch.max.bytes, max.partition.fetch.bytes, fetch.max.wait.ms и т.п.)

* Для высоконагруженных топиков количество кафковских partitions на которые разбит топик может стать узким местом, ограничивающим масштабирование числа консюмеров.  Поскольку из каждого partition кафкатопика не более чем один consumer из consumer group может читать, то число эффективно работающих консюмеров ограничено числом партишнов, все следующие консюмеры будут сидеть в засаде, ожидая что после перебалансировки им тоже что-нибудь перепадёт.

Ещё:
* (Вроде бы).
Если консюмеры не приложения, которые ETL проделывают вне ClickHouse, а ENGINE = KAFKA, то вроде бы количество таких консюмеров надо учитывать и корректировать количество threads в параметрах ClickHouse: SELECT * FROM system.settings WHERE name LIKE '%pool%';
Тут я не разбираюсь. Можно в поиске группы по словам
типа background_pool_size kafka
или background_schedule_pool_size кафка
посмотреть.
Там были аналогичные вопросы:
https://t.me/clickhouse_ru/190460

На большом массиве данных считал хэш-суммы и обнаружил,
что порядок данных во внешнем запросе КХ полностью определяется
порядком вложенного в запросе типа:

SELECT
 x
FROM
(  
SELECT
  x
FROM
  y
ORDER BY x
)

Это текущее поведение. Может ли оно измениться  в дальнейшем ?

(вопрос связан с оптимизацией, дополнительное упорядочивание во внешнем запросе занимает существенное время)

Да, я именно про engine=kafka. Спасибо за комментарии и наводку.

так работает скл. Сначала что бы отдать выборку наверх, нужно сначала отсортировать субквери.

> Это текущее поведение. Может ли оно измениться  в дальнейшем ?

На него достаточно надежно завязыватся, оно используется в том числе для собирания отсортированных значений в массив.

Ну да, так и отсортировал.

Спасибо Дмитрий, именно это и хотел выяснить

потому что если не указывать сортировку, то в верхнюю выборку можно отдавать данные по мере их вычисления(типа стрима)

Значит можно во внешнем не сортировать, буду использовать

Привет.
Подскажите, пожалуйста, как написать IN для нескольких столбцов сразу? У меня есть пары значений столбцов, по которые я хочу выбрать записи. Т.е. как сделать что-то вроде
SELECT * FROM table1 WHERE (col1, col2) IN ((11,22), (34,43), (57,68))

WITH (number, number + 10) AS t
SELECT t
FROM system.numbers
WHERE t IN (1, 11)
LIMIT 1

Query id: 99b01085-ea2b-4b26-b605-ebd415f54694

┌─t──────┐
│ (1,11) │
└────────┘

не понял описанной идеи

я написал запрос, который работает :)

свои колонки подставляешь - всё работает

твой исходный запрос тоже должен работать