Я с телефона, долго искать, настройка называется примерно: max bytes before external group by.

Спасибо, попробую

ClickHouse Meetup в Санкт-Петербурге: https://events.yandex.ru/events/ClickHouse/16-aug-2018/ Открываем регистрацию.

???

ClickHouse Meetup в Санкт-Петербурге: https://events.yandex.ru/events/ClickHouse/16-aug-2018/ Открываем регистрацию.

В Бенуа будет?

Да (если за месяц ничего не изменится)

?

а как таблицу то апдейтить ?

Как именно вы хотите её "апдейтить"?

кто пробывал запустить pentaho olap server(mondrian) в связке с ClickHouse?

кто пробывал запустить pentaho olap server(mondrian) в связке с ClickHouse?

Не пробовали, но в планах есть

Делаю запрос "rename table db_name.table_name to db_name.old_table_name". Получаю ошибку File not found: /var/lib/clickhouse//data/db_name/old_table_name Как так? Зачем он ищет файл таблицы, которой еще нет?

А полный трейс можно? Может быть попытка создать директорию провалилась. И какие файлы-директории есть с old в data и metadata ?

всем привет! подскажите, пожалуйста, насколько clickhouse подходит для хранения метрик IoT устройств во времени? то есть можно ли (есть ли смысл) использовать ее как time-series базу данных? Стоит задача - хранить метрики и делать выборки во времени с возможностью аггрегации данных. Например, выбрать показание температуры за год с определенной дискретностью (шагом) и применением функции усреднения (макс, мин) промежуточных значений

всем привет! подскажите, пожалуйста, насколько clickhouse подходит для хранения метрик IoT устройств во времени? то есть можно ли (есть ли смысл) использовать ее как time-series базу данных? Стоит задача - хранить метрики и делать выборки во времени с возможностью аггрегации данных. Например, выбрать показание температуры за год с определенной дискретностью (шагом) и применением функции усреднения (макс, мин) промежуточных значений

Идеально подходит ИМХО.

В метрике ж тоже «метрики» и «выборки по времени с аггригацией»

нужно сделать выборку типа: (на примере запроса из Timescale) SELECT time_bucket('15 minutes', time) AS fifteen_min, location, COUNT(*), MAX(temperature) AS max_temp, MAX(humidity) AS max_hum FROM conditions WHERE time > NOW() - interval '3 hours' GROUP BY fifteen_min, location ORDER BY fifteen_min DESC, max_temp DESC;

всем привет! подскажите, пожалуйста, насколько clickhouse подходит для хранения метрик IoT устройств во времени? то есть можно ли (есть ли смысл) использовать ее как time-series базу данных? Стоит задача - хранить метрики и делать выборки во времени с возможностью аггрегации данных. Например, выбрать показание температуры за год с определенной дискретностью (шагом) и применением функции усреднения (макс, мин) промежуточных значений

температурные измерения обычно не предполагают больших объемов данных )) у вас десятки миллионов?

температура, давление, влажность, шум, вибрация...и т.д. в общем более 1000 метрик в секунду

в timescale набегает более 1 Gb в день

гигабайты тут не канают, если есть куда их сложить ?

Вот то, что 1000 метрик в секунду - может иметь значение. Там потребуется посредник, который их сложит в один батч и будет засовывать в базу большими кусками

в timescale набегает более 1 Gb в день

CH их еще пожмет и может вообще оказаться что в нем это всего лишь 100-200 Mb ?

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

Огромное - это сколько?

60*60*24*365=31536000 по каждому сенсору в год

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

Если у вас есть понимание уровней аггрегации. Т.е. например вы 100% уверены что вы при запросе за год, аггрегируете по месяцу/неделе/дню то можно рядышком поставить MAT VIEW с двидком AggregatingMegreTree и тогда у вас будет быстрая таблица с атоаггрегацией и прочими прелестями

температура, давление, влажность, шум, вибрация...и т.д. в общем более 1000 метрик в секунду

а что измеряете если не секрет?

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

понятно

а как решаете вопрос с разнородными сенсорами?

нужно сделать выборку типа: (на примере запроса из Timescale) SELECT time_bucket('15 minutes', time) AS fifteen_min, location, COUNT(*), MAX(temperature) AS max_temp, MAX(humidity) AS max_hum FROM conditions WHERE time > NOW() - interval '3 hours' GROUP BY fifteen_min, location ORDER BY fifteen_min DESC, max_temp DESC;

Для описанной задачи кликхаус подходит, более того это именно то для чего он придуман. Запрос с минимальными изменениями будет работать, и почти наверняка будет работать быстрее чем вы можете ожидать :) можете потом какие-то цифры для сравнения скорости кликхауса и таймскалы написать на ваших данных, т.к. вроде пока сравнения никто не делал.

30 млн значений в год с сенсора - это для кликхауса не страшные цифры. В Яндексе - сотни тысяч / миллионы событий в секунду. На одном среднем сервере с кликхаусом можно с относительно небольшими задержками (десятки секунд-минуты) делать аналитику для миллиардов записей. Если допустимы задержки в минуты / десятки минут - то можно и десятки миллиардов данных перемалывать на одном сервере. Если ответы на запросы нужны без видимых задержек - то потребуется больше одного сервера (с шардингом), или преагрегация данных. Но для начала - попробуйте на одном сервере.

Всем привет, я немного подзастрял, и буду очень благодарен за пинок в нужном направлении, допустим я пишу в Clickhouse статистику по http кодам, в виде инкрементных каунтеров и хочу посчитать rate при помощи runningDifference() если я беру к примеру и ставлю в where http_code = code и считаю по одному коду, все отлично, но если кодов больше 1 никакой group by не спасает, и функция считает дельту между каунтерами разных кодов.

https://github.com/yandex/ClickHouse/issues/2590 вот сюда посмотрите. там и пример кода есть. фикс уже выкатили рабочий, но надо либо релиза ждать, либо из исходников собирать

А здесь есть кто-нибудь, раскативший ClickHouse на c5-инстансах в AWS? Вам норм живётся, машины не висят?

а что с ними должно быть не так ?

вообще в амазоне не висят машины

Во-первых, у m5 и c5 была (есть?) хитрая бага, которая зимой косила ряды. Там в случае с интенсивной работы i/o машина просто висла. Мы на это напоролись, пошли форумы читать амазоновые, оказались не уникальными. Ровно та же фигня, ровно на m5/c5 у ряда контор выстрелила. Во-вторых... Скажу словами поддержки Amazon, когда у нас за одну неделю три инстанса ушли в небеса: "железо иногда ломается".

Т.ч. про "не висят" не надо. :)

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

В теории да. На практике "любой момент" не должен означать регулярные частые проблемы. И мой вопрос про актуальный опыт с c5 был именно об этом.

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

Просто мы на нём давно живём.

Привет Сервер упал с таким сообщением в логе: https://pastebin.com/cbAtw3b1

это с чего он так?

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

Облака... белогривые лошадки :) Главная проблема железа - оно медленно прибавляется / убавляется, и железные проблемы (типа упавший диск) становятся проблемами которые нужно решать тебе самостоятельно или в "полуручном" режиме (руками админов ДЦ). В случае AWS об этом голова не будет болеть, зато может болеть о каких-то других (порой странных) вещах - типа cpu throttle, роскомнадзор, какие-то неожиданные для тебя работы в ДЦ с рестартом серверов и т.п.

...или с оплатой траффика) Что нас пока останавливает

Там межзональный дорогой, остальные терпимо. Но зависит от, конечно.

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

Привет Сервер упал с таким сообщением в логе: https://pastebin.com/cbAtw3b1

какая версия? какие были запросы? как часто бывает?

какая версия? какие были запросы? как часто бывает?

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

Облака... белогривые лошадки :) Главная проблема железа - оно медленно прибавляется / убавляется, и железные проблемы (типа упавший диск) становятся проблемами которые нужно решать тебе самостоятельно или в "полуручном" режиме (руками админов ДЦ). В случае AWS об этом голова не будет болеть, зато может болеть о каких-то других (порой странных) вещах - типа cpu throttle, роскомнадзор, какие-то неожиданные для тебя работы в ДЦ с рестартом серверов и т.п.

> В случае AWS об этом голова не будет болеть вот эта фраза всё таки у меня вызывает легкий скепсис =) Не, бесспорно пара минут на запуск в амазоне против 3 дней ожидания кастомной конфигурации — это разница. Но вот сколько будет стоить двухголовый E5 с 8 SSD на 500 Гб в амазоне? Полагаю, что сильно дороже, чем беру я

Яндекс скоро облако с ClickHouse выкатит, наверное подешевле будет

Сильно это мягко сказано. Один порядок разницы будет точно:)

> В случае AWS об этом голова не будет болеть вот эта фраза всё таки у меня вызывает легкий скепсис =) Не, бесспорно пара минут на запуск в амазоне против 3 дней ожидания кастомной конфигурации — это разница. Но вот сколько будет стоить двухголовый E5 с 8 SSD на 500 Гб в амазоне? Полагаю, что сильно дороже, чем беру я

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

Яндекс скоро облако с ClickHouse выкатит, наверное подешевле будет

И Алиса заговорит словами ваших клиентов ?

> В случае AWS об этом голова не будет болеть вот эта фраза всё таки у меня вызывает легкий скепсис =) Не, бесспорно пара минут на запуск в амазоне против 3 дней ожидания кастомной конфигурации — это разница. Но вот сколько будет стоить двухголовый E5 с 8 SSD на 500 Гб в амазоне? Полагаю, что сильно дороже, чем беру я

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

Но в кликхаусе на самом деле это сложновато...

Но в кликхаусе на самом деле это сложновато...

вот я именно в контексте кликхауса. Плюс как ни верти, а хочется покупать не только абстрактную бесконечную масштабируемость, а ещё и хорошее время отклика

Кликхаус не удобен в динамическом расширении и сужении. Много ручной работы требует из-за того что серверы - участиники сети не сами в сети регистрируются, а вручную добавляются в конфиги.

Коллеги, подскажите плиз, никак не могу загрузить внешний словарь из pgsql, dsn создан по ману, через isql туда нормально заходит. конфиг сделал с именем xxx_dictionaries.xml, положил в conf.d, при изменении КХ его перечитывает (в логах есть упоминания), ошибок нет, но и в system.dictionaries пусто. Куда посмотреть еще? КХ перезагружать очень уж не хочется

А как настроен <dictionaries_config> ?

Он по умолчанию не ищет конфиги словарей в conf.d.

только на верхнем уровне файлы словарей читает (т.е. если не изменяли <dictionaries_config> то конфиги словарей должны лежать просто в /etc/clickhouse-server/ )

И ещё сам файл с конфигурацией словаря - лучше всего обернуть тэгами <yandex>. Типа такого: <?xml version="1.0"?> <yandex> <comment>...</comment> <dictionary> <name>...</name> ... </dictionary> </yandex>

только на верхнем уровне файлы словарей читает (т.е. если не изменяли <dictionaries_config> то конфиги словарей должны лежать просто в /etc/clickhouse-server/ )

аа, вот в чем дело, dictionaries_config дифолтный :) Спасибо

И ещё сам файл с конфигурацией словаря - лучше всего обернуть тэгами <yandex>. Типа такого: <?xml version="1.0"?> <yandex> <comment>...</comment> <dictionary> <name>...</name> ... </dictionary> </yandex>

https://pastebin.com/7ufK6MNK конфиг, dictionaries_config дефолтный, в лог сыпет <Warning> ExternalDictionaries: /etc/clickhouse-server/dnl_dictionary.xml: unknown node in file: 'listen_host', expected 'dictionary' и тому подобное, как будто структура xml порушена, уже голову сломал - не могу понять где

Хм. Хз. Попробуйте <dictionaries_config>dictionaries/*.xml</dictionaries_config> , создать папку /etc/clickhouse-server/dictionaries (обратите внимание на chmod / acl, чтоб кликхаус мог оттуда читать/писать), и переложите туда ваш файл.

Так вообще не реагирует на файл словарей :) Чудеса

а что у вас вообще прописано в /etc/clickhouse-server/config.xml, в настройке dictionaries_config?

а что у вас вообще прописано в /etc/clickhouse-server/config.xml, в настройке dictionaries_config?

config.xml дифолтный, не трогаю его

Так вообще не реагирует на файл словарей :) Чудеса

а, изменение <dictionaries_config> скорее всего требует рестарта

Всем добрый день! А кто чем мониторит ch?

а, изменение <dictionaries_config> скорее всего требует рестарта

так я могу положить кофиг словаря наверх, и он его видит - но ошибки пишет

Всем добрый день! А кто чем мониторит ch?

icinga - рабочие процессы, память, диски, grafana - уже более детальные данные

/me потянулся за бубном.

Попробуйте тэги <yandex> в начале и конце заменить на <dictionaries>

А что в файле -processed?

icinga - рабочие процессы, память, диски, grafana - уже более детальные данные

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

Коллеги, подскажите пожалуйста есть кластер кликхауса с 2 шардами и двумя репликами создана distributed таблица в случае если один из четырёх инстансов кликхауса недоступен, то запись в distributed таблицу через гошный клиент github.com/kshvakov/clickhouse не работает в качестве ошибки пишет 'dial tcp 127.0.0.1:9012: connect: connection refused' при этом в другой инсталяции кликхауса при потере одного инстанса запись продолжается без ошибок подскажите пожалуйста по какой причине такое может происходить?

А что в файле -processed?

В preprocessed помимо нужного еще куча всего дописывается из других вставок из conf.d (конф зукипера и прочее). на вот эти лишние параметры как раз и ругается конфиг-парсер

Files used to generate this file: /etc/clickhouse-server/dnl_dictionary.xml /etc/clickhouse-server/conf.d/listen_hosts.xml /etc/clickhouse-server/conf.d/logger.xml /etc/clickhouse-server/conf.d/memory.xml /etc/clickhouse-server/conf.d/settings.xml /etc/clickhouse-server/conf.d/zookeeper.xml /etc/metrika.xml -->

config.xml дифолтный, не трогаю его

<dictionaries_config>*_dictionary.xml</dictionaries_config>

да все так

у вас файлик же называется dnl_dictionary.xml

пральна?