
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 / или что вы там любите, и удалить кусок данных из главной БД, оставив данные в КХ.

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 должны в этом случае отрабатывать одинаково
Если дело в конфигурации, подскажите какие настройки нужно проверить

Michal
06.07.2018
08:46:56

Максим
06.07.2018
08:51:31

Michal
06.07.2018
08:52:54

Максим
06.07.2018
08:55:00

Google

Michal
06.07.2018
09:42:08


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 ?

Victor
06.07.2018
10:09:03

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

Andrey
06.07.2018
10:12:53

Michal
06.07.2018
10:13:47

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

Michal
06.07.2018
10:15:29

Yaroslav
06.07.2018
10:18:26
он просто ругается на несоответствие типов

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

Michal
06.07.2018
11:33:01
Так будет намного быстрее чем миллион if

Дмитрий
06.07.2018
11:42:21

Google

Максим
06.07.2018
11:45:23

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

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

Alex
06.07.2018
11:57:02

Дмитрий
06.07.2018
12:13:23

Michal
06.07.2018
12:24:13
А в таблицу не хотите это сгруппировать?

Дмитрий
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

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

Michal
06.07.2018
13:17:07

Oleg Bazdyrev
06.07.2018
13:25:28
причем ошибка повторяется только в prewhere

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

Michal
06.07.2018
13:26:25


Дмитрий
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

Вячеслав
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

Michal
06.07.2018
14:43:40

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

Tima
06.07.2018
14:47:18

Дмитрий
06.07.2018
14:48:04

Michal
06.07.2018
14:48:24
Может memory кончается у вас? :)
с groupArrayInsertAt(0,4000) так делать не надо. Хвостовые элементы в таблице низачем не нужны

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

Tima
06.07.2018
14:50:21

Michal
06.07.2018
14:50:22

Дмитрий
06.07.2018
14:51:07

Tima
06.07.2018
14:51:08

Дмитрий
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

Tima
06.07.2018
14:55:05

Дмитрий
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
max_ast_elements