это для примера

у вас в a > 0 а - это что должно быть, то что вы суммируете или sumState?

ок понял

... AS SELECT sumState(a) as sum_a, sumState(b) as sum_b, CASE WHEN sum_a > 0 THEN (sum_b / sum_a) ELSE 0 END AS c ...

sum_a > 0 вот это как я понимаю и не провильно

ага, хорошо. а что вы хотите сделать, использовать то, что уже внутри просуммировалось?

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

finalizeAggregation

а где же про такое прочитать?)

и обернуть там где только с 0 сравнение или в деление тоже?

https://github.com/yandex/ClickHouse/blob/master/dbms/src/Columns/ColumnAggregateFunction.cpp#L33

прочитать "про такое" можно в документации, в system.functions и в сорсах.

обернуть везде, AggregateFunction(_) значения мало в какие функции можно передавать.

прочитать "про такое" можно в документации, в system.functions и в сорсах.

в документаци по поиску данного текста ничего не находит

прочитать "про такое" можно в документации, в system.functions и в сорсах.

Большое спасибо, создание прошло успешно

Всем привет! Возникла проблема, есть ряд сломавшихся запросов на репликацию, которые уже давно пытаются выполниться и видимо не смогут по причине отсутствия партиции. Я видел что ранее всем советовали удалить эти запросы из очереди в zookeeper. Я удалил их из zookeeper, но не вижу чтобы они удалились из replication_queue в CH Как часто CH синхронизируется с ZK? Или как форсануть этот процесс ?

можно сделать DETACH/ATTACH таблицы

или просто перезапустить сервер

необходимо для collapsing merge tree производить полное схлопывание чтобы не оставалось больше одной партиции, сейчас планируем писать в виде скрипта сбоку, но вдруг есть какая то настройка

Нет, такого нет.

Крутим throughput в ch-драйвере, и появилось несколько вопросов: 1) Если данные отправлять в нежатом виде, или с алгоритмом, отличным от представленного в конфигах, они всеравно пожмутся при merge-операции в соответствии с указанными compression в настройках сервера? 2) От чего защищает CityHash над сжатым блоком данных?

1) Да, алгоритм сжатия смерженного куска не зависит от сжатия исходных данных 2) cityhash это чексумма

и в догонку, могут ли отправляемые блоки в пределах одного потока быть сжаты разными методами? Хочется проверить кейс, с отправкой в lz4 по дефолту и переключением на zstd, когда включается throttling по сети.

Должно работать - dispatch алгоритма сжатия производится для каждого блока независимо

Нет, такого нет.

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

Фоновые мержи чаще всего не доводят до одного куска - эвристика такая, что если осталось всего несколько больших кусков, ещё раз мержить (тем самым ещё разок перезаписав данные) нет смысла.

Добрый день. Скажите, пожалуйста, изменилась ситуация с перешардированием с июня 2016? В документации указано, что функционал в состоянии беты.

Изменилась в худшую сторону - перешардирование вообще удалили :) Будем переосмысливать задачу.

Фоновые мержи чаще всего не доводят до одного куска - эвристика такая, что если осталось всего несколько больших кусков, ещё раз мержить (тем самым ещё разок перезаписав данные) нет смысла.

А опций для Настройки этого поведения получается нет ?

1) Да, алгоритм сжатия смерженного куска не зависит от сжатия исходных данных 2) cityhash это чексумма

Спасибо за ответы. Смущает что чексумма проверяется от сжатых данных а не от сырых. Не совсем понятно, от чего эта чексумма пытается защитить. По сжатию блоков разными методами - примерно так и предполагал. А зачем в таком случае передается setting network_compression_method в начале сессии, раз он влияет только на вкл/выкл сжатия? В любом случае - потестирую переключение сжатия на лету.

Настройка влияет на то, как данные отсылаются.

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

Это вы где смотрите? Вот код: выбираем сжатие на клиенте (для отправки данных INSERT): https://github.com/yandex/ClickHouse/blob/master/dbms/src/Client/Connection.cpp#L392 , вот на сервере (для отправки результатов запроса): https://github.com/yandex/ClickHouse/blob/master/dbms/src/Server/TCPHandler.cpp#L667

в обоих случаях настройка влияет на выбор алгоритма сжатия

https://github.com/yandex/ClickHouse/blob/master/dbms/src/IO/CompressedWriteBuffer.cpp#L102 Получается можно включить флажок компрессии но слать данные не сжато с методом NONE Второй способ слать их не сжато - не включать флажок здесь: https://github.com/yandex/ClickHouse/blob/master/dbms/src/Client/Connection.cpp#L358 При этом способы подготовки несжатых блоков будут различаться. (в первом случае нужна чексумма)

Выбор алгоритма декомпрессии совсем не завязан на то что мы отправили в network_compression_method, а зависит от первого байта блока и выбирается тут: https://github.com/yandex/ClickHouse/blob/master/dbms/src/IO/CompressedReadBufferBase.cpp#L100

Выбор алгоритма декомпрессии совсем не завязан на то что мы отправили в network_compression_method, а зависит от первого байта блока и выбирается тут: https://github.com/yandex/ClickHouse/blob/master/dbms/src/IO/CompressedReadBufferBase.cpp#L100

Ну правильно - то есть настройка влияет на алгоритм сжатия, но не влияет на алгоритм разжатия :)

Да, это до меня уже дошло. А зачем тогда её отправлять в сервер?

А нет планов убрать два способа отправки не сжатых данных? Я конечно это закостылю, но хочется кастануть сразу правильный костыль.

Да, это до меня уже дошло. А зачем тогда её отправлять в сервер?

Она используется для распределённых запросов для передачи промежуточных данных между серверами.

А нет планов убрать два способа отправки не сжатых данных? Я конечно это закостылю, но хочется кастануть сразу правильный костыль.

Имеется ввиду compression_method = 'none' и вообще без компрессии? Нет, не планируется. compression_method = 'none' добавил один человек ради эксперимента, чтобы хранить данные в таблице в несжатом виде. У него была гипотеза - на быстром массиве SSD так будет лучше для обработки запросов, но гипотеза не оправдалась, так как данные перестали помещаться.

Спасибо за разъяснения. А у вас нет тестов, с какого размера блока становится выгодно сжимать данные с LZ4, а до какого - отправлять без сжатия совсем. У нас получается так, что когда мало CPU и хорошая сеть - блоки со строками либо с рандомными данными выгодно жать когда в них счет строк начинает измеряться сотнями. Когда много CPU либо плохая сеть - выгодно жать ZSTD во время простоев.

Точных измерений нет. Мы включили zstd на кластере, который упирался в сеть. Это может быть видно одним из двух вариантов: 1. Используется вся полоса. 2. Большой packet loss. Это можно наблюдать по счётчику tcp retransmits - если больше где-то нескольких процентов. Для эксперимента очень легко поменять network_compression_method и проверить.

Чексумма сжатых данных нужна по нескольким причинам. 1. При всяких повреждениях (bit rott на диске как пример), бьются именно сжатые данные. 2. Некоторые алгоритмы сжатия не умеют безопасно сообщать об ошибке при битых данных при разжатии. Бонус - вычислять чексумму для сжатых данных существенно проще, чем для разжатых, потому что их меньше, и их не надо разжимать перед этим. Правильно хранить две чексуммы - для сжатых и для разжатых данных. На самом деле мы так и делаем - при хранении в MergeTree таблицах. Там даже ещё круче - три чексуммы - целиком на файл для сжатых данных, для несжатых данных, и ещё на каждый сжатый блок - для сжатых данных. А при передачи по сети - чексуммы только для сжатых данных на каждый блок, так как больше - оверкилл.

Коллеги, подскажите пожалуйста, нужно сделать выборку по диапазонам. Есть поле load_time выборка будет что то типа countIf(load_time < 1), countIf(load_time >= 1 AND load_time < 2), countIf(load_time >= 2) Диапазоны должны расчитываться на основе данных из поля load_time Мне нужно всегда статическое кол-во диапазонов - 3. Кроме квантилей ничего в голову пока что не приходит.

а чем вам не подходят перечисленные выше диапазоны

а чем вам не подходят перечисленные выше диапазоны

Хотелось бы чтобы были динамические. Или это лишнее? Как думаете. В принципе условно статично , что если загрузка страницы больше 1 сек то это плохо

обычно диапазоны нужны либо фиксированные "по горизонтали", т.е. гистограмма по регулярной сетке, либо "по вертикали", т.е. quantiles() с каким-то набором параметров.

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

а если вы получите из данных медиану, а потом посчитаете что countIf больше медианы содержит половину всех данных, то какая в этом будет польза.

Точных измерений нет. Мы включили zstd на кластере, который упирался в сеть. Это может быть видно одним из двух вариантов: 1. Используется вся полоса. 2. Большой packet loss. Это можно наблюдать по счётчику tcp retransmits - если больше где-то нескольких процентов. Для эксперимента очень легко поменять network_compression_method и проверить.

Спасибо. Когда сделаем вменяемые тестовые стенды попробую пошарить результаты. У нас немного другой кейс, мы делаем взаимодействие между приложением и сервером и хочется выжать из него максимум и ещё немного сверху. Пока решили в рамках одного соединения жать блоки LZ4 до тех пор пока не упремся в сеть, затем в моменты отлупов по сети - переключаться на zstd, а хвосты данных равно как и одиночные блоки небольшого размера не жать совсем.

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

Спасибо огромное Вам за развернутый ответ.?

Привет всем, А подскажите как подключить ClickHouse к Tableau на MacOS??

Привет всем, А подскажите как подключить ClickHouse к Tableau на MacOS??

Не подключается. Tableau под MacOS не поддерживает ODBC, который используется для подключения к ClickHouse.

А может кто-то подключал через SQL proxy??

Есть тикет на то что Distributed таблица не работает с MATERIALIZED колонками ?

@milovidov_an смотрел че join таблицы c кривыми данными в колонках? я тикета не нашел , и предыдущий коммент глянь ^^^.

/stat@combot

combot.org/chat/-1001080295593

Есть тикет на то что Distributed таблица не работает с MATERIALIZED колонками ?

Почему не работает? Например, если в Distributed колонка partner_id UInt64, а в локальной таблице partner_id UInt64 MATERIALIZED dictGetUInt64('dict', 'user_id', pad_id), разве не будет работать?

мне кажется, все прекрасно работало, правда потом в локальной таблице я переделал на ALIAS, чтобы это значение бралось по состоянию на сейчас, а не на тогда

Почему не работает? Например, если в Distributed колонка partner_id UInt64, а в локальной таблице partner_id UInt64 MATERIALIZED dictGetUInt64('dict', 'user_id', pad_id), разве не будет работать?

в distributed вообще не задаются колонки

их там не надо задавать, зачем

просто тип описать и всё

а задаётся в той таблице, куда смотрит Distributed

просто тип описать и всё

? CREATE TABLE partd AS part ENGINE = Distributed здесь никаких типов нет

CREATE TABLE partd ( day Date, id UInt64, partner_id UInt64 ) ENGINE = Distributed ('stats', 'db', 'part') CREATE TABLE part ( day Date, id UInt64, partner_id UInt64 MATERIALIZED id + 100 ) ENGINE = MergeTree(...)

insert into partd (day, id) values ('2018-01-09', 777);

здесь шарда отвечат что не вставлено поле event_date , хотя если напрямую вставлять в таблицу part то все ок

попробовал у себя, и правда не работает

а потом вспомнил, что сталкивался с такой проблемой

попробовал у себя, и правда не работает

то-то же ... хз из-за чего, особо не тестил ,толи из-за PARTITION BY То ли еще че

вот так работает

CREATE TABLE partd ( day Date, id UInt64, partner_id UInt64 DEFAULT id + 100 ) ENGINE = Distributed (stats, 'default', 'part', rand()) CREATE TABLE part ( day Date, id UInt64, partner_id UInt64 DEFAULT id + 100 ) ENGINE = MergeTree(day, (id, day), 8192)

:) insert into partd (day, id) values ('2018-01-10', 555); INSERT INTO partd (day, id) VALUES Ok. 1 rows in set. Elapsed: 0.004 sec.

SELECT * FROM partd ┌────────day─┬──id─┬─partner_id─┐ │ 2018-01-10 │ 555 │ 655 │ └────────────┴─────┴────────────┘

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

CREATE TABLE partd ( day Date, id UInt64, partner_id UInt64 DEFAULT id + 100 ) ENGINE = Distributed (stats, 'default', 'part', rand()) CREATE TABLE part ( day Date, id UInt64, partner_id UInt64 DEFAULT id + 100 ) ENGINE = MergeTree(day, (id, day), 8192)

не видел в доках примера где можно типы отписывать у Distributed ENGINE

так оно все лежит в /local/clickhouse/metadata/

так оно все лежит в /local/clickhouse/metadata/

ну точно , в любом случае оно клонирует схему, ну и нашелся кейс когда оно не работет

https://www.humblebundle.com/books/python-by-packt-book-bundle Мало-ли вдруг кому пригодится.. (ссылка не реферальная), ранее на амазоне брал Mastering Python Networking по цене, большей чем весь набор по этой акции :)

Спасибо, купил.

@milovidov_an, Алексей, добрый день! Подскажите, пожалуйста, а можно в кликхаусе сделать ротацию данных с гранулярностью меньше, чем 1 месяц? Сейчас как это вижу- запускается крон задача, которая находит партиции старше определенного срока, делает их детач и удалет на уровне файловой системы из директории detached. На уровне отдельных частей партиции можно работать только при их присоединении. Будет ли работать следующий вариант? 1)сделать детач партиции, чей кусок дынных хочу оставить 2)сделать аттач частей этой партиции 3)на уровне файловой системы удалить ненужные части

если кто-то из присутствующих сталкивался с подобным кейсом, то буду признателен, если вы поделитесь опытом!

если кто-то из присутствующих сталкивался с подобным кейсом, то буду признателен, если вы поделитесь опытом!

Возможен такой вариант: партиционировать по дням, скриптом по крону удалять хвостовые партиции.

или по неделям

что имеется под хостовыми партициями? манипуляции с отдельными таблицами? формат партиций в ClickHouse имеет вид YYYYMM

Возможен такой вариант: партиционировать по дням, скриптом по крону удалять хвостовые партиции.

пардон, прочитал хвостовые как хостовые...

<Warning> Application: Logging to console, в чем может быть проблема? логи не пишутся в файл, запуск через docker

опция --daemon

https://github.com/yandex/ClickHouse/blob/d21a2a057b2cd4133cacdc7bea9643558a87797c/libs/libdaemon/include/daemon/BaseDaemon.h#L39

есть какое-нибудь видео с конференции, где разбираются вопросы репликации, шардинга и эксплуатации в целом?

Ребят, подскажите пожалуйста как обычно поступают с шардами, если кластер растет? То есть если я у меня сейчас 12 серверов, на которых я хочу сделать 6 шардов по 2 реплики, а завтра у меня будет 24 сервера, то есть какое-то красивое решение как "размазать" эти шарды? кроме создание новой таблицы и Insert into select? Очень нужен какой-то best practice на эту тему.

Ребят, подскажите пожалуйста как обычно поступают с шардами, если кластер растет? То есть если я у меня сейчас 12 серверов, на которых я хочу сделать 6 шардов по 2 реплики, а завтра у меня будет 24 сервера, то есть какое-то красивое решение как "размазать" эти шарды? кроме создание новой таблицы и Insert into select? Очень нужен какой-то best practice на эту тему.

* перенести часть партиций на новые сервера * временно не вставлять в старые сервера, пока на новых не наберется столько же данных