Коллеги, вижу тут посты про графану, может кто подскажет, каким образом лучше сделать расчет метрик на базе таблицы КХ для нее. Натравливать графану на таблицу с сырыми данными, в моем понимании, не очень хорошо - поскольку при каждом изменении таймлайна последняя будет делать кучу селектов в таблицу для перестроения. Правильно ли понимаю, что лучшим вариантом будет подготовка данных для графаны в фоне в другой таблице внешними средствами? То есть каждую минуту внешний скрипт будет делать селект в основную таблицу, получать метрики за минуту, и класть их в другую таблицу в КХ, с которой уже будет работать графана.

Мы сырые в Summing пишем, время до 5 секунд транкейтим и движок сам в фоне агрегирует

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

поэтому тут агрегировать особо ничего не получится

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

Ну, мы их тоже с данных расчитываем, всегда можно что-то схлопнуть если есть однотипные события

Ну, мы их тоже с данных расчитываем, всегда можно что-то схлопнуть если есть однотипные события

я пробовал через AggregateMergeTree, там скорость выполнения падает больше, чем на 10% при обычном суммировании поля типа AggregateFunction

в сравнении с обычным MergeTree

+ данных у меня реально много (это IP-cессии, 40 полей)

кластер как у яндекса я себе позволить пока не могу :)

Ну, сделайте пару materialized View для метрик

Ну, сделайте пару materialized View для метрик

есть где то более детальное описание, чем в доке? А то там ссылка смотри CREATE MATERIALIZE VIEW, самой страницы нет

Коллеги, вижу тут посты про графану, может кто подскажет, каким образом лучше сделать расчет метрик на базе таблицы КХ для нее. Натравливать графану на таблицу с сырыми данными, в моем понимании, не очень хорошо - поскольку при каждом изменении таймлайна последняя будет делать кучу селектов в таблицу для перестроения. Правильно ли понимаю, что лучшим вариантом будет подготовка данных для графаны в фоне в другой таблице внешними средствами? То есть каждую минуту внешний скрипт будет делать селект в основную таблицу, получать метрики за минуту, и класть их в другую таблицу в КХ, с которой уже будет работать графана.

Как правильно заметили, Вы можете сделать view специально для графиков. Так же, если Вы будете использовать https://github.com/Vertamedia/chproxy, то сможете настроить лимиты по выполнению запросов из графаны. Например, не больше 2 запросо одновременно, не больше 20 сек на выполнение. Так же можно настроить кеширование результатов запроса и округление запрашиваемого периода времени до 10мин, например. Более подробно здесь - https://github.com/Vertamedia/clickhouse-grafana#chproxy-optional От себя скажу, что мы постоянно смотрим сырые данные непосредственно ч-з графану

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

единственный пикатнтный момент - найти описание самой вьюшки :)

единственный пикатнтный момент - найти описание самой вьюшки :)

https://clickhouse.yandex/docs/en/single/#create-view

Спасибо!

Единственный минус вьюшек сейчас - отсутствие под запросов :(

все-таки, в заголовке не совсем правда про то, что кликхаус не тормозит (ниже — график LA на машине с кликхаусом)

;) тормозит все, если нагрузить сверхмеры

в него вливается всего порядка 500 мбит/сек батчами по 1 мб

в буфер-таблицу

Просто не нужно использовать буфер-таблицы (с) А что мешает сразу в MergeTree лить ?

Просто не нужно использовать буфер-таблицы (с) А что мешает сразу в MergeTree лить ?

потому что мы хотим очень много вставок в секунду. сильно больше 1

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

потому что мы хотим очень много вставок в секунду. сильно больше 1

в чем проблема батчить большими кусками, но редко?

в чем проблема батчить большими кусками, но редко?

на каждой машине так и делается

их просто очень много :)

А как же старая добрая рабочая схема: валим все в Кафку, а от туда пачками растаскиваем в сервера КХ?

А как же старая добрая рабочая схема: валим все в Кафку, а от туда пачками растаскиваем в сервера КХ?

для этого нужна кафка :)

Всем известно, что в кх не стоит лить данные частыми малыми инсертами, но кто-то решает это сделать, и заявить что он тормозит. Это фича такая у базы, тормозить на таком юзкейсе :)

Всем известно, что в кх не стоит лить данные частыми малыми инсертами, но кто-то решает это сделать, и заявить что он тормозит. Это фича такая у базы, тормозить на таком юзкейсе :)

ну ок, пусть тормозит. Но LA 1600-то зачем?

мы ведь не в MergeTree льем :)

странно, что вы это сваливаете на кх :)

просто у вас слабое железо

просто у вас слабое железо

да нормальное вроде :)

Если не КХ и не железо тогда что?

@yourock88 В общем не стоит так делать, КХ, на данный момент, так работать не может. Нужно искать пути как увеличить размер батча и уменьшить количество пишущих в него. Если Кафка не вариант, то что-то ведь похожее должно у вас быть?

@yourock88 В общем не стоит так делать, КХ, на данный момент, так работать не может. Нужно искать пути как увеличить размер батча и уменьшить количество пишущих в него. Если Кафка не вариант, то что-то ведь похожее должно у вас быть?

Я не утверждаю, что это не вариант :). Мы хотели бы пока что попробовать без кафки. Насколько я знаю, аналога у нас нет.

Написать свой батчер, делов на пару дней

Написать свой батчер, делов на пару дней

;) и потом еще мучений на пару лет, если невнимательно собрать =)

С чем мучения?

@yourock88 В общем не стоит так делать, КХ, на данный момент, так работать не может. Нужно искать пути как увеличить размер батча и уменьшить количество пишущих в него. Если Кафка не вариант, то что-то ведь похожее должно у вас быть?

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

С чем мучения?

с пограничными случаями "ой мы тут файловый дескриптов не закрыли" "ой а тут у нас пришел OOM и буфера не флашнулись" и еще много можно нафантазировать но я правильно понимаю что когда мы говорим "батчер" это мы имеем ввиду взяли много маленьких INSERT и потом сделали один большой ?

Типа того

с пограничными случаями "ой мы тут файловый дескриптов не закрыли" "ой а тут у нас пришел OOM и буфера не флашнулись" и еще много можно нафантазировать но я правильно понимаю что когда мы говорим "батчер" это мы имеем ввиду взяли много маленьких INSERT и потом сделали один большой ?

При отсутствии транзакций в кх, заморачиваться на это в батчере мне кажется не совсем правильно

всем привет, а есть какой-то подробный туториал с примерами про типы таблиц в CH?

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

Как вариант, но Юра писал что у них с этим тоже проблемы

всем привет, а есть какой-то подробный туториал с примерами про типы таблиц в CH?

Подробнее чем https://clickhouse.yandex/docs/en/table_engines/index.html ?

ага

https://github.com/yandex/ClickHouse/tree/master/dbms/src/Storages ;)

Как вариант, но Юра писал что у них с этим тоже проблемы

Мы с Юрой как раз этим и заняты. Вместе)

Просто не очень хочется лить батчами по сотни мегабайт. Но, видимо, к этому можем и придти.

Батчевать мы можем на любой размер, но хочется ещё и приемлемый latency иметь.

@yourock88 У нас несколько сот батчей в минуту в минуту и все ок. если довести хотя бы до тысячи то начинают сыпаться ошибкаи Too many parts to merge. Вам надо попробывать просто собирать таки батчи побольше и страться придерживаться 1 батч - 1 партишн

что это у вас за график? инсерты в минуту? что вы имеете ввиду под LA?

https://ru.wikipedia.org/wiki/Load_Average

ага понял. Спасибо @vasya_toropov

@yourock88 а как вы данные загружаете в каком формате? сжимаете?

Просто не очень хочется лить батчами по сотни мегабайт. Но, видимо, к этому можем и придти.

Ну, еще можно просто шардов накинуть и писать в разные. Странно что у вас нет ничего похожего на Кафку, что сильно бы упростило вам жизнь (или наоборот:))

Какая-нибудь Kitten-Kafka )

Ну, еще можно просто шардов накинуть и писать в разные. Странно что у вас нет ничего похожего на Кафку, что сильно бы упростило вам жизнь (или наоборот:))

У нас локальная персистентная прокся на каждом сервере. Они батчат отдельные инсерты и потом уже льют в КХ. Но последний стоит к syscpu, а не user/iowait. Так что попробуем батчами того же размера но в меньшее число коннектов, чтобы столько потоков КХ не запускал.

Какая-нибудь Kitten-Kafka )

Не, не, не. Вот ничего такого не хочется.

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

Парни полдня разбираемся... делаем инсерты в базу, небольшое количество строк заходит всегда одинаково. и суммы по колонкам (клики и показы) одинаковая. Когда объем вставляемых данных увеличиваем с 30000 до 60000 строк, по итогу количество строк в норме, но суммы кликов и показов отличаются. запросы на вывод сумм даже не меняем. вставляем по 500. При этом несколько раз вставляли (60000) одни и теже строки и всегда по разному суммы кликов и показов... полтергест.... помогите плиз...

У нас локальная персистентная прокся на каждом сервере. Они батчат отдельные инсерты и потом уже льют в КХ. Но последний стоит к syscpu, а не user/iowait. Так что попробуем батчами того же размера но в меньшее число коннектов, чтобы столько потоков КХ не запускал.

Если серверов много всёравно наткнетесь что в какой-то момент одновременно все писать будут

Ну и доброго дня всем)

Так мы через nginx сейчас собираем) И лимиты на коннекты в апстримы

Помогите разобраться как работает Sign в CollapsingMergeTree. Он должен быть -1 ил и1, но кто его должен менять. Мне его указывать при вставке, или движок сам управляет этим значением?

указывать при вставке

А когда оно станет равным -1? Я же не могу менять его.

Или можно всегда указывать 1 и он будет схлапывать по этому признаку?

Строчку с тем же ключем записать, но с -1

Или можно всегда указывать 1 и он будет схлапывать по этому признаку?

Он будет первую оставлять

Допустим я не знаю, вставляю ли я дубль или нет. Всталять Sign = -1?

Но знаю, что он дожен заменить предыдущую запись

CollapsingMergeTree нужен когда точно знаете что нужно заменить запись, в противном случае просто лейте в MergeTree с дублями потом разберетесь

ну ок, пусть тормозит. Но LA 1600-то зачем?

это к линусу

CollapsingMergeTree нужен когда точно знаете что нужно заменить запись, в противном случае просто лейте в MergeTree с дублями потом разберетесь

Я точно знаю что нужно ее заменить. Но если у нее уже установлен Sign = 1. Но я считаю ее устаревшей, я не могу поменять ее Sign на -1. Видимо я не совсем понимаю смысла термина "старое значение". Ведь когда оно вставлялось вчера, на тот момент оно было новым.

Я точно знаю что нужно ее заменить. Но если у нее уже установлен Sign = 1. Но я считаю ее устаревшей, я не могу поменять ее Sign на -1. Видимо я не совсем понимаю смысла термина "старое значение". Ведь когда оно вставлялось вчера, на тот момент оно было новым.

Там есть ключ (то что вторым параметром при создании указывается в скобках или ORDER BY в новом синтаксисе партиций) и могут быть какие-то еще данные (колонки), вот чтоб "затереть" строку нужно вставить данные с темже ключем + Sign = -1

при мердже КХ удалит строку с Sign=1

Спасибо!

А если я вставлю sign=1, и у меня уже есть уже есть sign=1?

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