Алексей, спасибо большое.

кстати в select * from system.functions order by name она есть - надо еще посмотреть какие там функции недокументированные полезные :)

да, мне Игорь из СМИ2 уже открыл глаза ))

а что за сми2?

https://github.com/smi2

а, нет. я вспомнил, arrayUniq считает кол-во уникальных элементов, а не их значения

Можно написать через arrayFilter и arrayEnumerateUniq. Или arrayReduce('groupUniqArray', arr).

ага, я так и сделал вроде в итоге.. просто вспомнилось, что нет отдельной. спасибо!

кстати в select * from system.functions order by name она есть - надо еще посмотреть какие там функции недокументированные полезные :)

+1

Тут есть создатели clickhouse-grafana?

как я понял это кто-то англоговорящий, вряд ли тут до них достучаться можно

Тут есть создатели clickhouse-grafana?

Это из дружественного государства Aliaksandr Valialkin ( https://github.com/valyala ), сомневаюсь что он тут есть.

по какой причине метрика ClickHouse.ProfileEvents.MergesTime в графите может резко вырасти?

Это из дружественного государства Aliaksandr Valialkin ( https://github.com/valyala ), сомневаюсь что он тут есть.

ага, уже нашел их в слаке)

Здравствуйте.

У меня возник странный вопрос/проблема.

# clickhouse-client --port 3306 -m ClickHouse client version 1.1.54127. Connecting to localhost:3306. Connected to ClickHouse server version 1.1.54127. :) SELECT 1 :-] ; SELECT 1 ??1?

На последней строчке умирает сам клиент и консоль.

ОС Дебиан wheezy.

если сделать clickhouse-client --port 3306 -E, то за 10 секунд выдает единицу.

И не виснет!

# clickhouse-client --port 3306 -E ClickHouse client version 1.1.54127. Connecting to localhost:3306. Connected to ClickHouse server version 1.1.54127. :) SELECT 1; SELECT 1 Row 1: ?????? 1: 1 1 rows in set. Elapsed: 10.025 sec.

если авторы смогут объяснить такое поведение, буду благодарен.

Кажется, я понял. Если СУБД не может отрезолвить hostname, то почему-то виснет на простых вещах, вроде DESC или select 1.

Наверное, не сильно баг, но как-то неприятно.

возможно оно бекрезолвит того, кто подключился?

В моем случае все разрешилось прописыванием имени хоста в hosts

ну, это вообще элемент чистоплотности: хостнейм всегда должен резолвиться

Разве? Кому должен?

Я не буду незнакомому человеку из интернета это доказывать =)

получить по ip клиента его хостнейм нужно, чтобы проверить правила доступа, основанные на хостнеймах

у вас в users.xml случайно нет чего-то такого?

Насколько я помню, DNS резолвится только один раз, при соединении. Во время запроса не должен.

по какой причине метрика ClickHouse.ProfileEvents.MergesTime в графите может резко вырасти?

Насколько я помню, мы добавили MergesTime в последнем релизе. Раньше его просто не было. А если периодически растёт после этого - наверное система решила больше помержить (дошла до мержа большого куска). Если покажете график - может быть что-нибудь станет понятно.

у вас в users.xml случайно нет чего-то такого?

У меня все дефолтные конфиги. Спасибо за объяснение про права. Это вполне вменяемо. Хотя кажется, что правильно по дефолту считать, что субд живет на локалхосте, который точно резолвиться.

У меня все дефолтные конфиги. Спасибо за объяснение про права. Это вполне вменяемо. Хотя кажется, что правильно по дефолту считать, что субд живет на локалхосте, который точно резолвиться.

DNS запрос при соединении делается лишь в том случае, если в users.xml в списке сетей указано DNS имя или шаблон на него. Но по-умолчанию это не так. Также там рядом присутствует комментарий, который это объясняет. И ещё, я вспомнил, что даже в этом случае, DNS запрос будет делаться не при каждом соединении, а только один раз. Проверить можно с помощью strace -f -e trace=network -p $(pidof clickhouse-server) либо с помощью tcpdump.

ребят, подскажите,а можно раннингдифференц заставить как-то обнулять результаты в рамках условия. Ну т е у нас есть например id_проекта, id_сессии, и таймстэмпы. Хочется чтобы раннингдифференц выдавал разницу времени только в пределах сессии. Если сессия другая, то считал заного. В новой сессии соответственно первая дельта должна быть равна нулю

одним запросом можно сделать ? )

DNS запрос при соединении делается лишь в том случае, если в users.xml в списке сетей указано DNS имя или шаблон на него. Но по-умолчанию это не так. Также там рядом присутствует комментарий, который это объясняет. И ещё, я вспомнил, что даже в этом случае, DNS запрос будет делаться не при каждом соединении, а только один раз. Проверить можно с помощью strace -f -e trace=network -p $(pidof clickhouse-server) либо с помощью tcpdump.

Вероятно. Но в моем случае умирал именно клиент и сама консоль. Что совсем не очевидно почему.

ребят, подскажите,а можно раннингдифференц заставить как-то обнулять результаты в рамках условия. Ну т е у нас есть например id_проекта, id_сессии, и таймстэмпы. Хочется чтобы раннингдифференц выдавал разницу времени только в пределах сессии. Если сессия другая, то считал заного. В новой сессии соответственно первая дельта должна быть равна нулю

Нет. Потребность понятна - это хороший FR. Также можно рассмотреть вариант - сделать функцию, которая считает difference массива. Тоже такого нет, но было бы полезно. Сейчас это можно получить только очень плохим способом, который я не буду приводить. Также замечу, что сейчас такого вида функции (как runningDifference) работают исходя из допущения, что данные подаются на вход последовательно. Но интерпретатор запроса нигде не берёт во внимание наличие таких функций. То есть, они работают "на птичьих правах", что меня беспокоит. Это значит, что в дальнейшем нужно будет делать доработки специально для такого класса функций.

Вероятно. Но в моем случае умирал именно клиент и сама консоль. Что совсем не очевидно почему.

Да, совсем неочевидно. А что значит, умирала консоль? Шелл (bash или другой?) что-нибудь писал (типа Killed, Aborted...)?

Не реагировал ни на что. Совсем.

Да, bash.

одним запросом можно сделать ? )

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

Алексей, понял. А что такое FR ? )

feature request

feature request

?

Алексей, подскажите, а вот по поводу этой особенности: https://groups.google.com/forum/#!topic/clickhouse/2JS_yzvYAHM не появилась еще возможность изменить поведедение ?

DB::Exception: Scalar subquery returned empty result, когда подзапрос возвращает 0 rows при group by

Ещё нет.

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

(я знаю только о недавно зачатом с++-клиенте от artpaul, но меня пайтон пока больше интересует)

Так вроде нигде нет описания протокола. А реверсинжинеринг - это не правильно.

Так вроде нигде нет описания протокола. А реверсинжинеринг - это не правильно.

Правильно, правильно. :) Я считаю, что вполне возможно, в относительно короткие сроки сделать клиента для текущей версии протокола. Что удобно, это не требует ни каких модификаций на стороне сервера. Потом, можно будет подумать о, например, grpc, через котороый можно и из С++ и из python взаимодействовать.

А udp есть в планах?

А udp есть в планах?

Насколько мне известно, нет. А почему хочется именно его? С ним же есть проблема, что он не гарантирует доставку всех пакетов, соответственно, придётся, кое-что надстраивать. Получится что-то похожее на tcp. В это есть и свои плюсы, но тут стоит идти от конкретных потребностей.

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

Да, нужно делать костыли поверх. Но что делать.

Вставляйте пачками тогда

В смысле ещё большими пачками

Постоянно отключаться и подключаться с пачки машин?

Если только сделать отдельного демона, который по udp будет пакеты ловить, в пакеты собирать и с некоторой периодичностью писать в CH

Ну, конечно, тоже вариант.

Если только сделать отдельного демона, который по udp будет пакеты ловить, в пакеты собирать и с некоторой периодичностью писать в CH

Вы говорите о прокси. А протокол описан где-то?

Насколько я помню, мы добавили MergesTime в последнем релизе. Раньше его просто не было. А если периодически растёт после этого - наверное система решила больше помержить (дошла до мержа большого куска). Если покажете график - может быть что-нибудь станет понятно.

http://www.awesomescreenshot.com/image/2034994/c5b94dc600c828021adb288306cab123 все три сервера идентичные и запись на них равномерная

О прокси.

Так можно и через http писать

Вы говорите о прокси. А протокол описан где-то?

Можно взять HTTP и rowbinary как компромис

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

Мы подумаем, но вряд ли это случится в обозримом будущем.

А кто-нибудь сталкивался с такой ошибкой при попытке ребутнуть кликхаус ?

sudo clickhouse-server restart POCO ERROR: File not found: config.xml File not found: config.xml

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

:O а через service не?

service clickhouse-server restart

блин, умственная усталость ))

Игорь, спасибо

Правильно, правильно. :) Я считаю, что вполне возможно, в относительно короткие сроки сделать клиента для текущей версии протокола. Что удобно, это не требует ни каких модификаций на стороне сервера. Потом, можно будет подумать о, например, grpc, через котороый можно и из С++ и из python взаимодействовать.

grpc - двумя руками. Со стриммингом и прочей расширяемостью. Но реверсинжинерить - это тратить массу времени на поддержку изменений. Потому - неправильно.

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

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

Доброго дня. Наблюдаю такую ошибку { "log": "2017.01.09 10:16:44.606 [ 7 ] <Error> sms.outbox (Merger): Part 20161209_20161210_147824_258681_584 intersects previous part\n", "stream": "stderr", "time": "2017-01-09T10:16:44.607102712Z" } Что могло привести к такому поведению и как с этим бороться?

Доброго дня. Наблюдаю такую ошибку { "log": "2017.01.09 10:16:44.606 [ 7 ] <Error> sms.outbox (Merger): Part 20161209_20161210_147824_258681_584 intersects previous part\n", "stream": "stderr", "time": "2017-01-09T10:16:44.607102712Z" } Что могло привести к такому поведению и как с этим бороться?

Такая проблема была в старых версиях с таблицами типа MergeTree, при частых INSERT-ах. В новых версиях проблема исправлена. Тем не менее, если раньше возникла ситуация "... intersects previous part", то она останется и после обновления. Исправить до конца можно путём пересоздания таблицы и INSERT SELECT в неё.

в новых версиях - насколько новых, хотя бы примерно?) и актуальна ли еще рекомендация "не чаще одного инсерта в секунду"?

Где-то полтора месяца назад - середина ноября. Актуальна.

Такая проблема была в старых версиях с таблицами типа MergeTree, при частых INSERT-ах. В новых версиях проблема исправлена. Тем не менее, если раньше возникла ситуация "... intersects previous part", то она останется и после обновления. Исправить до конца можно путём пересоздания таблицы и INSERT SELECT в неё.

Спасибо, так и сдедали. Версию обновим

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

Как раз если сделать http версию то можно будет почти не следить.

это да, но это слишком скучно, мне приключений захотелось!

http://www.awesomescreenshot.com/image/2034994/c5b94dc600c828021adb288306cab123 все три сервера идентичные и запись на них равномерная

Тут можно не беспокоиться. Был длинный мерж, и он выполнился.

почти целые сутки? в это время перезапустили сервер. Может быть конечно просто так совпало, что он в это же время завершился.

почти целые сутки? в это время перезапустили сервер. Может быть конечно просто так совпало, что он в это же время завершился.

Вот это трудно сказать без разбирательств.

это да, но это слишком скучно, мне приключений захотелось!

Я бы предпочёл нормальное описание и версионируемость бинарного протокола. Тогда и клиенты можно под разные ЯП пилить. А поверх http - это накостыливание педалей. HTTP несет слишком много ограничений.

я бы тоже предпочел, но чего нет - того нет ¯\_(ツ)_/¯

В чем проблема HTTP?

Если кто-то сможет это сформулировать, можно подумать

Мы пока что не столкнулись ни с какими проблемами.

мне очень хочется прогресса выполнения запроса

я формулировал в https://github.com/yandex/ClickHouse/issues/208