Добрый день, не подскажете — в Clickhouse xor поддерживается? Вроде указан в руководстве, но база не принимает запросы с ним через jdbc и указывает, что не распознала оператор

если через jdbc не абонент, попробуйте через функцию просто вызывать

bitXor(x, y)

ну или xor(x, y), потому что оператора для xor судя по докам действительно нет %)

Да, действительно проблема в том, что оператора нет :)

Спасибо

https://habrahabr.ru/post/324846/ тут какой-то тип собрал бинарную сборку кх под макос

надеюсь это никому не нужно, но все же%)

другой тип написал пакет для хомбрю, тоже никому не нужный %)

https://github.com/hatarist/homebrew-clickhouse/, если что. только мне безумно лень автоматизировать проверку сборки, а в основной репозиторий меня не пускают из-за говнокода

Есть тут жители Новосибирска? Придёте на нашу встречу 3 апреля? https://events.yandex.ru/events/meetings/3-april-2017/ Для сравнения, в Санкт-Петербурге пришло чуть больше 100 человек. Любопытно, что будет в Новосибирске. Приглашайте друзей и знакомых. В свою очередь, обещаем устроить интересную встречу! Кстати, на этот раз встреча без трансляции.

@milovidov_an ждём подтверждения :)

@milovidov_an а есть вероятность, что не пришлют подтверждение? у меня товарищ зарегился позже и ему всё пришло уже, а мне пока ничего

@milovidov_an а есть вероятность, что не пришлют подтверждение? у меня товарищ зарегился позже и ему всё пришло уже, а мне пока ничего

Очень небольшая. Скорее всего, просто ещё неуспели прислать. Насколько я знаю, там периодически берут и отправляют всем зарегистрировавшимся.

Очень небольшая. Скорее всего, просто ещё неуспели прислать. Насколько я знаю, там периодически берут и отправляют всем зарегистрировавшимся.

Привет! Мы выслали приглашения сегодня, и Вы были в этом списке. Либо у Вас не подтвержденный email, либо еще есть вероятность, что Вы зарегистрировались на другую почту. Напишите мне в личку, разберемся!

заметил, что CASE с нуллами плохо работает: SELECT caseWithoutExpr(screen_name = '', NULL, screen_name) FROM apps_screens LIMIT 1 Received exception from server: Code: 43. DB::Exception: Received from 88.99.66.175:9000. DB::Exception: Internal logic error. а вот так нормально: SELECT caseWithoutExpr(screen_name = '', 'empty', screen_name) FROM apps_screens LIMIT 1 и даже так нормально: SELECT caseWithoutExpr(screen_name = '', NULL, 1) FROM apps_screens LIMIT 1 я так понимаю, что фейлится, когда после else идет строка

Привет! Мы выслали приглашения сегодня, и Вы были в этом списке. Либо у Вас не подтвержденный email, либо еще есть вероятность, что Вы зарегистрировались на другую почту. Напишите мне в личку, разберемся!

странно. Мэйл точно подтверждал, не получил ни отказа, ни птдтверждения. А 2 часа ехать с вероятностью 50% что не пустят сильно не хотелось

Напишите Наталье, она не даст пропасть :)

можете подсказать, что за ошибка такая? DB::Exception: Table is inconsistent accross shards. переливаю данные из одного сервера в кластер. залил по месяцу в каждый шард, хочу запустить перешардирование, и получаю такую ошибку. есть nullable и materialized поля.

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

ReplacingMergeTree?

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

ага, там же процесс слияния ( а если нужно сразу без дублей, насколько понимаю - никак

да, другой СУБД, видимо :)

ну, либо GROUP BY по тем полям, которые нужны дедуплицированными, и any() для всех остальных полей, но это тоже.. такое.. :)

ну тоже норм вариант, чо )

на безрыбье как говорится

ReplacingMergeTree?

А replacing merge tree разве в фоне сработает?

так он вроде ничем от collapsing в этом плане не отличается

а вообще юник констринты были в планах ?

не в курсе ?

констрэинты

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

Обратите внимание, что дедупликация данных производится лишь во время слияний. Слияние происходят в фоне, в неизвестный момент времени, на который вы не можете ориентироваться. Некоторая часть данных может так и остаться необработанной. Хотя вы можете вызвать внеочередное слияние с помощью запроса OPTIMIZE, на это не стоит рассчитывать, так как запрос OPTIMIZE приводит к чтению и записи большого объёма данных. Таким образом, ReplacingMergeTree подходит для фоновой чистки дублирующихся данных в целях экономии места, но не даёт гарантий отсутствия дубликатов.

Даже такого поведения я не наблюдаю

Должен я включить trace и посмотреть что происходит?

это же мне вопрос? да, он. )

ReplacingMergeTree?

увы и ах, это было предложение воспользоваться ReplacingMergeTree для дедупилкации

насчет шардинга не подскажу, сорри. может зукипер как-то косячит.

Ок, поситаю исходники

Кто хочет помочь перевести комменты на англ? Я уже сделал 70%, но силы кончаются

заметил, что CASE с нуллами плохо работает: SELECT caseWithoutExpr(screen_name = '', NULL, screen_name) FROM apps_screens LIMIT 1 Received exception from server: Code: 43. DB::Exception: Received from 88.99.66.175:9000. DB::Exception: Internal logic error. а вот так нормально: SELECT caseWithoutExpr(screen_name = '', 'empty', screen_name) FROM apps_screens LIMIT 1 и даже так нормально: SELECT caseWithoutExpr(screen_name = '', NULL, 1) FROM apps_screens LIMIT 1 я так понимаю, что фейлится, когда после else идет строка

Да, эта функциональность недоделана. Если переписать с использованием обычного if или цепочки if, то будет Ок. В случае, если один из элементов NULL, можно использовать ifNull, nullIf, coalesce функции. Они были доведены до нормального состояния в последней версии сервера.

Спасибо. На самом деле мне нужно было вытащить данные из одного сервера и залить в другой. Эту проблему обошел sed-ом.

Да, эта функциональность недоделана. Если переписать с использованием обычного if или цепочки if, то будет Ок. В случае, если один из элементов NULL, можно использовать ifNull, nullIf, coalesce функции. Они были доведены до нормального состояния в последней версии сервера.

а вообще юник констринты были в планах ?

Пока не было. Сложность в том, что их нужно проверять либо сразу при INSERT-е, либо постоянно мержить данные при SELECT-е. Для того, чтобы проверять при INSERT-е, очень желательно держать соответствующий индекс в оперативке. Но типичный сценарий использования ClickHouse предполагает достаточно большой объём данных на одном сервере (по крайней мере десятки миллиардов записей), и реализация такого индекса становится проблематичной (возможной, например, если держать в оперативке разреженный индекс и bloom фильтр, а другую часть индекса на SSD - мы используем такое в одной из структур данных в Яндекс.Метрике) Мержить при SELECT-е тоже затруднительно. Это возможно либо с существенным уменьшением производительности SELECT-ов (см. SELECT FINAL), либо требует серьёзной разработки (трудно распараллеливать мерж при SELECT-е), хотя полностью реально.

можете подсказать, что за ошибка такая? DB::Exception: Table is inconsistent accross shards. переливаю данные из одного сервера в кластер. залил по месяцу в каждый шард, хочу запустить перешардирование, и получаю такую ошибку. есть nullable и materialized поля.

Мы ещё не начали использовать перешардирование в продакшене, и не исправили все проблемы, которые с ним возникают. Поэтому рекомендую переносить вручную - отдельными партициями, либо INSERT SELECT-ом.

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

INSERT-SELECT не работает из-за materialized поля в distributed-таблице.

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

Да.

INSERT-SELECT не работает из-за materialized поля в distributed-таблице.

Значит придётся перечислить остальные поля в запросе (либо заменить MATERIALIZED на DEFAULT).

ок, понял. спасибо, буду завтра пробовать.

Можно ли рассчитывать, что когда будет сделано партиционирование до дней, скажем, то OPTIMIZE будет решать вопрос с дедупликацией быстрее\проще\с чтение и записью меньшего кол данных так как партиция один день а не месяц? Я праильно понимаю что OPTIMIZE для ReplicatedMergeTree удалит дубликаты? или это я только хочу так

Можно ли рассчитывать, что когда будет сделано партиционирование до дней, скажем, то OPTIMIZE будет решать вопрос с дедупликацией быстрее\проще\с чтение и записью меньшего кол данных так как партиция один день а не месяц? Я праильно понимаю что OPTIMIZE для ReplicatedMergeTree удалит дубликаты? или это я только хочу так

Это зависит от объёма данных в рамках партиции. В случае OPTIMIZE FINAL, все данные в рамках партиции сливаются в один кусок и вся фоновая работа происходит до конца. К настройке партиций надо будет относиться осторожно, так как слишком большое количество партиций приведёт к замедлению коротких запросов - надо будет делать много seek-ов. Месяц по-умолчанию выбран не просто так.

Привет! Подскажите, пожалуйста, что делать, если на одной из реплик отсутствует кусок (part), и как такое могло получиться? В логах реплики, в которой куска нет, его имя не фигурирует. В логах реплики, где кусок есть, упоминание только одно - <Trace> dbName.tableName (Data): Renaming tmp_20161101_20161130_857_857_0.

Следует обратить внимание - является ли этот кусок активным. В таблице system.parts это поле active. Чтобы посмотреть только активные куски, напишите SELECT * FROM system.parts WHERE active. Именно активные куски используются в запросах. Остальные куски - это те, которые остались после слияний и будут удалены через небольшое время. При репликации, данные вставляются (и формируют новый кусок) на одну реплику, а остальные реплики скачивают этот кусок. Но если кусок уже успел помержиться с другими, то реплики будут скачивать уже более крупный - померженный кусок.

Кусок активен

Собственно, копать начали потому, что количество записей в репликах разошлось

Посмотрите очередь репликации: SELECT * FROM system.replication_queue

пусто

У реплики есть некий эталонный набор кусков, который должен быть на диске. Этот эталонный набор хранится в ZK в /path/to/table/replicas/replica/parts. Репликация устроена так, что без внешнего вмешательства, после выполнения очереди репликации, все реплики будут иметь один и тот же эталонный набор кусков. Посмотрите, есть ли там нужный кусок. Совпадает ли набор кусков в ZK у разных реплик?

Нет, наборы не совпадают - как и в system.parts, у одной реплики на один кусок меньше

(тот же самый кусок)

Если вы добавите туда этот кусок и перезапустите сервер, то он скачает его с реплики. Как я говорил, без ручных вмешательств и без очереди репликации, набор кусков должен совпадать. У нас на практике случая расхождения реплик не было. Интересуют подробности по каким-нибудь необычным действиям... всякие ATTACH/DETACH/DROP PARTITION, не включали ли insert_quorum, не редактировали ли ZooKeeper, не было ли сбоев в ZK с восстановлением и т. п.

Также посмотрите path/to/table/log и path/to/table/replicas/replica/log_pointer - информация о том, докуда реплика скопировала свою очередь из общего лога.

>Если вы добавите туда этот кусок и перезапустите сервер, то он скачает его с реплики. Понял, так и сделаем. > Интересуют подробности по каким-нибудь необычным действиям... всякие ATTACH/DETACH/DROP PARTITION, не включали ли insert_quorum, не редактировали ли ZooKeeper Вот этого ничего не было. >не было ли сбоев в ZK с восстановлением и т. п. А вот у зукипера проблемы были, прилетали сообщения "no zookeeper", "keeper exception"

> А вот у зукипера проблемы были, прилетали сообщения "no zookeeper", "keeper exception" Keeper Exception - это не проблемы, а временная потеря сессии с ZK, которая восстанавливается автоматически.

Также посмотрите path/to/table/log и path/to/table/replicas/replica/log_pointer - информация о том, докуда реплика скопировала свою очередь из общего лога.

log_pointer у обеих реплик на 1 больше максимального номера из path/to/table/log

Значит с этим всё как ожидается.

А вот в /path/to/table/replicas/replica/queue есть один элемент, и в нём упоминается тот самый кусок

А в system.replication_queue при этом пусто?

да

Это странно (надо посмотреть в коде, как может быть, что реплика не видит свою очередь). Если вы просто перезапустите сервер на этой реплике, то всё будет Ок.

про перезапуск - хорошая новость

p.s. если что, у нас 1.1.54164

Привет Подскажите, пожалуйста Периодически разваливается реплика Кликхауса с таким вот сообщением в логе 2017.03.28 12:31:14.818651 [ 3297 ] <Error> HTTPHandler: Code: 999, e.displayText() = zkutil::KeeperException: connection loss, path: /clickhouse/tables/nz/1/zos2/temp/abandonable_lock-, e.what() = zkutil::KeeperException, Stack trace: 0. /usr/bin/clickhouse-server(StackTrace::StackTrace()+0x16) [0x1224296] 1. /usr/bin/clickhouse-server(DB::Exception::Exception(std::string const&, int)+0x1f) [0xf88dbf] 2. /usr/bin/clickhouse-server(zkutil::KeeperException::KeeperException(int, std::string const&)+0x6b) [0x12ea4bb] 3. /usr/bin/clickhouse-server(zkutil::ZooKeeper::tryCreate(std::string const&, std::string const&, int, std::string&)+0x52) [0x2ad5ac2] 4. /usr/bin/clickhouse-server(zkutil::ZooKeeper::create(std::string const&, std::string const&, int)+0x47) [0x2ad5b37] При этом в логе Zookepeer вот такое 2017-03-28 12:21:29,689 [myid:3] - WARN [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:2181:NIOServerCnxn@362] - Exception causing close of session 0x35b0f9728470000 due to java.io.IOException: Len err or 1097666 2017-03-28 12:21:29,689 [myid:3] - INFO [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:2181:NIOServerCnxn@1008] - Closed socket connection for client /10.244.2.162:33026 which had sessionid 0x35b0f9728 470000 Помогает только рестарт Зукипера и последующий рестарт Кликхауса Может кто сталкивался с такой проблемой?

а у кого большой опыт с CH в Графане?

я хочу GROUP BY собрать, но у меня поле это IPV4 как число

не получается на него применить IPv4NumToString:(

а почему не получается?

IPv4NumToString почему-то применяется и на поле выборк и на count()

и вылетает с ошибкой "2 аргумента для IPv4NumToString слишком много"

мне фактичсеки надо select IPv4NumToString(my_field), count() group by my_field

Вы уверены, что SELECT IPv4NumToString(IP) ip, count(*) from table where $timeFilter GROUP BY ip не работает ?

оно работает, если вбить в графану руками SQL запрос

а через конструктор запроса - нет :(

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

:'(

у нас просто много разных баз, tsdb, prometheus, influxdb и там везде по привычки тыкаешь конструктором, оно удобно

а через конструктор запроса - нет :(

Если вас не затруднит сделайте issue в https://github.com/Vertamedia/clickhouse-grafana

Явно бага редактора а не clickhouse

Это бага редактора, но в обновлении редактор был удален из плагина

вместо него форматирование запросов и хайлайт

он удобный был, мне понравился

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

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

в целом я согласен