
antuan
13.06.2018
08:48:34
и по сколько записей вставляется за раз?

Vadim
13.06.2018
08:51:10
смотрел в файле 6330 скрок
сейчас пробую для карбон-кликхауса задержку делать
chunk-auto-interval = "5:10s,20:60s"

antuan
13.06.2018
08:52:07
я бы дождался пока закончатся мержи, потом возобновил бы вставку

Google

antuan
13.06.2018
08:52:33
но это я, человек более сведущий сделал бы, возможно, как-то по-другому

Vadim
13.06.2018
08:55:18
так мерджи идут очень медленно, часы
у карбон-кликхауса есть вчерашен файлы и они не исчезают, видимо, вставка совсем не идет, автоматика с задержкой не сработала, сообщения в логе карбон-кликхауса валились несколько раз в секунду, поставил отправлять раз в 30 секунд, файлы становтяся больше в объеме
скорость мерджа примерно 2% за 2 часа

antuan
13.06.2018
08:58:38
Если поискать по этому чатику ошибку про slow merges, то всегда советуют дождаться окончания мержа. И всегда (насколько я успел посмотреть) такая ошибка при слишком частых вставках

Vadim
13.06.2018
08:59:43
ок, спасибо, зделаю везде вставку реже чем ежесекундно

Arkady
13.06.2018
09:29:27
Привет всем!
Подскажите пожалуйста, способ как tuple развернуть в набор колонок.
Я делаю
SELECT min((a,b,c)) FROM t
и хочу получить на выходе 3 колонки a,b,c.

Perlovka
13.06.2018
09:42:03
Боброго. А почему КХ не принимает числа с ведущим 0 в UInt поля? Пытаюсь загрузить TSV файл.
Column 1, name: event_ms, type: UInt16, parsed text: "0"
ERROR: garbage after UInt16: "75<TAB>2018-01"
Это фича или баг? )

Tima
13.06.2018
09:44:04

Perlovka
13.06.2018
09:44:21
075 там

Tima
13.06.2018
09:44:33

Perlovka
13.06.2018
09:45:35
Ну про это и вопрос ) По идее должно вставиться 75, а оно падает

Google

Tima
13.06.2018
09:46:27

Aleksandr
13.06.2018
09:47:00
Здравствуйте. Подскажите пожалуйста, была ли уже реализована возможность переименовывать column?

Perlovka
13.06.2018
09:47:21
Ну приводить понятно, просто это лишние телодвижения, хотелось бы автоматом )

Tima
13.06.2018
09:50:55

Perlovka
13.06.2018
09:52:04
Да я уже привык, просто постоянно возникают вопросы ) Спасибо в любом случае.

Yuran
13.06.2018
10:02:57
хотя нет, погодите, валидное, я туплю :)
но все равно, обычно под 0xxx подразумеваются восмеричные числа, и 075 != 75
видимо КХ восьмеричные числа не поддерживает и не дает такое вставлять

Tima
13.06.2018
10:05:00
КХ работает по строгой типизации, 8-ричность тут не причем

Yuran
13.06.2018
10:06:04
судя по сообщению, парсер КХ просто не дает иметь ведущие нули в числе, потому что не хочет обрабатывать восьмеричную нотацию
даже если бы КХ поддерживал такие числа, в этом случае он должен был вставить 61 , а не 75 :)

Vladimir
13.06.2018
10:12:53
Кто-то может знает когда сл релиз с этой штукой выйдет?
https://github.com/yandex/ClickHouse/issues/2342

Ievgen
13.06.2018
10:18:02
Всем привет, немного unclear из документации - я правильно понимаю - если я создаю колонку как materialized то кроме того что она не отображается при select * и не "учитывается" при insert в остальном это вполне обычная колонка, я могу по ней строить индексы и прочее, я имею ввиду что значение не расчитывается каждый раз, а только при insert?


Victor
13.06.2018
10:39:11
Друзья, подскажите новичку.
Кручу, верчу КХ, применить хочу.
Есть таблица, пусть MergeTree, туда вставляются данные.
Допустим таблица вида
PK( EventDate, ObjectID ), value1, value3, ..., valueN
Описывает состояние объектов в n-ное время.
99% времени - value1, value2, value3, ..., valueN не изменяются. Изменяется только EventDate, что в PK, это время "съёма" значений.
В целом, при хранении мне всё равно, пусть даже дублируются.
В результатах запросов - не нужны.
т.е. по факту, я хочу иметь историю изменения состояний и возможность выбрать только те, у кого состояния менялись за некоторый интервал времени, это будет 2-3 изменившихся значения.
GROUP BY по всем филдам мне не кажется хорошей идеей.
Использовать DISTINCT по value1, value2, value3, ..., valueN?
Завести филд для хеша всех value и делать по нему GROUP by hash?
Адаптироваться к CollapsingMergeTree?
наверно, добавлю hash столбцов в PK и ReplacingMergeTree сделаю


Ilya
13.06.2018
10:39:38
:) select 075
SELECT 61
┌─61─┐
│ 61 │
└────┘
1 rows in set. Elapsed: 0.002 sec.
:)

Yuran
13.06.2018
10:42:51
я так понимаю, что для каждого формата свой парсер

Google

papa
13.06.2018
10:43:42
так более оптимально

Andrey
13.06.2018
11:31:00
Добрый день.
Есть 6 серверов: 3 шарда и по одной реплике у каждого.
Для каждого шарда создана таблица с движком ReplicatedMergeTree
Есть 7-й сервер, который планируется использовать как агрегационный.
Вопрос: где создавать таблички с Engine = Distributed?
Ибо 7-я нода о них ничего не знает

papa
13.06.2018
11:36:23
создавать например там, где вы собираетесь из нее селекты делать.

Andrey
13.06.2018
11:41:21
На каждом шарде создаю таблицы с ReplicatedMergeTree, далее на 7-й машине (агрегационной), пытаюсь создать таблицу с Engine = Distributed и логично получаю отказ, ибо он ничего не знает про таблицы с других машин

M
13.06.2018
11:44:57
вы так делаете?

Andrey
13.06.2018
11:45:43
CREATE TABLE IF NOT EXISTS distributed_$table AS $table Engine = Distributed($cluster, $dbName, $table)")
Но она должна смотреть на реплицируемые таблицы созданные ранее

M
13.06.2018
11:46:49
вот тут из-за create table ... AS <TABLE> ругается наверное на то, что нету <TABLE> у вас на 7ой машине. Верно?

Andrey
13.06.2018
11:47:17
верно

M
13.06.2018
11:47:48
тогда Engine оставье как есть, а Create table сделаейте без AS <table> а укажите поля явно
и в конфиге обязательно указать кластер с названием $cluster

Andrey
13.06.2018
11:51:53
Отлично, создал точно такую же таблицу только с движком Distributed, все заработало.
Теперь вопрос про вьюхи, мы их создаем опять же на каждом шарде и над ними делаем Distributed?

M
13.06.2018
11:52:15
да

Andrey
13.06.2018
11:54:52
Большое спасибо! А это есть в документации? Может стоит её дополнить?

Alexey
13.06.2018
12:07:55
там всё есть

Andrey
13.06.2018
12:08:54
Это читал, не сразу догнал что нужно создавать такуюже таблицу, но с иным движком
examplов бы не помешало

nikita
13.06.2018
12:14:06
Добрый день. После обновления до 1.1.54385 во второй день получилась ситуация, что продублировало пачку данных на вставку. До этого такого поведения не было замечено. Может кто сталкивался и это проблема в версии?

Google

Ievgen
13.06.2018
13:23:42
Мм, вопрос, я могу сделать вот такой квери INSERT INTO test.test1 (EventDateTime,SomeData1) values (1528881276,splitByChar(' ', 'somevalue_part1 somevaluepart2')) и получить в колонке SomeData1 массив. Есть ли вариант создать таблицу(колонку) так, чтобы инсертить стринг а не результат работы функции splitByChar() но при этом записывался массив?

Tima
13.06.2018
13:35:18

Ievgen
13.06.2018
13:36:23
как раз исходная строка не нужна
нужно сделать split с заданным разделителем и записать в массив, я имею ввиду, есть вариант задать эту функцию на уровне create table не записывая исходную строку совсем?
сделать default или materialized можно, но не хочется хранить исходную строку

Tima
13.06.2018
13:39:28
Делайте splitByChar на уровне кода перед вставкой
Особой магии в КХ нет

Ievgen
13.06.2018
13:40:14
ну да это самый очевидный вариант делать split до записи, но не хотелось

Tima
13.06.2018
13:40:46
Тогда храните строку, это не так дорого как может показаться

Ievgen
13.06.2018
13:43:08
Ок спасибо

Aliaksandr
13.06.2018
13:48:19
fyi, вышел релиз chproxy с поддержкой произвольных конфиг-опций, которые отправляются в каждом запросе к кликхаусу. У каждого юзера может быть свой набор опций, чтобы не нужно было править конфиги самого кликхауса на каждой ноде под каждого юзера.
https://github.com/Vertamedia/chproxy/releases/tag/1.12.0

nikita
13.06.2018
14:33:36

Michal
13.06.2018
14:36:43
А вне матвью - все эти прелести можно (и нужно) использовать. :)

Andrey
13.06.2018
15:03:45

Arkady
13.06.2018
15:09:20

Deance
13.06.2018
15:41:02
Ребят, в кликхауз сейчас заливаю данные в кликхауз, пачками по 100к записей, и один insert занимает около 30 секунд.. Это нормально? Нагрузки на диск и на ядра нет, по сети задержек нет
Может какие настройки можно подкрутить? А то это мне кажется медленным

Ilya
13.06.2018
15:42:26

Deance
13.06.2018
15:42:46
Тоже нет

Google

Deance
13.06.2018
15:42:51
Около 70ти колонок
вроде немного

Tima
13.06.2018
16:26:18

Vitaly
13.06.2018
17:06:11
ENGINE = MergeTree(date, (project, platform, type), 8192)
нужно добавлять в первичный ключ дату, что бы нормально фильтровать по дням? или так достаточно?

Vitaly
13.06.2018
17:16:27


Vasiliy
13.06.2018
17:21:40
очевидно потому что постгрес не mq
мы так же делаем - кафка используется как буфер, там храним очередь сообщений за неделю, если что можем сделать рестеймент за это время
и на клиенте ничего хранить не надо - в очередь сбросили и забыли
ну и из кафки потом куда угодно раскидывать можно - можно сырые в КХ, агрегированные в sql, бекапы на с3 в файлы, в хадуп, в общем куда угодно из одного источника

Vitaly
13.06.2018
17:23:57
а ведь чем больше очередь в кафке, тем больше тормозов

Vasiliy
13.06.2018
17:24:38
почему? Не обязательно же с самого начала читать сообщения

Vitaly
13.06.2018
17:26:31
второй раз слышу про такое решение... заинтригован... а большие у вас объемы данных?

Vasiliy
13.06.2018
17:28:22
порядка 2-3 млрд в сутки

Vitaly
13.06.2018
17:29:42
круто... а постгрес вообще не используете?

Vasiliy
13.06.2018
17:32:04
для статы нет, мы одни и те же топики по-разному для разных целей стримим - где-то агрегируем и отбрасываем не нужные колонки, где-то мапим айдишники, куда-то сырые данные пишем

Vitaly
13.06.2018
17:34:03
а разве в кафке не теряются сообщения?