@clickhouse_ru

Страница 580 из 723
Michal
06.07.2018
08:11:26
Т.е. ваш аналитический отчет по финансовым данным будет выполняться за пару минут вместо десятков часов. Во время его выполнения главная база данных не будет "лежать" из-за блокировок и т.п.

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

Denis
06.07.2018
08:11:49
у нас не финансы, а данные с датчиков. старая база на вставку не справляется(

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

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

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

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

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

А есть штатный механизм, с помощью которого можно узнавать, что при живой сети и живом КХ и без ошибок строки не вставились по какой-нибудь КХ-причине?
Штатный механизм = если кликхаус вернул статус 200, значит ВСЕ данные вставились. Исключение - если подкручены настройки типа input_format_allow_errors_num (выключенные по умолчанию).

Sergey
06.07.2018
08:31:43
О. Этого хватит. Спасибо.

Максим
06.07.2018
08:38:36
Подскажите, почему запрос с 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 должны в этом случае отрабатывать одинаково

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

Максим
06.07.2018
08:51:31
Случайно не используете поля типа ALIAS в таблице?
Это какой-то ссылочный тип? Нет, в таблице только строки, числа и даты

Michal
06.07.2018
08:52:54
Это какой-то ссылочный тип? Нет, в таблице только строки, числа и даты
Это "вычислимое" поле которое физически в базе не хранится, а вычисляется "на лету".

Google
Michal
06.07.2018
09:42:08
и ещё: почему запрос: SELECT * FROM tbl WHERE EntityID = 'value' зависает, а с prewhere отрабатывает, хотя столбец "EntityID" - первый в индексе, и, согласно документации, where и prewhere должны в этом случае отрабатывать одинаково
Действительно, у меня разница по скорости вышла в 10 раз, вызвана разным количеством прочитанных данных. Там есть оптимизация optimize_move_to_prewhere, но она не работает с primary key. А где написано что "согласно документации, where и prewhere должны в этом случае отрабатывать одинаково"?

Yaroslav
06.07.2018
09:53:18
Всем привет! Часовой пояс для 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 │

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

Дмитрий
06.07.2018
10:10:21
как source в mysql?
этого я тож не знаю ;( надо чтобы зачитал с винта sql и выполнил

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

Andrey
06.07.2018
10:12:53
cat sql.sql | clickhouse-client работает вроде но хочется из интерактивного режима
А в чем разница? Все равно ошибки выползень в аутпут. А вообще такой команды вроде нет.

Michal
06.07.2018
10:13:47
Всем привет! Часовой пояс для DateTime можно указывать прямо в фкнции преобразования toDateTime(timestamp, 'UTC'). Но почему то если указываю такое выражение в DEFAULT, то часовой пояс игнорируется. Кто-нибудь сталкивался?
Дело в типе данных. Если тип данных DateTime тогда будет форматировать дату в соотвествии с часовым поясом сервера или клиента. Если нужно чтобы по умолчанию использовалась определенная таймзона - то просто указываете её в типе данных, т.е. в вашем случае CREATE TABLE ... ( time_utc DateTime('UTC') DEFAULT ... )

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

Michal
06.07.2018
10:15:29
мне не ощибки мне статус с прогресс-баром итд... запрос очень жирный через клипбоард тормозно вставлять
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 ...

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

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

Michal
06.07.2018
11:33:01
А можно ли как-то безболезнено сделать 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

Google
Максим
06.07.2018
11:45:23
Действительно, у меня разница по скорости вышла в 10 раз, вызвана разным количеством прочитанных данных. Там есть оптимизация optimize_move_to_prewhere, но она не работает с primary key. А где написано что "согласно документации, where и prewhere должны в этом случае отрабатывать одинаково"?
Следует иметь ввиду, что указывать в PREWHERE только столбцы, по которым существует индекс, имеет мало смысла, так как при использовании индекса и так читаются лишь блоки данных, соответствующие индексу. https://clickhouse.yandex/docs/ru/query_language/queries/#prewhere

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

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

Дмитрий
06.07.2018
12:13:23
Если нужно обязательно по колонкам разнести (зачем?) то можно потом с помощью if. Разница в том что сейчас на каждой ИСХОДНОЙ строке выполняется миллион if, а тут был бы миллион if на сгруппированных строках, которых я полагаю будет значительно меньше.
неа, в 99.9999% в рамках одной session_id только одно событие "xxx", сверткой не спасешься... по колонкам разнести - надо считать дельту времени между различными событиями и выявлять нарушение максимально допустимого времени. этих правил (дельт которые надо считать и контролировать) в макете 2000... Думается сначала собрать такую широкую таблицу в memory а потом тейблсканами по ней 2000 запросов...

Дмитрий
06.07.2018
12:35:01
А в таблицу не хотите это сгруппировать?
что именно? данные о событиях летят кладутся отдельными записямив КХ.

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

papa
06.07.2018
13:01:38
toStartOfQuarter

Michal
06.07.2018
13:02:04
что именно? данные о событиях летят кладутся отдельными записямив КХ.
Ну можно это в несколько шагов сделать. 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 или функциями высшего порядка. Или тупо повытаскивать отдельные элементы таблицы в колонки и делать то что вам там нужно.

Harry
06.07.2018
13:03:09
toStartOfQuarter
Спасибо! А как быть с группировкой по 6 месцев?

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

Michal
06.07.2018
13:17:07
Привет! Есть табличка с полем 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.

Oleg Bazdyrev
06.07.2018
13:25:28
вы нас обманываете... :) 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

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

Дмитрий
06.07.2018
13:30:02
Ну можно это в несколько шагов сделать. 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% и думает, КХ при этом непонятно чем занимается (ядро даже одно полностью не занято)....

Google
Michal
06.07.2018
13:31:56
Progress: 554.31 million rows, 16.63 GB (9.62 million rows/s., 288.67 MB/s.) 99% дошло до 99% и думает, КХ при этом непонятно чем занимается (ядро даже одно полностью не занято)....
Ага. Кликхаус те вещи для которых не может оценить время выполнения на последнем проценте выполняет :) Потерпите :)

Вячеслав
06.07.2018
13:41:17
nikoinlove
06.07.2018
13:48:15
а не знаете аналога toStartOfFifteenMinutes в mysql? ну так совершенно случайно:)

Harry
06.07.2018
13:53:53
Дмитрий
06.07.2018
14:17:42
Ага. Кликхаус те вещи для которых не может оценить время выполнения на последнем проценте выполняет :) Потерпите :)
Так и не дождался. Переписал запрос чуток (раскрыл скодбки убрал 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-получится дата/время

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

Tima
06.07.2018
14:47:18
просто со строк перешел на числа (ID-ы) - сравнивать проще. groupArrayInsertAt(0,4000) - выделить сразу 4000 элементов, заполнить нулями. Пофиг и с ним и без него падает
Как-то слишком жирно 4000 элементов на строку, не находите? Зачем столько? По моему опыту с таким порядком цифр вам не к КХ, а куда-то в сторону Hadoop и ему подобных

Michal
06.07.2018
14:48:24
Может memory кончается у вас? :)

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

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

Tima
06.07.2018
14:51:08
Array с 4000 тысячами элементов - должно быть терпимо.
Терпимо, но зачем так делать? Я пока не очень понимаю какую проблему пытаются решить создавая такой массив

Дмитрий
06.07.2018
14:51:55
сделал 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

Google
Дмитрий
06.07.2018
14:57:09
ест 128 гигов и падает....

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

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

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

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

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

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

Tima
06.07.2018
15:18:27
можно кстати как-то его подкрутить?
Насколько я знаю - да, сейчас посмотю

можно кстати как-то его подкрутить?
Во https://github.com/yandex/ClickHouse/blob/82932f904d403014b76befe8a66a83ea915fa204/docs/ru/operations/settings/query_complexity.md

max_ast_elements

Страница 580 из 723