Ведь судя по доке: Фрагмент INSERT INTO t VALUES парсится полноценным парсером, а данные (1, 'Hello, world'), (2, 'abc'), (3, 'def') - быстрым потоковым парсером.

В кликхаус - нет. Можно написать например INSERT INTO table(col1, col2) FORMAT JSONEachRow

интересно, спасибо

dictGetString('some_dict_name', 'name', tuple(toUInt64(3))) AS rname Оказывается надо так

dictGetString('some_dict_name', 'name', tuple(toUInt64(3))) AS rname Оказывается надо так

странно, что-то тут не то

Ведь судя по доке: Фрагмент INSERT INTO t VALUES парсится полноценным парсером, а данные (1, 'Hello, world'), (2, 'abc'), (3, 'def') - быстрым потоковым парсером.

там все "потоково" парсится

TabSeparated пошустрее, но не сильно намного

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

Круче всего в RowBinary наверное писать

Почему странно? он же сначало сортирует а потом LIMIT

На самом деле ClickHouse делает ORDER BY и LIMIT одновременно (частичная сортировка в рамках каждого блока). Но при большом количестве данных, оперативки может всё-равно не хватить.

а есть какая-то возможность, посмотреть параметры engine существующей таблицы? в system.tables и в describe этого нет (об этом дока говорит даже)

В старых версиях ClickHouse, в таблице system.tables был виртуальный (невидимый) столбец engine_full. Его можно указать в SELECT. В новых версиях, виртуальные столбцы стали настроящими - просто есть столбец engine_full.

Всем, привет. Подскажите пожалуйста для Alter table T optimize partition X final, важно чтобы партиция была подключена? или может и в detached быть?

Важно. Про detached партиции сервер ничего не знает, за исключением случая, когда делается ATTACH.

То есть, OPTIMIZE detached данных нельзя сделать.

Спасибо.

можно наверно во время вставки делать unhex(‘dfdfd45’) ?

В формате Values есть два вида парсера. Один - быстрый потоковый парсер, который работает, если во вставляемых данных нет выражений. Другой - весьма медленный, который интерпретирует выражения. Вы можете написать выражение unhex(...) при вставке, но работаеть будет медленно.

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

Совершенно верно. Если не использовать выражения при вставке, то Values примерно такой же как CSV и чуть медленнее TSV. А если использовать, то сильно медленнее.

ну будет медленно, понятно. придется терпеть. вариантов-то нет больше, все равно, так?

Добрый день. Подскажите пожалуйста в чем может быть проблема. select dictGetString('some_dict_name', 'name', toUInt64(3)) as rname в ответ получаю Code: 53. DB::Exception: Received from localhost:9000, 127.0.0.1. DB::Exception: Third argument of function dictGetString must be (UInt64).

Возможно у вас словарь с составным ключом, и требуется tuple(x). Сообщение об ошибке плохое.

Нет, не составной

ну будет медленно, понятно. придется терпеть. вариантов-то нет больше, все равно, так?

Если там в VALUES только константы - то будет быстро. Сообщение об ошибке действительно плохое. ➜ cat /tmp/values.txt /tmp/values2.txt | clickhouse-client --query='INSERT INTO tracklog VALUES' -t --stacktrace Code: 53. DB::Exception: Type mismatch in IN or VALUES section. Expected: UInt64. Got: String Stack trace: 0. clickhouse-client(StackTrace::StackTrace()+0x16) [0x490b4b6] 1. clickhouse-client(DB::Exception::Exception(std::string const&, int)+0x1f) [0x2686d3f] 2. clickhouse-client() [0x420ce12] 3. clickhouse-client(DB::convertFieldToType(DB::Field const&, DB::IDataType const&, DB::IDataType const*)+0x53) [0x420d353] 4. clickhouse-client(DB::ValuesRowInputStream::read(std::vector<COWPtr<DB::IColumn>::mutable_ptr<DB::IColumn>, std::allocator<COWPtr<DB::IColumn>::mutable_ptr<DB::IColumn> > >&)+0x838) [0x4435c18] 5. clickhouse-client(DB::BlockInputStreamFromRowInputStream::readImpl()+0x75) [0x466a175] 6. clickhouse-client(DB::IProfilingBlockInputStream::read()+0x1fd) [0x3ad697d] 7. clickhouse-client(DB::AsynchronousBlockInputStream::calculate(MemoryTracker*)+0x47) [0x26943b7] 8. clickhouse-client(ThreadPool::worker()+0x167) [0x4a18727] 9. clickhouse-client() [0x4dc4c9f] 10. /lib64/libpthread.so.0(+0x7e25) [0x7f147320ee25] 11. /lib64/libc.so.6(clone+0x6d) [0x7f1472c3a34d]

ну будет медленно, понятно. придется терпеть. вариантов-то нет больше, все равно, так?

Как лучше всего вставлять бинарные данные. 1. Можно использовать формат TSV. Тогда требуется заменять байты - перевод строки 0x0A, таб 0x09, бэкслеш 0x5C на \n, \t, \\. Также рекомендуется (но не обязательно) экранировать \r, \0. 2. Можно использовать формат RowBinary. Он более эффективен для парсинга и не требует экранирования. Строка пишется так: сначала длина строки в формате varint, потом байты строки.

у меня в values unhex встречается

dictGetString('some_dict_name', 'name', tuple(toUInt64(3))) AS rname Оказывается надо так

Тип словаря complex_key_..., но ключ состоит из одного элемента?

по RowBinary — а как колонки разделяются и как разные типы кодируются? ну там int?

https://clickhouse.yandex/docs/ru/interfaces/formats/#rowbinary

<structure> <key> <attribute> <name>id</name> <type>UInt64</type> </attribute> </key> <attribute> <name>name</name> <type>String</type> <null_value></null_value> </attribute> </structure>

да вроде не составной

По поводу сообщения об ошибке: Type mismatch in IN or VALUES section. Expected: UInt64. Got: String Скорее всего, значение типа String (например, unhex('ABCD')) встречается на позиции того столбца, который имеет тип UInt64. Было бы хорошо выводить информацию о позиции и имени этого столбца... и о самом значении. Если есть сомнения, что это сообщение некорректно - просьба поделиться структурой таблицы, несколькими строками данных в качестве примера, и примером, как производится вставка.

а, подумал что это native формат и недокументированю

вставка производилась как insert into table values ()

точная структура и точные значения не сохранились, к сожалению.

1) имеет ли смысл укорачивать длинну ключа, для тех случаев когда там есть длинные id? но они постоянно повторяются. например в начале может быть имя компании - в 99% там будет "yandex"

Сами значения первичного ключа хранятся для каждых N строк таблицы, где N (index_granularity) по-умолчанию - 8192. Обычно это значит, что первичный ключ занимает мало места в оперативке. На скорость фильтрации данных его длина почти не влияет. Тем не менее, делать очень много столбцов часто бессмысленно. Если они не нужны для сортировки для Collapsing/Replacing/Summing/AggregatingMergeTree, и если последние столбцы не помогают фильтрации, то держать их в первичном ключе не нужно. Описание того, как работает фильтрация: https://clickhouse.yandex/docs/ru/operations/table_engines/mergetree/#_4

а, подумал что это native формат и недокументированю

RowBinary - это бинарный формат, в котором данные уложены по строкам. Первая строка, вторая строка, и т. п. Весьма привычно для работы. Native формат - это бинарный формат, который состоит из блоков, а в каждом блоке данные уложены по столбцам. Менее привычно для использования, и не документировано. Что эффективнее для приложения, которое вставляет данные - это ещё под вопросом, так как само приложение может тратить ресурсы на преобразование в такой формат.

Подскажите пожалуйста, как лучше сделать? У меня в запросе происходит фильтрация массивов, получается много вложенных arrayFilter и arrayMap, я хочу 9для отладки и лучшего понимания проиходящего) раздзелить из чтобы было так примерно: SELECT arrayFilter(..., someval) as r1, arrayMap(..., r1) as r2, arrayFilter(..., r2) as result Не увеличивается ли расход памятит от того что я размазываю много вложенных вызовов в строку? И если да - можно ли делать такие алиасы не в селекте или езе как-то исключить их из выборки?

Подскажите пожалуйста, как лучше сделать? У меня в запросе происходит фильтрация массивов, получается много вложенных arrayFilter и arrayMap, я хочу 9для отладки и лучшего понимания проиходящего) раздзелить из чтобы было так примерно: SELECT arrayFilter(..., someval) as r1, arrayMap(..., r1) as r2, arrayFilter(..., r2) as result Не увеличивается ли расход памятит от того что я размазываю много вложенных вызовов в строку? И если да - можно ли делать такие алиасы не в селекте или езе как-то исключить их из выборки?

Расход памяти не увеличивается. Суть в том, что в запросе все одинаковые выражения склеиваются и считаются один раз. Можно делать такие алиасы не в SELECT-е, а в секции WITH, вот так: WITH expr AS alias, expr2 AS alias2... SELECT alias, alias2, ...

они не одинаковые, там r1, r2 и result считаются отдельно для каждой строчки

то есть у меня получается либо arrayFilter(..., arrayMap(..., arrayFilter(..., someval))) as result либо так как написано сообщением выше. Меня смущает что в случае вложенных фильтров и мапов после подсчёта результата для каждой строки промежуточные подсчёты можно выкинуть, а случае когда они возращаются - выкинуть их нельзя

то есть у меня получается либо arrayFilter(..., arrayMap(..., arrayFilter(..., someval))) as result либо так как написано сообщением выше. Меня смущает что в случае вложенных фильтров и мапов после подсчёта результата для каждой строки промежуточные подсчёты можно выкинуть, а случае когда они возращаются - выкинуть их нельзя

Да, так будет больше памяти расходоваться.

Я вынес эти части в WHERE, получается что-то вроде SELECT result ... WHERE notEmpty(arrayFilter(..., someval) as r1) AND notEmpty(arrayMap(..., r1) as r2) AND notEmpty(arrayFilter(..., r2) as result) Будет ли эта конструкция вести себя как я ожидаю? Есть ли в ней еще какие-то отрицательные стороны?

по крайней мере я ожидаю что notEmpty должен быть достаточно быстрый чтобы этого практически не было заметно

по крайней мере я ожидаю что notEmpty должен быть достаточно быстрый чтобы этого практически не было заметно

Да. FYI. Ещё есть функция ignore, которая всегда возвращает 0. Можно писать WHERE NOT ignore(...)

Спасибо большое, так действительно лучше!

Спасибо большое, так действительно лучше!

А с секцией WITH будет удобнее.

Но в секции WITH оно будет высчитываться для каждой строки разве?

Но в секции WITH оно будет высчитываться для каждой строки разве?

Если будет использоваться в SELECT, то будет считаться.

Я был уверен что она считается один раз перед запросом

Ага.. Спасмбоо второй раз

А с секцией WITH будет удобнее.

После переноса в WITH вылезла ошибка No alias for non-trivial value in ARRAY JOIN: resultRow

А нет ли более красивого варианта для arrayMap((x,y,z)->(x,y,z),nested.x,nested.y,nested.z) ?

А нет ли более красивого варианта для arrayMap((x,y,z)->(x,y,z),nested.x,nested.y,nested.z) ?

Нет.

После переноса в WITH вылезла ошибка No alias for non-trivial value in ARRAY JOIN: resultRow

Тоже с таким сталкивался

Тоже с таким сталкивался

Давайте добавим минимальный кейс (где это поведение некорректно) в GitHub issues.

Давайте добавим минимальный кейс (где это поведение некорректно) в GitHub issues.

Не уверен, что сохранился запрос; завтра попробую припомнить и воспроизвести.

Кстати, на тему WITH задам дурацкий вопрос select a, a+1 from t with a as b select b, b+1 from t Сколько раз вычислится а? И в том и в другом случае один?

create table test.tab1 (a1 Int32, b1 Int32) engine = MergeTree order by a1; create table test.tab1_copy (a1 Int32, b1 Int32) engine = MergeTree order by a1; insert into test.tab1 values (1, 2); insert into test.tab1_copy values (2, 3); select tab1.a1, tab1_copy.a1, tab1.b1 from test.tab1 any left join test.tab1_copy on tab1.b1 + 3 = b1 + 2

поправилось - https://github.com/yandex/ClickHouse/commit/3b8e3c854c7020a9ad77935bc2fd74730b6a4db0

Кстати, на тему WITH задам дурацкий вопрос select a, a+1 from t with a as b select b, b+1 from t Сколько раз вычислится а? И в том и в другом случае один?

Да.

@milovidov_an Скажите пожалуйста, когда ближайший релиз?

@milovidov_an Скажите пожалуйста, когда ближайший релиз?

Как раз сейчас готовлю тестинг. У нас в тестинге уже выложено сегодня. Исправляем мелкую регрессию. Сейчас проведу нагрузочное тестирование на тестовой среде и если всё Ок - выложим в stable.

Кто-то знает, что может задерживать мутации(ALTER TABLE...DELETE WHERE...)? Висят уже более суток. Мерджи крупные все прошли. Оптимизировать таблицы нужно?

Кто-то знает, что может задерживать мутации(ALTER TABLE...DELETE WHERE...)? Висят уже более суток. Мерджи крупные все прошли. Оптимизировать таблицы нужно?

А в логах должна быть информация, у меня мутации долго не проходили из-за незаконченных мержей

в логах только: 2018.08.30 10:22:12.412130 [ 17 ] <Information> default.graphite_tree (ReplicatedMergeTreeQueue): Loading 1 mutation entries: 0000000008 - 0000000008 2018.08.30 10:22:27.632989 [ 76 ] <Information> default.graphite_tree (ReplicatedMergeTreeQueue): Loading 1 mutation entries: 0000000009 - 0000000009 2018.08.30 10:22:32.639549 [ 17 ] <Information> default.graphite_tree (ReplicatedMergeTreeQueue): Loading 1 mutation entries: 0000000010 - 0000000010 2018.08.30 10:22:41.217139 [ 19 ] <Information> default.graphite_tree (ReplicatedMergeTreeQueue): Loading 1 mutation entries: 0000000011 - 0000000011 2018.08.30 10:22:46.957097 [ 79 ] <Information> default.graphite_tree (ReplicatedMergeTreeQueue): Loading 1 mutation entries: 0000000012 - 0000000012 2018.08.30 10:22:51.736090 [ 11 ] <Information> default.graphite_tree (ReplicatedMergeTreeQueue): Loading 1 mutation entries: 0000000013 - 0000000013 2018.08.30 10:23:24.037055 [ 62 ] <Information> default.graphite (ReplicatedMergeTreeQueue): Loading 1 mutation entries: 0000000008 - 0000000008 2018.08.30 10:23:33.806679 [ 70 ] <Information> default.graphite (ReplicatedMergeTreeQueue): Loading 1 mutation entries: 0000000009 - 0000000009 2018.08.30 10:23:46.449111 [ 76 ] <Information> default.graphite (ReplicatedMergeTreeQueue): Loading 1 mutation entries: 0000000010 - 0000000010 2018.08.30 10:23:52.607061 [ 65 ] <Information> default.graphite (ReplicatedMergeTreeQueue): Loading 1 mutation entries: 0000000011 - 0000000011 2018.08.30 10:23:57.334559 [ 75 ] <Information> default.graphite (ReplicatedMergeTreeQueue): Loading 1 mutation entries: 0000000012 - 0000000012 2018.08.30 10:24:01.898373 [ 81 ] <Information> default.graphite (ReplicatedMergeTreeQueue): Loading 1 mutation entries: 0000000013 - 0000000013

и они до сих пор не выполнились

Первая вообще с 27.08

Хотя прогресс есть, поле parts_to_do снижается у всех мутаций

значит, мутации выполняются

хотя что-то очень медленно. Какой объем партиций?

20-400G

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

такое поведение исправлено только в 18.4.0

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

А в последней версии поправили?

18.6.0 54401 да, похоже на то, у всех мутаций в списке партиций - все

хм, в 18.6.0 уже не должно быть такого по идее

только если мутации не были созданы еще до обновления

либо в 18.6 регресс случился

мутации были созданы уже на 18.6?

да, на предудущей(1.54390) я не пробовал удалять данные

https://github.com/yandex/ClickHouse/pull/2694 вот тут вроде поправили, может не до конца...

поправилось - https://github.com/yandex/ClickHouse/commit/3b8e3c854c7020a9ad77935bc2fd74730b6a4db0

супер, спасибо. когда в stable?)

К xml конфигах clickhouse можно инклюдить другие конфиги или перменные?

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

К xml конфигах clickhouse можно инклюдить другие конфиги или перменные?

Можно. Если используете стандартный /etc/metrika.xml - то всё работает "из коробки". Если хотите эти "общие" фрагменты записывать куда-то ещё - то тоже можно, но конфигурация несколько неочевидна.

Тут пример как у нас сконфигурировано: https://gist.github.com/filimonov/cbafa8ca85268693b7bf28c14473ab34

спасибо