Какой у вас рейт запросов?

более того, такие зависания блокируют остановку сервиса, только kill -9 и помогает

Grafana уже напрямую в CH ходить может? А то тут описывалось через графен.

Коллеги, привет. Кому удалось реализовать bulk заливку данных в КликХаус с помощью Pentaho Data Integration? Обычные Table Output и Execute SQL Script льют по одной записи и крайне медленно. Данные беру из PostgreSQL.

не-не, продолжайте про графану и КХ.

https://github.com/Vertamedia/clickhouse-grafana

https://github.com/Vertamedia/clickhouse-grafana

Т.е. напрямую прикручивается? Это видел.

Т.е. напрямую прикручивается? Это видел.

А что именно Вас интересует?

Извиняюсь за hijacking вопроса, но..

Возможно составлять query с учетом сортировки по avg \ current ?

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

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

Да, благодарю вас. Видится, тем не менее, примерно следующее кратко: $columns( request, count(*) c) FROM $table ORDER BY current DESC с тем, чтобы без 'show legend' сразу было отображение с сортировкой

Мне видится это малореальным, конечно..

Мне видится это малореальным, конечно..

если Вы посмотрите на генерируемый макросом $columns запрос, то увидите, что сортировка идет по времени. И это обязательно, т.к. Вы отображаете временной график. Вы можете не использовать этот макрос и написать кастомный запрос, который отобразит так, как Вам нужно. Но выше правильно заметили, что наиболее оптимальный способ - сортировать легенду на стороне графаны

если Вы посмотрите на генерируемый макросом $columns запрос, то увидите, что сортировка идет по времени. И это обязательно, т.к. Вы отображаете временной график. Вы можете не использовать этот макрос и написать кастомный запрос, который отобразит так, как Вам нужно. Но выше правильно заметили, что наиболее оптимальный способ - сортировать легенду на стороне графаны

Спасибо за развернутый ответ. Так примерно и есть, операторы видят в плагине аналог tabix`а со всеми вытекающими последствиями)

судя по графику, нужно использовать $rateColumns вместо $columns

тогда на графике получите requests per second

судя по графику, нужно использовать $rateColumns вместо $columns

Спасибо.

Добрый день, коллеги. Подскажите, пожалуйста, насколько реально конвертировать postgres-hll формат HLL в Clickhouse формат uniqHLL12x или uniq? Посмотрев код, я так понимаю они не совместимы, но возможно есть способ конвертации. Спецификация HLL, которую использует postgres-hll - https://github.com/aggregateknowledge/hll-storage-spec/blob/master/STORAGE.md Необходимо мигрировать порядка 100ТБ данных, с сохранением уникальных элементов.

Всем привет, проапгрейдили кластер, и унас не исчезают внутренние запросы, кластер не может стабилизироваться. Обновили все ноды до 1.1.54245. Что можно с этим сделать?

а что такое uniqHLL12x?

аггрегирующая функция для хранения уникальных значений в HyperLogLog структуре

https://clickhouse.yandex/docs/en/agg_functions/index.html

постгресовый HLL вроде как довольно понятный, он может хранить состояние подсчета. в CH uniqHLL12(x) - это агрегатная функция, её состояние существует только во время выполнения запроса. Если я все правильно понял

она не для хранения ведь?

оно применит HLL пробегая по значениям

В ClickHouse можно сохранять состояние любой агрегатной функции :)

если используется Materilized Views, то насколько я понял - нет, будет именно хранить эти значения. Но я могу ошибаться.

т.е. мы хотим импортировать старые данные напрямую в Materialized View, а новые будут считаться с "сырых" данных в Clickhouse

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

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

В ClickHouse можно сохранять состояние любой агрегатной функции :)

промежуточное состояние? или результат?

ну типа загрузить данные в CH и посчитать агрегат заново.

если уж вы данные собираетесь загрузить - то посчитать по ним hll - не проблема

Промежуточное состояние: https://clickhouse.yandex/docs/ru/agg_functions/index.html#state

mat view - оно ведь view чего-то

Промежуточное состояние: https://clickhouse.yandex/docs/ru/agg_functions/index.html#state

спасибо, понял о чем речь

ну типа загрузить данные в CH и посчитать агрегат заново.

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

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

а агрегаты сложные? В дальнейшем планируете считать через mat view?

в основном это суммы значений, но есть и десяток hstore, т.е. map ключ-значение

да, в дальнейшем все новые данные считаться через mat view

да, в дальнейшем все новые данные считаться через mat view

Тогда просто можно залить текущие агрегированные данные в таблицу сырых данных. Они будут начальными значениями для view

в доке CH написано "Используется 212 5-битовых ячеек. Размер состояния чуть больше 2.5 КБ"? в постгресовом HLL может оказаться любое количество регистров с любой битовой размерностью

Тогда просто можно залить текущие агрегированные данные в таблицу сырых данных. Они будут начальными значениями для view

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

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

что значит с уникальными значениями?

в доке CH написано "Используется 212 5-битовых ячеек. Размер состояния чуть больше 2.5 КБ"? в постгресовом HLL может оказаться любое количество регистров с любой битовой размерностью

верно, в постгресовом в том числе SPARSED формат может быть, но дефолтное hll(log2m=11, regwidth=5, expthresh=-1, sparseon=1)

что значит с уникальными значениями?

есть тип данных в postgres - hll, мы храним уникальные IP используя этот тип данных в агрегации

есть тип данных в postgres - hll, мы храним уникальные IP используя этот тип данных в агрегации

Юзер кейс для ClickHouse - не хранить агрегаты, а считать реалтайм каждый раз при запросе

увы, при достаточно большом объеме данных, нет возможности хранить "окно" данных больше чем 2-3 месяца но агрегаты должны быть доступны за 1 год+

7M records/s

увы, при достаточно большом объеме данных, нет возможности хранить "окно" данных больше чем 2-3 месяца но агрегаты должны быть доступны за 1 год+

В Яндекс Метрике хранят и считают https://clickhouse.yandex/docs/ru/introduction/ya_metrika_task.html. Возможно что-то делаете не так. Посмотрите в сторону https://clickhouse.yandex/docs/ru/table_engines/aggregatingmergetree.html

верно, в постгресовом в том числе SPARSED формат может быть, но дефолтное hll(log2m=11, regwidth=5, expthresh=-1, sparseon=1)

Вывод hll12()-State ведь текстовый? Можно просто посмотреть что оно там хранит?

В Яндексе метрике всего 20,3 триллионов строк. При скорости 7M/s этот объем заполняется за 33 дня. Увы нам надо больше чем 33 дня. О различных структурах в Clickhouse читал, разбирался.

11 у постгреса подозрительно похоже на 12 :)

Вывод hll12()-State ведь текстовый? Можно просто посмотреть что оно там хранит?

вот как это выглядит в postgres - https://pastebin.com/jbCqz5Ed

при увеличении количества элементов postgres меняет формат хранения, видно по первым байтам

Не, с пг то мне понятно

А что возвращает CH?

В виде промежуточного агрегата -State

─hex(toString(uniquesIPv4))─┬─runningAccumulate(uniquesIPv4)─┐ │ 00019799D8DE │ 1 │ └────────────────────────────┴────────────────────────────────┘

ERROR: S client not available

что-то такое CH возвращает

Понятно, какая-то внутренняя бинарная фигня...

Судя по доке там на 2,5кб должно быть

У вас интересный кейс, 7M/s инсертов.

А тут 6 байт

У вас интересный кейс, 7M/s инсертов.

Это не только у него. + данные за 3 года.

Три года в секунду?

7м записей в секунду, данные за 3 года.

Сжатые в gzip tsv минутные агрегаты занимают всего 25ТБ, а вот хранить сырые данные при скорости 7М/s можем пока позволить хранить только 3 месяца. Дальше планируется увеличить этот срок.

даже при такой хорошем сжатии, что предоставляет Clickhouse

Сжатые в gzip tsv минутные агрегаты занимают всего 25ТБ, а вот хранить сырые данные при скорости 7М/s можем пока позволить хранить только 3 месяца. Дальше планируется увеличить этот срок.

Это каждая минута пакуется? По идее упаковка дня ещё уменьшит. Хотя конечно смотря какие данные.

Да, каждая минута пакуется, дальше пакуется в часы, часы в дни, дни в месяца. По крайней мере в текущей системе. С Clickhouse хотим хранить сырые данные за 3 месяца, а агрегированные минутные - бесконечно.

@the_real_jkee @milovidov_an стоит сюда привести бота, который будет в момент когда вы тэгаете релизы (тестинг-стейбл) сюда ссылку на тэг присылать?

Конечно.

Если такой есть

И было бы не плохо все таки changelog какой то видеть и release notes :)

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

/subscribe yandex/ClickHouse all

/subscribe yandex/ClickHouse all

Success!

@the_real_jkee должен теперь оповещать )

Срочно релиз делаем

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

а, ну еще так как он делает poll, то оповещения с задержкой до 30 минут будут )

/subscribe requires exactly 2 arguments

Ярик, не трогай бота :)

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

но пока в todo :)

само получилось, по ссылке проманулся ?

/subscribe yandex/ClickHouse all

/subscribe yandex/ClickHouse all

Already subscribed