нужная строка лишь одна из многих, которые тоже агрегируются. Думал про anyHeavy() но в доке говорится про недетерминированность результата

Интересно почему получается разное количество? С windowFunnel получается больше результатов и они релевантные

sequenceMatch('(?1).*(?2).*(?3)')(toDateTime(sessionTimestamp + (eventOffset / 1000)),
eventName = 'cSearchAddress',
eventName = 'cHouseNumberSearchString',
eventName = 'cAddress',
eventName NOT IN
('cSearchAddress', 'cHouseNumberSearchString', 'cAddress')) as sequenceEventName

windowFunnel(60000)(
toDateTime(sessionTimestamp + (eventOffset / 1000)),
eventName = 'cSearchAddress',
eventName = 'cHouseNumberSearchString', eventName = 'cAddress') AS level

добрый день. пробую отреплицировать таблицу. подскажите пожалуйста, как задать имя (IP), по которому 1 сервер будет обращаться в другой?
я думал, вот это:
<macros>
   <replica>clickhouse-2</replica>
</macros>

а он пробует по имени хоста обращаться

в config.xml настройка interserver_http_host

то есть он в зукипер запишет значение этой настройки?

Здравствуйте, господа.

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

Шаги:
1) имеем max_memory_usage, например, 50 Гб
2) запросу нужно около 70 (эмпирически приверено) и он падает
3) через некоторое время (10-12 упавших запросов) уже простые запросы не пролезают

Через top посмотрел, что после каждого упавшего запроса %MEM вырастает на ~7% и не падает назад.

Если запрос выполняется успешно без ограничения по памяти, то потребление памяти не растет

и можно ли туда IP-адрес вписать, а не имя?

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

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

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

имя реплики в ZK это часть path
значение куда именно обращаться для скачивания новых партов зареганых в ZK берется из  interserver_http_host и тоже сохраняется в ZK при регистрации \ изменении конфигурации реплики

Добрый день. Чего-то последние релизы (и stable, и LTS) не могут принять от carbon-clickhouse больше 4000 метрик за раз (Attempt to read after eof, сначала пятисотка от HTTP-клиента, потом сегфолтит). Последний раз работало на 20.6.8.5. Не подскажете, куда копать? Или это приколы carbon-clickhouse явные?

Здравствуйте! Делали insert from select  в дистрибьютед таблицу через clickhouse-client одного из инстансов, в процессе этого потеряли коннект к поду.. Продолжил ли запрос выполняться в этом случае, и можно ли как-то проверить, что он до конца отработал не сравнивая данные в таблицах?

возможно умерло что-то в clickhouse

Подскажите как в toDateTime загнать миллисекунды?

в DateTime нет миллисекунд, мб тебе нужен DateTime64 (и соотв. toDateTime64)

Он UnixTimestamp64Milli странно переводит

Так используйте fromUnixTimestamp64Milli

если под остался жив и вы просто коннект из clickhouse-client потеряли
то смотрите на поде в котором clickhouse-client коннектился, в  system.processes
и прогресс как ваш INSERT ..SELECT работает
и ничего не трогайте

у вас под distributed лежит ReplicatedMergeTree?
значит сначала данные у вас будут разбиты по шардам в  каталоге /var/lib/clickhouse/data/db/distributed/<shard_host_port>/*.bin  этого distributed на ноде инициаторе
данные там на блоки разобьются на миллион записей кажется (могу ошибаться)
и потом это будет пушится по доступным репликам в шардах...

и когда оно доедет до ReplicatedMergeTree
тогда начнет механизм дедупликации ReplicatedMergeTree работать, а именно там хранятся в ZK контрольные суммы 100 последних вставленных блоков
если совпадает, то вставляться не будет...

соответственно, если у вас меньше 100 миллионов успелов вставиться  в distributed
то в целом можно заново запустить...
если вы KILL сделали

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

спасибо!