Спасибо вам всем за все что вы делаете :)

https://github.com/yandex/ClickHouse/blob/master/docs/en/development/build.rst

https://github.com/yandex/ClickHouse/blob/master/docs/en/development/build.rst

Алексей, а есть какая то информация по этому багу? https://github.com/yandex/ClickHouse/issues/859

Очень жить мешает :)

Неправильное выкидывание ненужных столбцов из подзапросов. Пока не исправили. Эта функциональность сделана неудобно и возникает желание сделать исправление более глобально. Может быть, получится исправить быстрее, если очень надо.

Неправильное выкидывание ненужных столбцов из подзапросов. Пока не исправили. Эта функциональность сделана неудобно и возникает желание сделать исправление более глобально. Может быть, получится исправить быстрее, если очень надо.

Ну это не прям критично для нас, просто может быть кто-то тоже с таким сталкивался. У нас данных пока не так много, что бы прям сильно страдать от этого

Просто если это пофиксить, то это сэкономит тонну процессорного времени

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

А можете ещё приложить структуры таблиц (SHOW CREATE TABLE)?

Да, сейчас напишу в issue

Закинул

Могу так же семпл данных приложить

Пригодится.

Ок, тогда подготовлю сейчас семпл в csv и закину тоже

Добавил семпл с данными. Там 2.5 млн строк

Как же все сложно в обычном sql: ... where sym in (select arrayJoin(arrayMap(x->cityHash64(x), ['AAA','BBB']))) вместо векторного: ... where sym in cityHash64 each ['AAA','BBB']

я бы делал has(arrayMap(x->cityHash64(x), ['AAA','BBB']), sym)

хотя наверно то же самое будет.

Совсем не ясно почему колонка (что в векторной базе = вектор), тут не считается вектором (массивом) по сути.

С has вообще не очень понятно как работает, те и не должно по идее работать, но главное в 200 раз медленнее

синтаксически список в правой части in это вообще тупл, т.е. не массив, хотя проверки относительно него делаются как для массива, проверяется существования общего типа всех компонентов. массивы же не считаются отношениями, это такой вектор-строка, в отличие от вектора-столбца, который представляет собой таблица с одной скалярной колонкой. arrayReduce немного маскирует это отличие, но не всегда помогает.

Has возвращает булевый массив, но он будет не соответствовать длине sym => странно что where его вообще принимает.

С has вообще не очень понятно как работает, те и не должно по идее работать, но главное в 200 раз медленнее

а вот это интересно. ну т.е. работать должно, почему бы и не работать, неужели он хеши считает на каждую строку.

Я не понимаю как where может работать при таком подходе, :) может только тиражирует все на каждую строку, отсюда и скорость.

SELECT has([1, 2, 3], 1) ┌─has([1, 2, 3], 1)─┐ │ 1 │ └───────────────────┘

а у вас sym это массив?

А, извиняюсь, параметры в голове местами переставил. Тогда странно что так медленно

Нет, сим - это колонка.

Чуть позже пришлю запрос как он в кдб выглядит и какой он получается (пока не получается).

SELECT * FROM ( SELECT number AS x FROM system.numbers LIMIT 100000000 ) WHERE has( ( SELECT arrayMap(x -> cityHash64(x), ['AAA', 'BBB']) ), x) Ok. 0 rows in set. Elapsed: 1.693 sec. Processed 100.01 million rows, 800.06 MB (59.07 million rows/s., 472.52 MB/s.) SELECT * FROM ( SELECT number AS x FROM system.numbers LIMIT 100000000 ) WHERE has(arrayMap(x -> cityHash64(x), ['AAA', 'BBB']), x) Ok. 0 rows in set. Elapsed: 4.484 sec. Processed 100.01 million rows, 800.06 MB (22.30 million rows/s., 178.43 MB/s.)в три раза отличается.

SELECT * FROM ( SELECT number AS y FROM system.numbers LIMIT 100000000 ) WHERE y IN ( SELECT arrayJoin(arrayMap(x -> cityHash64(x), ['AAA', 'BBB'])) ) Ok. 0 rows in set. Elapsed: 0.389 sec. Processed 100.01 million rows, 800.06 MB (257.02 million rows/s., 2.06 GB/s.)еще четыре раза. любопытно.

видимо в таком виде этот кусок не реплицируется на каждую строку.

Ну с точки зрения векторизации последний вариант понятно будет быстрее.

ну можно сделать вывод, что во-первых сервер не вычисляет cityHash64 от констант, иначе первый вариант работал бы как второй, а также для has с первым аргументом-константой как минимум в одном случае оптимальнее переписывать в in.

Не понял про константы.

Переписал

Признаться не так ужасно , кроме этой обработки массива, ну и словаря конечно, + скорость очень порадовала. сначала думал, ну вот, в 5 раз от кдб отстаёт, а потом смотрю - дату забыл поставить.

Не понял про константы.

has(arr,val) эквивалентно val in (select arrayJoin(arr)) если arr не зависит от строки. если arr сам столбец, то так не получится.

Парни, нужна помощь

какой-то разрыв шаблонов получается

а какие времена ответов. и где во втором запросе cityhash

Ля, я не так написал, сейчас.

и так CH кластер: <s3_r1> <shard> <weight>1</weight> <internal_replication>false</internal_replication> <replica> <host>xdray-1</host> <port>9000</port> </replica> </shard> <shard> <weight>1</weight> <internal_replication>false</internal_replication> <replica> <host>xdray-2</host> <port>9000</port> </replica> </shard> <shard> <weight>1</weight> <internal_replication>false</internal_replication> <replica> <host>xdray-3</host> <port>9000</port> </replica> </shard> </s3_r1> на каждом сервере создана локальная таблица с таким конфигом: ... ENGINE = ReplicatedMergeTree('/clickhouse/tables/s3_r1/omega/omega_sccp_local','{replica}', EventDate, cityHash64(sccp_src_local_ref, sccp_dst_local_ref), (EventDate, session_type, Timestamp, sccp_cr_m3ua_opc, sccp_cr_m3ua_dpc, cityHash64(sccp_src_local_ref, sccp_dst_local_ref)), 8192);

т.е. Replicated, но реальных реплик нет

поверх создана таблица типа: CREATE TABLE omega.omega_sccp AS omega.omega_sccp_local ENGINE = Distributed(s3_r1, omega, omega_sccp_local, cityHash64(sccp_src_local_ref,sccp_dst_local_ref,sccp_cr_m3ua_opc,sccp_cr_m3ua_dpc));

при вставке строки в таблицу идет копирование на каждый шард

т.е. вставляешь 1 строку, получаешь 3

причем это дубликаты

и запрос из omega.omega_sccp их честно выдает

в чем фокус?

@orantius время ответа: КХ - около 200мс, что в общем-то много все равно. В кдб - 48мс

в чем фокус?

У вас replicated таблицы являются репликами друг друга.

Поскольку они в разных шардах, это неправильно.

Ситихеш - это временное решения для быстрой нормализации строк.

То есть путь (первый параметр движка) должен быть разный в разных шардах.

Поскольку они в разных шардах, это неправильно.

не очень понял... ща еще раз перепроверю

Вопрос: клиент выдает время так сказать итоговое на клиенте: те + сеть?

ща гляну как это выглядит в ZK

То есть путь (первый параметр движка) должен быть разный в разных шардах.

Все понял. Спасибо!

А как взять два последние элемента из массива? И потом разгруппировать

прекрасный вопрос. мы однажды столкнулись с тем, что arrayElement в качестве индекса принимает константу, а длина массива не константа.

сейчас это сделано через отрицательные индексы, такой себе питон.

а разгруппировать это что, arrayJoin?

Отрицательные индексы хорошо, но что-то с ходу не вижу функции как вырезать два элемента последних

И главное как потом это все развернуть.

Т.е. по идее что-то вроде argMax<два>(...) в итоге. Если надо не последнее значение, а два или три последних

а что должно получиться, массив из двух элементов?

Ну в итоге должен появиться не массив, а будет по две или сколько надо строки на каждую группировку. Для случая одной строки argMax использую.

звучит как вот такая штука, arrayJoin([x[-2], x[-1]]) , но вообще то что вы описываете похоже на работу с историей каких-то событий, это обычно заканчивается либо крайне нечитаемыми креативами, либо тупиком.

Не, всё нормально работает в проде.

Вопрос: клиент выдает время так сказать итоговое на клиенте: те + сеть?

Да, доставка на клиент учитывается.

звучит как вот такая штука, arrayJoin([x[-2], x[-1]]) , но вообще то что вы описываете похоже на работу с историей каких-то событий, это обычно заканчивается либо крайне нечитаемыми креативами, либо тупиком.

Ага. Спасибо. ArrayJoin то что нужно, осталась только проблема что нечем резать array

Предположительно это эквилибристикой с arrayEnumerate можно изобразить.

CH завёлся на Windows 10 в местном бэше %)

TZ='Europe/Moscow'; export TZ; sudo nohup clickhouse-server —config-file=/etc/clickhouse-server/config.xml &

из пакета или собранный?

Из пакета xenial

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

например сейчас в столбце записано region Moscow. заменить на region 2 группируем по регионам и достаем по 2 - Moscow

@maksim_melnichuk ес-но. мне казалось что я тут об этом каждый второй день пишу: про словари, про нормализацию строк и тд и тп. собственно у меня выборка по строкам ~2с, по UInt64 - ~0.1с

там еще enumы были вроде, только пользоваться ими раньше было как-то неудобно, помню

t1 (sym MATERIALIZED cityHash64(symN), symN String). и каждую выборку делаю where ... AND sym = cityHash64(строка).

а имя - выбираю из дикта, где лежат опять же cityHash и имя

Доброго времени суток, подскажите о чем говорит исключение (Too much parts. Merges are processing significantly slower than insert ....) и какие действия надо сделать что бы оно не возникало или возникало реже. Заранее признателен

какая версия сервера?

ClickHouse server version 1.1.54236

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

Вообще будет шустрее работать. У меня например из-за race condition лежит не id пользователя, а хэш от "сайт.айди юзера", пока не заморачивался, т.к. даже по md5 кх вполне не плохо катается и даже группирует

Доброго времени суток, подскажите о чем говорит исключение (Too much parts. Merges are processing significantly slower than insert ....) и какие действия надо сделать что бы оно не возникало или возникало реже. Заранее признателен

Упрощенно: Кх каждый инсерт в таблицу пишет в файлик. Фоновый процесс (мерж) их оптимизирует в удобоваримый форму (склеивает в более жирные куски, сортирует по ключу внутри).

Доброго времени суток, подскажите о чем говорит исключение (Too much parts. Merges are processing significantly slower than insert ....) и какие действия надо сделать что бы оно не возникало или возникало реже. Заранее признателен

Поэтому кх любит мало инсертов но по большой пачке данных. Или хотя бы таблицу буфер которая будет помогать клеить данные

Вопрос по внутренностям: а читает с диска КХ в несколько потоков? Или, например, одним потоком отдельный блок данных.

спасибо за ответ

подскажите, кто что использует для построения разных чартов с CH. интерактивные приложения какие то подключаются? или опенсорс может какой есть. интересует что-то вроде дешбордов и тп

tabix в чарты недавно научился superset умеет с sqlalchemy работать, а для алхимии есть пара драйверов вроде

Grafana что-то простое умеет еще

tabix в чарты недавно научился superset умеет с sqlalchemy работать, а для алхимии есть пара драйверов вроде

Кстати, табикс так и подтекает? Не удалось решить эту проьоему?