Мы собственно хотим использовать КХ именно по назначению - агрегировать данные БЫСТРО и получать нужные отчеты БЫСТРО, с чем он замечательно справляется )

@milovidov_an Алексей, а подскажите, есть у вас отзывы по работе кх в kubernetes?

Кликхаус умеет работать со статическими huge pages? (2m/1g)

Не умеет. Были эксперименты с huge pages. Статические не использовали, так как их сложно настраивать. (Transparent huge pages давали прирост производительности в некоторых случаях, но через несколько дней система деградировала из-за особенностей их аллокации.)

изменений не было чтобы поддерживать статистику запроса в HTTP header?

Нет, не добавляли.

Только прогресс бар в заголовках X-ClickHouse-Progress.

X-ClickHouse-Progress очень круто, спасибо

мы сохраняем ID запроса на промежуточном сервере и потом опрашиваем его

в итоге рисуем пользователю проценты

очень довольны

А что при изменении происходит со старыми данными? их нужно переливать заново, чтобы они сжались по-новому?

Данные сжимаются по-новому только при мержах. То есть, совсем старые данные автоматически пережиматься не будет. Можно вручную инициировать мерж старых партиций с помощью OPTIMIZE TABLE table PARTITION yyyymm FINAL. Мы так и сделали для экономии места. (При этом, если на диске осталось недостаточно места, то мерж не запустится.)

Данные сжимаются по-новому только при мержах. То есть, совсем старые данные автоматически пережиматься не будет. Можно вручную инициировать мерж старых партиций с помощью OPTIMIZE TABLE table PARTITION yyyymm FINAL. Мы так и сделали для экономии места. (При этом, если на диске осталось недостаточно места, то мерж не запустится.)

спасибо!

А есть какие-то примерные сроки когда появится релиз с фиксом удаления партиций в зукипере или тестовая сборка (v1.1.54284) в пакетах ?

По некоторым нелепым причинам ещё не опубликовано в stable репозитории. Перезапускаю...

Спасибо

Нет. Поддержка типа UUID неполная. Это community разработка и многие вещи ещё нужно доделывать. В данном случае это мелочи и доработка будет не сложной.

Алексей, есть шанс получить исправление со следующим релизом?

Алексей, это как раз нас случай. Было три реплики. Один сервер остановили, а удалить ноду из ZK забыли. Через zkCli.sh не получается удалить, падает и при delete и при ls с путем /log. Как можно воспользоваться вашей специальной программой, чтобы удалить ненужные ноды? Спасибо.

1. Делаете clone репозитория https://github.com/yandex/ClickHouse 2. Ставите все зависимости для сборки https://github.com/yandex/ClickHouse/blob/master/docs/en/development/build.rst 3. Выполняете часть пункта Build to work with code: mkdir build cd build cmake .. 4. В директории utils собираете две утилиты: zookeeper-dump-tree zookeeper-remove-by-list Для этого заходите в директорию build/utils/... и пишете make 5. Теперь у вас есть две эти собранные утилиты. Первая позволяет быстро получить список узлов в ZooKeeper. Для использования наберите ./zookeeper-dump-tree --help Вторая позволяет быстро удалить узлы по списку. Аналогично, посмотрите help. Для того, чтобы получить список узлов для удаления, возьмите результат zookeeper-dump-tree, выберите первый столбец (имя узла): cut -f1 отсортируйте. Следует проверить этот список, чтобы не удалить ничего лишнего.

подскажите пожалуйста. Я хочу сгруппировать сессии по их длительностям. Сейчас вырисовывается такая конструкция: if(duration < 30, 30, if(duration < 120, 120, if(duration < 360, 360, if(duration < 3600, 3600, if(..... if(duration < 86400, 86400, 90000)....)))

Есть специальная функция roundDuration(num): "This function is specific to Yandex.Metrica and used for implementing the report on session length." Иногда полезно обращаться к документации.

А кто-то может подсказать по <expression>rand64()</expression> внутри словаря? Есть дата рождения, нужно вычислить возраст пользователя. Можно как то написать expression что бы из даты рождения вычислять возраст при запросе?

Выражение зависит от того, в какой базе у вас данные (так как оно передаётся в SELECT запросе в источник словаря). Для ClickHouse это просто: today() - date_of_birth

Выражение зависит от того, в какой базе у вас данные (так как оно передаётся в SELECT запросе в источник словаря). Для ClickHouse это просто: today() - date_of_birth

Т.е. по сути это выражение для источника, а не для CH?

Есть специальная функция roundDuration(num): "This function is specific to Yandex.Metrica and used for implementing the report on session length." Иногда полезно обращаться к документации.

о, хорошо. Там правда верхняя граница не очень, но всё же круто выглядит, спасибо

Всем привет! Есть вопрос по настройке репликации. Имеется работающая реплика на 4 ноды. Есть задача заменить одну из нод на другую. Как это правильней делается? Есть какие-то подводные камни?

Для этого создаётся новая реплика на новой ноде - с помощью CREATE TABLE. После этого у вас станет на одну реплику больше. Затем удаляется старая реплика с помощью DROP TABLE. А если старая реплика полностью умерла и сервера больше нет, то надо удалить соответствующий ей узел в ZooKeeper: path_to_table/replicas/replica_name

подскажите пожалуйста. Я хочу сгруппировать сессии по их длительностям. Сейчас вырисовывается такая конструкция: if(duration < 30, 30, if(duration < 120, 120, if(duration < 360, 360, if(duration < 3600, 3600, if(..... if(duration < 86400, 86400, 90000)....)))

Более менее, хотя есть более удобный CASE WHEN ... THEN ... для таких цепочек.

да вот roundDuration или roundExp2 почти что нужно

о, наверное совсестить CEILING и логарифм

А ещё есть https://clickhouse.yandex/docs/en/single/#roundtoexp2-num

ага, мне уже ткнули

Всем привет. Столкнулись с проблемой, у нас почему-то на одном проекте начали виснуть запросы select distinct. Запрос выполняется, выдает пару значения и зависает.

У нас КХ используется для хранения исходных данных по которым мы считаем факты, а те запросы которые мы строим для агрегации просто умирают в MySQL и Postgres. Postgres показывает результаты лучше MySQL в разы, но все равно не достаточно. У нас есть например набор сущностей и время потраченное пользователем на сущность. В среднем 300 сущностей и 300 строк на пользователя с таймингами. Далее по каждой сущности нужно построить отчет по фроду, т.е. понять кто из пользователей слишком быстро прошел сущность или слишком медленно. MySQL такой запрос обрабатывает 40 секунд...

Тут вариант - писать лог фактов того, что пользователь потратил ещё какое-то количество времени на какую-то сущность. То есть "пользователь A потратил на B ещё +123 секунды времени". Потом простым запросом всё это суммировать. Такой лог получается неизменяемым и это удобно для ClickHouse.

Что интересно, на этом сервере 2 проекта, с аналогичными табличками, на первом данных прям очень много, и этот запрос отрабатывает нормально, на втором всего 20м и запросы стабильно виснут.

Если запрос не кильнуть, он может висеть неделями

@milovidov_an Алексей, а подскажите, есть у вас отзывы по работе кх в kubernetes?

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

Алексей, есть шанс получить исправление со следующим релизом?

В следующем релизе - нет, мы этим не занимались.

Т.е. по сути это выражение для источника, а не для CH?

Да. Оно передаётся в источник в виде SELECT expression AS name

Тут вариант - писать лог фактов того, что пользователь потратил ещё какое-то количество времени на какую-то сущность. То есть "пользователь A потратил на B ещё +123 секунды времени". Потом простым запросом всё это суммировать. Такой лог получается неизменяемым и это удобно для ClickHouse.

Тут есть проблемка :) У нас иногда меняются переменные для подсчета фактов. Даже не знаю какой пример привести...вобщем мы можем поправить например алгоритм подсчета времени которое пользователь провел в сущности. У нас есть поток событий типа: вошел в сущность, вышел из сущности. Потоки не всегда целостные, например есть 10 входов подряд, а выхода нет. Или например вход был 1 числа, а выход 15 числа и т.д. и мы применяем различные правила для таймаутов, фрода и пр. И получается, что после смены алгоритма система думает, что пользователь провел в сущности не 10 минут, а 15 или вообще 5.

Если запрос не кильнуть, он может висеть неделями

А есть ли возможность посмотреть, что в это время происходит на сервере? top -d0.5 - смотрим, использует ли clickhouse-server CPU. dstat - диск, сеть. iostat -dmx 1 - диск. sudo perf top - в каких функциях тратится CPU.

Сек. Призываем devops

Тут есть проблемка :) У нас иногда меняются переменные для подсчета фактов. Даже не знаю какой пример привести...вобщем мы можем поправить например алгоритм подсчета времени которое пользователь провел в сущности. У нас есть поток событий типа: вошел в сущность, вышел из сущности. Потоки не всегда целостные, например есть 10 входов подряд, а выхода нет. Или например вход был 1 числа, а выход 15 числа и т.д. и мы применяем различные правила для таймаутов, фрода и пр. И получается, что после смены алгоритма система думает, что пользователь провел в сущности не 10 минут, а 15 или вообще 5.

Понятно. Это сложнее... Как будто надо какие-то custom агрегатные функции делать внутри ClickHouse, которые могли бы учесть особенности этих алгоритмов... либо просто читать данные в свой скрипт, который их обрабатывает. Это уже весьма неэффективно.

Можно конечно замудриться с replacing merge tree и сделать идентификаторы сессий и по ним обновлять данные, но может получиться так, что вместо 10 сессий будет 5 из-за увеличения таймаута. Таймауты меняются в зависимости от среднего времени нахождения в сущности ) И разным сущностям могут применяться разные таймауты (этого пока нет, но будет).

Понятно. Это сложнее... Как будто надо какие-то custom агрегатные функции делать внутри ClickHouse, которые могли бы учесть особенности этих алгоритмов... либо просто читать данные в свой скрипт, который их обрабатывает. Это уже весьма неэффективно.

Поэтому мы берем поток эвентов из КХ, накладываем на них алгоритмы, проводим вычисление фактов и пишем их в MySQL ) А потом поверх этого добра строим отчеты...но вы же сами понимаете...

Версия 1.1.54284 опубликована.

Но вот сегодня весь день собираю прототип этого добра на CH. Есть кейс. Есть база обучающихся с фактами, есть факт "Территориальный банк". Есть пользователи системы аналитики. Каждому пользователю назначаются "фильтры", что бы они могли видеть данные по обучающимся только своего территориального банка. Есть суррогатный факт (то, что мы считаем налету) для курса - кол-во учащихся. И вот это кол-во учащихся должно фильтроваться по териториальному банку :) Вобщем кейсы очень интересные встречаются.

А есть ли возможность посмотреть, что в это время происходит на сервере? top -d0.5 - смотрим, использует ли clickhouse-server CPU. dstat - диск, сеть. iostat -dmx 1 - диск. sudo perf top - в каких функциях тратится CPU.

Сложно, сервер активно используется, CH и так в топе по всем параметрам

https://github.com/yandex/ClickHouse/releases/v1.1.54284-stable was tagged

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

Это perf top

В момент когда все 8 ядер в 100 ушли

Сделали ровно 8 висячих запросов

А это скриншот запроса, который виснет, или нормального?

Подскажите пожалуйста ссылку на сравнение производительности клик-хаус на open-shift (или виртуальный) и железе. Не могу найти.

На Openstack?

А это скриншот запроса, который виснет, или нормального?

Который виснет

Вроде да, не помню точно.

Подскажите пожалуйста ссылку на сравнение производительности клик-хаус на open-shift (или виртуальный) и железе. Не могу найти.

https://www.altinity.com/blog/2017/6/20/clickhouse-vs-redshift

Спасибо. Оно.

Там сравнение некоторого железа с некоторыми виртуалками в Amazon.

Который виснет

То есть, прогресс бар вообще не обновляется?

Прогресс бар моментально доходит до 98%

и потом вообще ничего не приходит

Даже стрелочка слева не крутится

Понятно. Есть подозрение на одно из изменений, которое у нас было. Для начала стоит проверить, что это никак не связано с DISTINCT. Если убрать DISTINCT, то тоже виснет?

без distinct тоже самое │ test5 │ │ test5 │ │ test5 │ │ test5 │ │ test5 │ │ test5 │ │ test5 │ │ test5 │ │ test5 │ │ test5 │ │ test5 │ │ test5 │ │ test5 │ │ test5 │ │ test5 │ │ test5 │ └────────┘ ↘ Progress: 20.77 million rows, 405.58 MB (117.44 million rows/s., 2.29 GB/s.) 98%

Понятно. Сейчас напишу в личку, как мы можем разобраться.

Подскажите, а как то можно обезопасить INSERT...SELECT Если сделать запрос CREATE table default.x1 ( x1 Float64, x2 Float64, x3 Float64 ) ENGINE = TinyLog ;; INSERT INTO default.x1 SELECT 0.1 as x1,0.3 as x3,0.2 as x2 ;; SELECT * FROM default.x1 Получается я ожидал 0.3 в X3 0.2 в X2 А получил : `| x1 | x2 | x3 | | 0.1 | 0.3 | 0.2 |`

И мне кажется до релиза 1.1.54245 было другое поведени CH

Да, мы это меняли, хотя уже довольно давно - несколько релизов назад. Новое поведение больше соответствует стандарту - соответствие столбцов при INSERT SELECT определяется только позициями.

Ух... печаль тостка... жаль нет переключателя ((((

У меня просто insert select ручные по 100 колонок, и я понял что в одно ошибся местами x88 и x87 и оба float )

Понимаю. Да, это проблема.

Понимаю. Да, это проблема.

А теоритически - если поставить issue на возможность сделать _переключатель_ - не соответствоать стандарту - можно ожидать появления ?

Да, можно. Сейчас вспомню, насколько это сложно...

Это не очень сложная задача.

Спасибо! Поставлю, буду ждать появления фичи - просто потратил очень много сил на ошибку после обновления CH )))

А если в select секции и where секции использутся dictGetString(...), т.е. делается фильтр и выборка параметра из справочника, то обращение к справочнику будет один раз или два? Есть смысл как то костылять типа select dictGetString(...) as paramName ... where paramName = 'paramValue'?

Один раз. Все одинаковые выражения в запросе вычисляются единожды.

О! Супер! ) Спасибо за ответ!

Всем привет. Есть ли какие-то оганичения по количеству возвращаемых строк через HTTP для пользователя readonly? У пользоваетля квота - default, она вроде не имеет ограничений из коробки. Пытаюсь в табло через веб конектор выгрузить миллион записей. Сто тысяч получается выгружать

Всем привет. Есть ли какие-то оганичения по количеству возвращаемых строк через HTTP для пользователя readonly? У пользоваетля квота - default, она вроде не имеет ограничений из коробки. Пытаюсь в табло через веб конектор выгрузить миллион записей. Сто тысяч получается выгружать

Постоянно здесь про строки говорят. В ClickHouse терминология другая, не записи? Искренне интересно.

Постоянно здесь про строки говорят. В ClickHouse терминология другая, не записи? Искренне интересно.

Ну да, тут строка. Под записью, имхо, подразумевается действие, глагол.

Я думаю везде строки :)

Я думаю везде строки :)

Точно нет!

Ну ладно ) В Монге документы

Ну ладно ) В Монге документы

В любой RDBMS записи - records. В монге, да. Наверное здесь действительно такая терминология. Не вникал еще в КХ.

Всем привет. Есть ли какие-то оганичения по количеству возвращаемых строк через HTTP для пользователя readonly? У пользоваетля квота - default, она вроде не имеет ограничений из коробки. Пытаюсь в табло через веб конектор выгрузить миллион записей. Сто тысяч получается выгружать

max_rows_to_read

RDBMS Terminology: ... Row: A row (= tuple, entry or record) is a group of related data, for example the data of one subscription. ...

https://en.wikipedia.org/wiki/Relational_database#Terminology

Не нашел ничего о record

Не нашел ничего о record

Relational database term Tuple or record По твоей ссылке

Постоянно здесь про строки говорят. В ClickHouse терминология другая, не записи? Искренне интересно.

А чем смысл дискусии? Предлагаю всем заинтересованым создать отделный чат и обсудить

Но прошу заметить, что это используется как синоним, а основной термин все таки Row во многих источниках

А чем смысл дискусии? Предлагаю всем заинтересованым создать отделный чат и обсудить

Извиняюсь, спросил

А чем смысл дискусии? Предлагаю всем заинтересованым создать отделный чат и обсудить

А я ответил, собственно :)