Последний раз была информация о том, что нужны тесты для многопоточности. Что бы не было race condition

Всем привет! Кто-нибудь знает докер образ, в котором была бы утилита clickhouse-format? В официальных образах clickhouse-client/server её нет.

И вообще, есть ли способ собрать данный бинарник без сборки всего кликхауса?

Добрый день! Подскажите как сделать left join с большим словарем, в котором хранится история, на дату. Т е в левой таблице table1 есть dict_id и my_date, во правой таблице словаря table2  есть dict_id, start_date, end_date. Необходимо выбрать значение из словаря на my_date без уменьшения выборки. Делаю all LEFT OUTER JOIN. Т к условия на даты нельзя использовать в using приходится выносить их в where наверх. А в этом случае выражение my_date>start_date уменьшает выборку, в случае если значения словаря есть на дату больше чем my_date, но на меньшую дату значения в словаре еще не определено.

И вообще, есть ли способ собрать данный бинарник без сборки всего кликхауса?

Есть. cmake .. -DCLICKHOUSE_SPLIT_BINARY=1 -DENABLE_CLICKHOUSE_ALL=0 -DENABLE_CLICKHOUSE_TOOLS=1 && make -j16 clickhouse-format

только собираться будет 90% кликхауса

Спасибо!

только собираться будет 90% кликхауса

Это единственный вариант?

Так много зависимостей?

пока да, мы медленно пытаемся это распутать но с самым низким приоритетом

Ок, спасибо

@proller Я правильно понимаю, если мне нужен форматтер в докере, то билдить из сорсов кликхаус — единственный вариант?

на данный момент да

а вообще нет

бинарник clickhouse уже умеет format

можно сделать симлинк clickhouse-format -> clickhouse

можно сделать симлинк clickhouse-format -> clickhouse

Это уже очень хорошо.

Спасибо

Добрый день. Подскажите, в чем причина что индекс не используется? https://gist.github.com/Ruslan/834e32ff44f82e59569bcbc4037dd14a

добавьте условие на дату

В конце запрос с условием на дату, в разных таблицах разный эффект

На дату (f2) добавил условие, не изменилось, обновил по ссылке результат

ага, ну смотрите, во первых, если у вас таблица f1f4, то условие на f4 по индексу работать не будет, ибо как

но

у вас кусок where уезжает в prewhere

а т.к. where нельзя сказать что сильно большой, то что есть, то и уезжает

т.е. фильтр по f4 в f1f4 таблице что-то там в prewhere отфильтровывает, и что остается уже обрабатывается "для всего запроса".

а когда вы f1f4 таблицу фильтруете по f1 или f4f1 по f4, то там индекс как бы работает и это вполне ожидаемо.

а когда у вас есть два условия в запросе, то в prewhere попадает условие по более легкой колонке

если я все правильно помню, и потом уже по оставшимся блокам проверяются оставшиеся условия

А почему тогда в таблице f4f1 нормально работает индекс при запросе по f1?

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

Добрый день. Подскажите, в чем причина что индекс не используется? https://gist.github.com/Ruslan/834e32ff44f82e59569bcbc4037dd14a

>(f1, f4) >select count(*) from tmp2 where f4 = 2; >Запрос по f4 обрабатывает все записи и не использует индекс (BUG?) так и должно быть таблица отсортирована по f1||f4 а f1 в условии нет, причем f1 должно быть =

Всем привет! А можно ли в GraphiteMergeTree усреднять данные с учетом времени? Поясню - предполагается хранить некоторые метрики, значения которых - это скорость. Если такие метрики поступают неравномерно и в качестве агрегирующей функции взять avg, то усредненное значение получится некорректным, потому что надо усреднять с учетом времени между метриками. Как это можно решить?

А почему тогда в таблице f4f1 нормально работает индекс при запросе по f1?

потому что clickhouse не тормозит. я думаю это зависит от того что на самом деле означает число processed. которое вы видите, и чему при этом равно время выполнения запроса в этом случае. в достаточно умной базе этот запрос можно было бы переписать в виде f4=v1 and cond(f1) or f4=v2 and cond(f1) .. чтобы индекс сработал, тут это вряд ли имеет место.

>(f1, f4) >select count(*) from tmp2 where f4 = 2; >Запрос по f4 обрабатывает все записи и не использует индекс (BUG?) так и должно быть таблица отсортирована по f1||f4 а f1 в условии нет, причем f1 должно быть =

Покажите результат команды SHOW CREATE TABLE f1f4 и SHOW CREATE TABLE f4

а CH не умеет случайно залазить во второй столбец индекса если у первого столбца низкая кардинальность?

show create в начале по ссылке

Покажите результат команды SHOW CREATE TABLE f1f4 и SHOW CREATE TABLE f4

они в gist называются tmp2 и tmp соответственно, просто из этих названий невозможно понять о чем речь.

а CH не умеет случайно залазить во второй столбец индекса если у первого столбца низкая кардинальность?

wat? кардинальность? у CH rule based optimizer, он вообще стоимость не считает.

>(f1, f4) >select count(*) from tmp2 where f4 = 2; >Запрос по f4 обрабатывает все записи и не использует индекс (BUG?) так и должно быть таблица отсортирована по f1||f4 а f1 в условии нет, причем f1 должно быть =

я тоже такое поведение ожидаю, но почему-то в f4|f1 при фильтре по f1 происходит отсечение лишних записей. Плюс когда используются одновременно и f1 и f4 то результат разный (последние запросы в примере)

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

потому что clickhouse не тормозит. я думаю это зависит от того что на самом деле означает число processed. которое вы видите, и чему при этом равно время выполнения запроса в этом случае. в достаточно умной базе этот запрос можно было бы переписать в виде f4=v1 and cond(f1) or f4=v2 and cond(f1) .. чтобы индекс сработал, тут это вряд ли имеет место.

по f4f1 запрос с условиями f1,f2,f4 стабильно быстрее, чем в f4f1, значит processed означает что-то похожее на истину

Умные дяди, объясните

я тоже такое поведение ожидаю, но почему-то в f4|f1 при фильтре по f1 происходит отсечение лишних записей. Плюс когда используются одновременно и f1 и f4 то результат разный (последние запросы в примере)

я подозреваю, потому что в таблице parts_columns есть информация в каких партициях эти даты есть. И там баги ровным слоем рассыпаны, например после optimize меняется информация в системных таблицах и все ломается https://github.com/yandex/ClickHouse/issues/2342#issuecomment-388395965

поднял кластер из двух нод. ZK на отдельном инстансе

На второй ноде получают такое: 2018.05.29 13:57:48.346602 [ 23 ] <Debug> distributed.distributed_logs (StorageReplicatedMergeTree): Fetching part 20180529_20180529_0_0_0 from /clickhouse/tables/distributed_logs/replicas/01 2018.05.29 13:57:48.391622 [ 23 ] <Trace> ReadWriteBufferFromHTTP: Sending request to http://localhost:9009/?endpoint=DataPartsExchange%3A%2Fclickhouse%2Ftables%2Fdistributed_logs%2Freplicas%2F01&part=20180529_20180529_0_0_0&compress=false 2018.05.29 13:57:48.391865 [ 23 ] <Error> distributed.distributed_logs (StorageReplicatedMergeTree): DB::StorageReplicatedMergeTree::queueTask()::<lambda(DB::StorageReplicatedMergeTree::LogEntryPtr&)>: Poco::Exception. Code: 1000, e.code() = 111, e.displayText() = Connection refused, e.what() = Connection refused

А если курлом - то все "звонится"

На второй ноде получают такое: 2018.05.29 13:57:48.346602 [ 23 ] <Debug> distributed.distributed_logs (StorageReplicatedMergeTree): Fetching part 20180529_20180529_0_0_0 from /clickhouse/tables/distributed_logs/replicas/01 2018.05.29 13:57:48.391622 [ 23 ] <Trace> ReadWriteBufferFromHTTP: Sending request to http://localhost:9009/?endpoint=DataPartsExchange%3A%2Fclickhouse%2Ftables%2Fdistributed_logs%2Freplicas%2F01&part=20180529_20180529_0_0_0&compress=false 2018.05.29 13:57:48.391865 [ 23 ] <Error> distributed.distributed_logs (StorageReplicatedMergeTree): DB::StorageReplicatedMergeTree::queueTask()::<lambda(DB::StorageReplicatedMergeTree::LogEntryPtr&)>: Poco::Exception. Code: 1000, e.code() = 111, e.displayText() = Connection refused, e.what() = Connection refused

А что в конфиге в <interserver_http_host> ?

А что в конфиге в <interserver_http_host> ?

0.0.0.0

0.0.0.0

Тут должно быть: Hostname that is used by other replicas to request this server.

То есть hostname по которому сервер доступен для других реплик

То есть hostname по которому сервер доступен для других реплик

то есть его ipшничек можно указать?

да

потому что clickhouse не тормозит. я думаю это зависит от того что на самом деле означает число processed. которое вы видите, и чему при этом равно время выполнения запроса в этом случае. в достаточно умной базе этот запрос можно было бы переписать в виде f4=v1 and cond(f1) or f4=v2 and cond(f1) .. чтобы индекс сработал, тут это вряд ли имеет место.

На тему того, влияет ли число в processed на скорость — обновил на gist бенчмарк с большим числом данных. Вывод: Сокрашение Processed в 145.90 / 51.54 = 2.83 раза, дает рост производительности в 1.767 / 0.615 => 2.87 раз Так что получается что простая перестановка в первичном ключе дает ускорение производительности в запросе, который использует все значения первичного ключа? optimize ничего не изменил.

а разве это не ип других инстансов, которые надо слушать?

Нет, это ип или хостнейм самого сервера

На тему того, влияет ли число в processed на скорость — обновил на gist бенчмарк с большим числом данных. Вывод: Сокрашение Processed в 145.90 / 51.54 = 2.83 раза, дает рост производительности в 1.767 / 0.615 => 2.87 раз Так что получается что простая перестановка в первичном ключе дает ускорение производительности в запросе, который использует все значения первичного ключа? optimize ничего не изменил.

а сколько процессед для FROM tmp2 WHERE (f1 < '2018-05-01 10:00:00')

from tmp2 where f1 < '2018-05-01 10:00:00' => Elapsed: 1.191 sec. Processed 145.90 million rows

а разве это не ип других инстансов, которые надо слушать?

Настройка про которую вы говорить называется <listen_host>

Настройка про которую вы говорить называется <listen_host>

Я уже собрался с силами и победил. Спасибо!

> Так что получается что простая перестановка в первичном ключе дает ускорение производительности в запросе, который использует все значения первичного ключа? первичный ключ определяет порядок сортировки в котором данные лежат в таблице, а индекс там разреженный, так что всё логично

вопрос про clickhouse + grafana. появился ли способ создавать графановские алерты, не копируя данные из clickhouse в prometheus?

вопрос про clickhouse + grafana. появился ли способ создавать графановские алерты, не копируя данные из clickhouse в prometheus?

Там же есть отдельный плагин для кх

но алертов под него afaik нет

алерты под плагин?) это что вообще такое?) плагины это коллекторы всего лишь, алерты настраиваются силами графаны

я выше кидал бинарник telegraf для influxdb, отлично подключается к графане

Там же есть отдельный плагин для кх

ну это понятно, только в нем "tsdb.HandleRequest() error Could not find executor for data source type: vertamedia-clickhouse-datasource" разработчики графаны пишут, что алерты под кастомные датасурсы будут не раньше grafana 5.2. вот я и спрашиваю, вдруг есть воркараунд какой.

так там для influxdb коллектор. считайте, родной для grafana

алерты под плагин?) это что вообще такое?) плагины это коллекторы всего лишь, алерты настраиваются силами графаны

Я вот тоже так считал

есть чатик "Церковь метрик", лучше туда с таким вопросом)

Я вот тоже так считал

ну т.е. мораль в том, что grafana отдельно, а алерты на кликхаусовские данные разумно делать другой тулзой?

yep

я бы даже сказал "графана отдельно, а алерты разумно делать другой тулзой"

А Kapacitor c КХ как-то интегрируется или он чисто для инфлюкса?

я чего-то не понимаю

вот алерт. Соорудил и вперде

а кнопочка test работает?

Хотя совершенно не понятно, зачем алертингом у вас занимается графана, но это уже не моё дело

оно там в итоге ругнется что алерты поддерживаются только для graphite и influx(?)

походу пилят, но судя по error пока до конца не запилили?

про ненужность алертов графаны я выше писал что полностью солидарен

про ненужность алертов графаны я выше писал что полностью солидарен

Я был удивлен докладом Авито, на котором рассказали, что они алертят инфраструктуру микросервисную силами графаны

у авито впринципе странные доклады всегда)

(хотя не мне говорить, я сам тот ещё докладчик)

Я был удивлен докладом Авито, на котором рассказали, что они алертят инфраструктуру микросервисную силами графаны

Алертим силами Мойры

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

в доке https://clickhouse.yandex/docs/ru/query_language/queries/#query_language-queries-create_table блок При создании материализованного представления, нужно обязательно указать ENGINE - движок таблицы для хранения данных. Материализованное представление работает следующим образом: при вставлении данных в таблицу, указанную в SELECT, часть вставленных данных конвертируется запросом, а результат вставляется в представление. задублирован

интересно, делал ли кто-нибудь на mat.view триггеры для мониторинга

и вообще можно ли так... ch умеет в kafka писать?

Алертим силами Мойры

Я не про бизнес-метрики

Я про кубу и т.д.