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

Плюсы налицо.

у нас не финансы, а данные с датчиков. старая база на вставку не справляется(

Если это датчики АЭС, то я бы вам советовал задуматься над тем как это исправить без помощи КХ. :) Если это датчики не с АЭС, то я бы советовал задуматься - так ли важно каждое единичное значение датчика в конкретную секунду.

99% можно потерять иногда, но есть один вид сигналов, который обязательно нужен. возможно есть смысл только его дублировать в ACID базу

А есть штатный механизм, с помощью которого можно узнавать, что при живой сети и живом КХ и без ошибок строки не вставились по какой-нибудь КХ-причине?

Ну т.е. жить в ситуации "угадай, сколько строк КХ сохранил" чёт больно. :)

Можно ещё сделать так: в течение относительно короткого промежутка времени хранить данные в 2 местах. Потом (в конце дня / недели / месяца) выполнять проверку целостности данных в КХ сравнивая их с данными в другой системе. Если все совпало - то записать бэкап данных на ленты / Glacier / или что вы там любите, и удалить кусок данных из главной БД, оставив данные в КХ.

А есть штатный механизм, с помощью которого можно узнавать, что при живой сети и живом КХ и без ошибок строки не вставились по какой-нибудь КХ-причине?

Штатный механизм = если кликхаус вернул статус 200, значит ВСЕ данные вставились. Исключение - если подкручены настройки типа input_format_allow_errors_num (выключенные по умолчанию).

О. Этого хватит. Спасибо.

Подскажите, почему запрос с GLOBAL IN может выводить данные с одного узла, а не со всех? т.е. запрос: SELECT * FROM tbl preWHERE EntityID GLOBAL IN ( SELECT EntityID FROM tbl preWHERE EntityID = 'value' ) показывает меньше данные чем запрос SELECT * FROM tbl preWHERE EntityID = 'value'

и ещё: почему запрос: SELECT * FROM tbl WHERE EntityID = 'value' зависает, а с prewhere отрабатывает, хотя столбец "EntityID" - первый в индексе, и, согласно документации, where и prewhere должны в этом случае отрабатывать одинаково

Если дело в конфигурации, подскажите какие настройки нужно проверить

и ещё: почему запрос: SELECT * FROM tbl WHERE EntityID = 'value' зависает, а с prewhere отрабатывает, хотя столбец "EntityID" - первый в индексе, и, согласно документации, where и prewhere должны в этом случае отрабатывать одинаково

Случайно не используете поля типа ALIAS в таблице?

Случайно не используете поля типа ALIAS в таблице?

Это какой-то ссылочный тип? Нет, в таблице только строки, числа и даты

Это какой-то ссылочный тип? Нет, в таблице только строки, числа и даты

Это "вычислимое" поле которое физически в базе не хранится, а вычисляется "на лету".

Это "вычислимое" поле которое физически в базе не хранится, а вычисляется "на лету".

Хм, вроде нет

и ещё: почему запрос: SELECT * FROM tbl WHERE EntityID = 'value' зависает, а с prewhere отрабатывает, хотя столбец "EntityID" - первый в индексе, и, согласно документации, where и prewhere должны в этом случае отрабатывать одинаково

Действительно, у меня разница по скорости вышла в 10 раз, вызвана разным количеством прочитанных данных. Там есть оптимизация optimize_move_to_prewhere, но она не работает с primary key. А где написано что "согласно документации, where и prewhere должны в этом случае отрабатывать одинаково"?

Всем привет! Часовой пояс для DateTime можно указывать прямо в фкнции преобразования toDateTime(timestamp, 'UTC'). Но почему то если указываю такое выражение в DEFAULT, то часовой пояс игнорируется. Кто-нибудь сталкивался?

┌─toDateTime(1527640610.101, \'UTC\')─┐ │ 2018-05-30 00:36:50 │ └─────────────────────────────────────┘ localhost :) desc test ┌─name───────┬─type─────┬─default_type─┬─default_expression──────────────┐ │ date │ Date │ │ │ │ time_utc │ DateTime │ DEFAULT │ toDateTime(time_epoch, \'UTC\') │ │ time_epoch │ Float64 │ │ │ └────────────┴──────────┴──────────────┴─────────────────────────────────┘ insert into test (date, time_epoch) values (toDate(now()), 1527640610.101) localhost :) select * from test ┌───────date─┬────────────time_utc─┬─────time_epoch─┐ │ 2018-07-06 │ 2018-05-30 03:36:50 │ 1527640610.101 │

а подскажите если запрос в файле на жестком диске - как его выполнить из интерактивного режима clickhouse-client ?

а подскажите если запрос в файле на жестком диске - как его выполнить из интерактивного режима clickhouse-client ?

как source в mysql?

как source в mysql?

этого я тож не знаю ;( надо чтобы зачитал с винта sql и выполнил

cat sql.sql | clickhouse-client работает вроде но хочется из интерактивного режима

cat sql.sql | clickhouse-client работает вроде но хочется из интерактивного режима

А в чем разница? Все равно ошибки выползень в аутпут. А вообще такой команды вроде нет.

Всем привет! Часовой пояс для DateTime можно указывать прямо в фкнции преобразования toDateTime(timestamp, 'UTC'). Но почему то если указываю такое выражение в DEFAULT, то часовой пояс игнорируется. Кто-нибудь сталкивался?

Дело в типе данных. Если тип данных DateTime тогда будет форматировать дату в соотвествии с часовым поясом сервера или клиента. Если нужно чтобы по умолчанию использовалась определенная таймзона - то просто указываете её в типе данных, т.е. в вашем случае CREATE TABLE ... ( time_utc DateTime('UTC') DEFAULT ... )

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

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

clickhouse-client --help Main options: ... -t [ --time ] print query execution time to stderr in non-interactive mode (for benchmarks) --stacktrace print stack traces of exceptions --progress print progress even in non-interactive mode --echo in batch mode, print query before execution ...

Дело в типе данных. Если тип данных DateTime тогда будет форматировать дату в соотвествии с часовым поясом сервера или клиента. Если нужно чтобы по умолчанию использовалась определенная таймзона - то просто указываете её в типе данных, т.е. в вашем случае CREATE TABLE ... ( time_utc DateTime('UTC') DEFAULT ... )

Спасибо!

Дело в типе данных. Если тип данных DateTime тогда будет форматировать дату в соотвествии с часовым поясом сервера или клиента. Если нужно чтобы по умолчанию использовалась определенная таймзона - то просто указываете её в типе данных, т.е. в вашем случае CREATE TABLE ... ( time_utc DateTime('UTC') DEFAULT ... )

А можно ли как-то безболезнено сделать alter поля, которое уже содержит данные, c DateTime на DateTime('UTC')

он просто ругается на несоответствие типов

господа я тут бъюсь над одним страшным запросом, может быть есть мысли как можно ускорить? https://pastebin.com/9kDPTXB7

упирается с CPU я так понимаю.

А можно ли как-то безболезнено сделать alter поля, которое уже содержит данные, c DateTime на DateTime('UTC')

Должно быть безболенно, но увы нет. Создал issue: https://github.com/yandex/ClickHouse/issues/2602

господа я тут бъюсь над одним страшным запросом, может быть есть мысли как можно ускорить? https://pastebin.com/9kDPTXB7

сделать группировку по sessionid, checkpoint_code и вытащить any(synchronized_event_time) из каждой группы. А потом на результате сделать группировку по sessionid и перенести нужные значение в отдельные колонки.

Так будет намного быстрее чем миллион if

сделать группировку по sessionid, checkpoint_code и вытащить any(synchronized_event_time) из каждой группы. А потом на результате сделать группировку по sessionid и перенести нужные значение в отдельные колонки.

Как именно перенести результаты в нужную колонку? Я как раз через anyif это делаю

Действительно, у меня разница по скорости вышла в 10 раз, вызвана разным количеством прочитанных данных. Там есть оптимизация optimize_move_to_prewhere, но она не работает с primary key. А где написано что "согласно документации, where и prewhere должны в этом случае отрабатывать одинаково"?

Следует иметь ввиду, что указывать в PREWHERE только столбцы, по которым существует индекс, имеет мало смысла, так как при использовании индекса и так читаются лишь блоки данных, соответствующие индексу. https://clickhouse.yandex/docs/ru/query_language/queries/#prewhere

Если нужно обязательно по колонкам разнести (зачем?) то можно потом с помощью if. Разница в том что сейчас на каждой ИСХОДНОЙ строке выполняется миллион if, а тут был бы миллион if на сгруппированных строках, которых я полагаю будет значительно меньше.

Господа, не подскажите с одной проблемой. В clickhouse держу базу для графита с движком GraphiteMergeTree, если указываю агрегацию по sum на определенных интервалах, то clickhouse начинает агрегировать какую то дичь. Например для метрик типа counter последнее значение может быть меньше предыдущего.

Должно быть безболенно, но увы нет. Создал issue: https://github.com/yandex/ClickHouse/issues/2602

Это в 54388 было исправлено

Если нужно обязательно по колонкам разнести (зачем?) то можно потом с помощью if. Разница в том что сейчас на каждой ИСХОДНОЙ строке выполняется миллион if, а тут был бы миллион if на сгруппированных строках, которых я полагаю будет значительно меньше.

неа, в 99.9999% в рамках одной session_id только одно событие "xxx", сверткой не спасешься... по колонкам разнести - надо считать дельту времени между различными событиями и выявлять нарушение максимально допустимого времени. этих правил (дельт которые надо считать и контролировать) в макете 2000... Думается сначала собрать такую широкую таблицу в memory а потом тейблсканами по ней 2000 запросов...

А в таблицу не хотите это сгруппировать?

Следует иметь ввиду, что указывать в PREWHERE только столбцы, по которым существует индекс, имеет мало смысла, так как при использовании индекса и так читаются лишь блоки данных, соответствующие индексу. https://clickhouse.yandex/docs/ru/query_language/queries/#prewhere

? https://github.com/yandex/ClickHouse/issues/2601

А в таблицу не хотите это сгруппировать?

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

Подскажите, а как сгруппировать данные по 3 месяца?

toStartOfQuarter

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

Ну можно это в несколько шагов сделать. 1) трансформируйте ваши значения в номера колонок, типа такого transform( checkpoint_code , [ 'B_rule_1sec_0', 'A_rule_1sec_1', 'B_rule_1sec_1', ... ], [1,2,3, ...], 0) as arr_index,2) погруппируйте данные по session_id, arr_index cобирая попутно synchronized_event_time select session_id, transform( ... ) as arr_index, any(synchronized_event_time) as some_synchronized_event_time group by session_id, arr_index3) поверх всего этого сделайте группировку по session_id и собирая таймстампы в таблицы в нужные позиции с помощью groupArrayInsertAt: select session_id, groupArrayInsertAt( some_synchronized_event_time, arr_index ) from ( ... предыдущий селект ... ) group by session_id4) на выходе получите примерно то на что расчитывали, только не в колонках а в таблице. и должно работать ощутимо быстрее. Таблицы могут не иметь хвостовых элементов, но это ни в чем не мешает. 5) потом по этим таблицам можно ездить аггрегациями c -ForEach или функциями высшего порядка. Или тупо повытаскивать отдельные элементы таблицы в колонки и делать то что вам там нужно.

toStartOfQuarter

Спасибо! А как быть с группировкой по 6 месцев?

Привет! Есть табличка с полем UInt8 При фильтрации типа field = 1 все работает нормально, но при фильтрации типа field in (1,2) кликхаус ругается на нестыковку типов Как тут правильно сделать?

Привет! Есть табличка с полем UInt8 При фильтрации типа field = 1 все работает нормально, но при фильтрации типа field in (1,2) кликхаус ругается на нестыковку типов Как тут правильно сделать?

вы нас обманываете... :) create temporary table www ( w UInt8 ); insert into www values (1),(2),(3); select * from www where w in (1,2); ┌─w─┐ │ 1 │ │ 2 │ └───┘ 2 rows in set. Elapsed: 0.012 sec.

вы нас обманываете... :) create temporary table www ( w UInt8 ); insert into www values (1),(2),(3); select * from www where w in (1,2); ┌─w─┐ │ 1 │ │ 2 │ └───┘ 2 rows in set. Elapsed: 0.012 sec.

вот так точно ошибка выглядит: DB::Exception: Types of column 1 in section IN don't match: Int8 on the right, UInt8 on the left походу разобрался, читаем из merge-таблицы, в ней Int8, а в нижележащих таблицах UInt8

причем ошибка повторяется только в prewhere

Привет. Есть web api, который возвращает данные в формате json. Пример: [{"id": 1, "name":"abc"}]. При подключении api к clickhouse в качестве внешнего словаря, получаю ошибку: Format JSON is not suitable for input. Существуют ли какие то варианты использования такого формата?

Привет. Есть web api, который возвращает данные в формате json. Пример: [{"id": 1, "name":"abc"}]. При подключении api к clickhouse в качестве внешнего словаря, получаю ошибку: Format JSON is not suitable for input. Существуют ли какие то варианты использования такого формата?

Только JSONEachRow.

Спасибо! А как быть с группировкой по 6 месцев?

Например так: group by intDiv(toRelativeMonthNum(date), 6)

Ну можно это в несколько шагов сделать. 1) трансформируйте ваши значения в номера колонок, типа такого transform( checkpoint_code , [ 'B_rule_1sec_0', 'A_rule_1sec_1', 'B_rule_1sec_1', ... ], [1,2,3, ...], 0) as arr_index,2) погруппируйте данные по session_id, arr_index cобирая попутно synchronized_event_time select session_id, transform( ... ) as arr_index, any(synchronized_event_time) as some_synchronized_event_time group by session_id, arr_index3) поверх всего этого сделайте группировку по session_id и собирая таймстампы в таблицы в нужные позиции с помощью groupArrayInsertAt: select session_id, groupArrayInsertAt( some_synchronized_event_time, arr_index ) from ( ... предыдущий селект ... ) group by session_id4) на выходе получите примерно то на что расчитывали, только не в колонках а в таблице. и должно работать ощутимо быстрее. Таблицы могут не иметь хвостовых элементов, но это ни в чем не мешает. 5) потом по этим таблицам можно ездить аггрегациями c -ForEach или функциями высшего порядка. Или тупо повытаскивать отдельные элементы таблицы в колонки и делать то что вам там нужно.

Progress: 554.31 million rows, 16.63 GB (9.62 million rows/s., 288.67 MB/s.) 99% дошло до 99% и думает, КХ при этом непонятно чем занимается (ядро даже одно полностью не занято)....

Progress: 554.31 million rows, 16.63 GB (9.62 million rows/s., 288.67 MB/s.) 99% дошло до 99% и думает, КХ при этом непонятно чем занимается (ядро даже одно полностью не занято)....

Ага. Кликхаус те вещи для которых не может оценить время выполнения на последнем проценте выполняет :) Потерпите :)

Только JSONEachRow.

спасибо

а не знаете аналога toStartOfFifteenMinutes в mysql? ну так совершенно случайно:)

Например так: group by intDiv(toRelativeMonthNum(date), 6)

Супер!!! Спасибо большое!

Ага. Кликхаус те вещи для которых не может оценить время выполнения на последнем проценте выполняет :) Потерпите :)

Так и не дождался. Переписал запрос чуток (раскрыл скодбки убрал any вообще) https://pastebin.com/6azBGvVQ → Progress: 19.86 million rows, 595.22 MB (198.30 thousand rows/s., 5.94 MB/s.) 3%Received exception from server (version 1.1.54388): Code: 1001. DB::Exception: Received from localhost:9000, ::1. DB::Exception: std::bad_alloc. 120.525

а не знаете аналога toStartOfFifteenMinutes в mysql? ну так совершенно случайно:)

преобразовать в unix-timestamp (получится чиселко) потом разделить на 900, отбросить дробную часть, умножить на 900 и потом FROM_UNIXTIMESTAMP-получится дата/время

Так и не дождался. Переписал запрос чуток (раскрыл скодбки убрал any вообще) https://pastebin.com/6azBGvVQ → Progress: 19.86 million rows, 595.22 MB (198.30 thousand rows/s., 5.94 MB/s.) 3%Received exception from server (version 1.1.54388): Code: 1001. DB::Exception: Received from localhost:9000, ::1. DB::Exception: std::bad_alloc. 120.525

Н-да. Это у вас конспирация такая сильная что все столбцы каждый раз меняются? :) Что должно означать groupArrayInsertAt(0,4000)?

просто со строк перешел на числа (ID-ы) - сравнивать проще. groupArrayInsertAt(0,4000) - выделить сразу 4000 элементов, заполнить нулями. Пофиг и с ним и без него падает

просто со строк перешел на числа (ID-ы) - сравнивать проще. groupArrayInsertAt(0,4000) - выделить сразу 4000 элементов, заполнить нулями. Пофиг и с ним и без него падает

Как-то слишком жирно 4000 элементов на строку, не находите? Зачем столько? По моему опыту с таким порядком цифр вам не к КХ, а куда-то в сторону Hadoop и ему подобных

Как-то слишком жирно 4000 элементов на строку, не находите? Зачем столько? По моему опыту с таким порядком цифр вам не к КХ, а куда-то в сторону Hadoop и ему подобных

требование заказчика - макет с 10+ кратным запасом по объемам

просто со строк перешел на числа (ID-ы) - сравнивать проще. groupArrayInsertAt(0,4000) - выделить сразу 4000 элементов, заполнить нулями. Пофиг и с ним и без него падает

Ну вы там пытаетесь всё это ещё в таблицу с движком Memory запихать.

Может memory кончается у вас? :)

с groupArrayInsertAt(0,4000) так делать не надо. Хвостовые элементы в таблице низачем не нужны

кстати, а есть какие-то цифры, какое количество элементов в строке для CH предел по эффективности?

кстати, а есть какие-то цифры, какое количество элементов в строке для CH предел по эффективности?

ИМХО - больше 100 байт - уже много

Как-то слишком жирно 4000 элементов на строку, не находите? Зачем столько? По моему опыту с таким порядком цифр вам не к КХ, а куда-то в сторону Hadoop и ему подобных

Array с 4000 тысячами элементов - должно быть терпимо.

Ну вы там пытаетесь всё это ещё в таблицу с движком Memory запихать.

поменял на Log жду...

Array с 4000 тысячами элементов - должно быть терпимо.

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

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

сделать PIVOT по 4000 точек

сделал engine=Log не взлетело... ← Progress: 20.05 million rows, 601.11 MB (108.74 thousand rows/s., 3.26 MB/s.) 3%Received exception from server (version 1.1.54388): Code: 1001. DB::Exception: Received from localhost:9000, ::1. DB::Exception: std::bad_alloc. 186.830

сделал engine=Log не взлетело... ← Progress: 20.05 million rows, 601.11 MB (108.74 thousand rows/s., 3.26 MB/s.) 3%Received exception from server (version 1.1.54388): Code: 1001. DB::Exception: Received from localhost:9000, ::1. DB::Exception: std::bad_alloc. 186.830

Попробуйте MergeTree

ест 128 гигов и падает....

4000 * 20 млн строк - это довольно много. У вас включена агрегация с использованием диска?

4000 * 20 млн строк - это довольно много. У вас включена агрегация с использованием диска?

нет наверное

я счас развернул алгоритм... сначала отбираю в memory table "окно" с событиями. А потом уже "разворачиваю" для каждого правила из 2-х тысяч

такое чуство что быстрее

окно строилось 16 секунд, 250 правил вычисляются одним запросом за 15 секунд

все правила в union all не получается говорит AST Complexitiy Превышен

можно кстати как-то его подкрутить?

можно кстати как-то его подкрутить?

Насколько я знаю - да, сейчас посмотю

можно кстати как-то его подкрутить?

Во https://github.com/yandex/ClickHouse/blob/82932f904d403014b76befe8a66a83ea915fa204/docs/ru/operations/settings/query_complexity.md

max_ast_elements