и еще - правильно я понимаю, что в случае единичного запроса Кликхаус его не параллелит на ядра?

Зависит от таблицы и самого запроса. У нас все вполне себе параллелится

условно имеется сервер с 72 ядрами и кучей ОЗУ. разницы по времени запроса с сервером с 2 ядрами и 64ГБ ОЗУ я не заметил

Зависит от движка таблицы, который вы используете, а так же от числа партиций в таблице (если это MergeTree)

https://github.com/yandex/ClickHouse/tree/master/dbms/tests/integration/test_cross_replication

mreci

Зависит от движка таблицы, который вы используете, а так же от числа партиций в таблице (если это MergeTree)

одна партиция

https://github.com/yandex/ClickHouse/tree/master/dbms/tests/integration/test_cross_replication

Это даже лучше :) статью пока не удается найти

Это даже лучше :) статью пока не удается найти

???

одна партиция

Если в ней будет несколько кусков, то будет параллелить

Агрегация вроде бы тоже параллелится

окей. Есть какой-либо тулз, который подсказывает как оптимизировать запросы?

или кликхаус достаточно умен сам по себе?

окей. Есть какой-либо тулз, который подсказывает как оптимизировать запросы?

мозг )

мозг )

+ )

или кликхаус достаточно умен сам по себе?

Он достаточно быстро работает )

Тулзы нет, но есть логи в которых кажет конвейер выполнения запроса

Тулзы нет, но есть логи в которых кажет конвейер выполнения запроса

по умолчанию включены?

А вообще если глянуть видяшки про устройство mergetree, то там все понятно будет

по умолчанию включены?

Да вроде, log level должен быть trace если не ошибаюсь

Есть подзапрос, который необходимо использовать в нескольких запросах, но с разными параметрами. Подскажите, пожалуйста, есть ли в clikhouse возможность создать view с параметрами или может обернуть запрос в функцию таким образом, чтобы не писать в каждом запросе один и тот же подзапрос?

Параметры берутся из приложения и подставляются в текст запроса.

Есть подзапрос, который необходимо использовать в нескольких запросах, но с разными параметрами. Подскажите, пожалуйста, есть ли в clikhouse возможность создать view с параметрами или может обернуть запрос в функцию таким образом, чтобы не писать в каждом запросе один и тот же подзапрос?

cte пока не работает (

Точнее его пока нет

А в with вроде бы работает, но я не тестил

Точнее его пока нет

в данной задаче, кмк, CTE не подойдёт

Подскажите, пожалуйста, синтаксис для создания таблицы с движком merge, по доке не соображу никак :(

Подскажите, пожалуйста, синтаксис для создания таблицы с движком merge, по доке не соображу никак :(

create table ... (...) engine = MergeTree partition by ... order by ...

create table ... (...) engine = MergeTree partition by ... order by ...

Там нужно перечислить все поля соединяемых таблиц?

Там нужно перечислить все поля соединяемых таблиц?

Сорян

Я прочитал merge tree

create table table_name as одна_из_таблиц_для_Merge ENGINE = Merge(database, 'pattern');

create table table_name as одна_из_таблиц_для_Merge ENGINE = Merge(database, 'pattern');

Спасибо

вопрос открыт

Имеет ли смысл под значения с id использовать int если стринги все равно хешируются, и уникальных значений этих Id планируется пару десятков. В общем,у меня вопрос цены удобства 1345 или "Вася"?

Имеет ли смысл под значения с id использовать int если стринги все равно хешируются, и уникальных значений этих Id планируется пару десятков. В общем,у меня вопрос цены удобства 1345 или "Вася"?

https://github.com/yandex/clickhouse-presentations/blob/master/meetup17/1_low_cardinality_strings.pdf

?

Подскажите, если я делаю партиционирование таблицы по полю, нужно ли его включать в order by?

Подскажите, если я делаю партиционирование таблицы по полю, нужно ли его включать в order by?

Если вам явно это поле не нужно в ORDER BY - тога не нужно.

И ещё баг https://github.com/yandex/ClickHouse/issues/3111

Если вам явно это поле не нужно в ORDER BY - тога не нужно.

По нему будет поиск. Т.е. нужно ли добавлять, если данные вроде как итак на куски побиты на диске будут

@konstantin_ptr по low cardinality string, подскажите, это уже вошло в какой либо релиз(и в какой возможно войдет)? https://github.com/yandex/ClickHouse/blob/master/CHANGELOG.md Здесь последний 18.6.0 и про эту фичу ни слова пока.

Если у вас партиции по одному полю, а в первичном ключе (ORDER BY) другие поля. И в запросе есть условие на партиции и первичный ключ, тогда КХ сначала выберет нужные партиции, а дальше будет искать с использованием первичног ключа уже конкретных партиций

@konstantin_ptr по low cardinality string, подскажите, это уже вошло в какой либо релиз(и в какой возможно войдет)? https://github.com/yandex/ClickHouse/blob/master/CHANGELOG.md Здесь последний 18.6.0 и про эту фичу ни слова пока.

его не успели перевести на английский, см. https://github.com/yandex/ClickHouse/blob/master/CHANGELOG_RU.md 18.12.13 зарелижен 19 часов назад

Если у вас партиции по одному полю, а в первичном ключе (ORDER BY) другие поля. И в запросе есть условие на партиции и первичный ключ, тогда КХ сначала выберет нужные партиции, а дальше будет искать с использованием первичног ключа уже конкретных партиций

Спасибо, получается, что тогда в order by добавлять не нужно. Попробуем ещё залить тестовые данные и погонять.

Отличная новость! Спасибо!

странно, только вчера развернул кликхаус)

Спасибо, получается, что тогда в order by добавлять не нужно. Попробуем ещё залить тестовые данные и погонять.

Почитайте тут https://clickhouse.yandex/docs/ru/operations/table_engines/mergetree/ "Выбор первичного ключа" Возможно я для ваших данных и запросов что-то не учёл

Подскажите пожалуйста, есть 3 шарда(по 2 реплики каждый), на каждый смотрит распределенная таблица со своим ключом. При попытке вставить данные на первом шарде в распределенную таблицу данные улетают на второй, соответственно данные на первом и третьем шарде не появляются. Возможна ли запись на три шарда одновременно через распределенные таблицы? Запрос cat /tmp/customer.csv | clickhouse-client --host=ch-shard01 --database=dfoodmart --query="INSERT INTO customer FORMAT CSV";

прошу прощения за глупый вопрос, а как вместо toYYYYMM(event_date) задать хранение партицы по неделям? и норм ли будет 48 партиц?

прошу прощения за глупый вопрос, а как вместо toYYYYMM(event_date) задать хранение партицы по неделям? и норм ли будет 48 партиц?

https://clickhouse.yandex/docs/ru/operations/table_engines/custom_partitioning_key/

https://clickhouse.yandex/docs/ru/operations/table_engines/custom_partitioning_key/

не, у меня вопрос глупее.. что написать вместо toYYYYMM(event_date) ?

Вам нужно чтобы даты округлялись до начала недели? Так 2018-09-12 -> 2018-09-10 ?

можно toMonday(event_date)

48 партиций нормально

можно toMonday(event_date)

чёрт, спасибо :)

парни, если у меня новая реплика ругается Can not clone replica, because the 172.16.100.158 updated to new ClickHouse version При этом на обоих репликах select version() выдает 18.12.13 - куда мне покопать?

крайний вопрос... планирую создать в таблице поле Nested (хранить ключ-значение). Вопрос в том, насколько хорошо будут сжиматься данные? они будут сжиматься по каждой строчке в Nested, либо по полю целиком? В ORDER BY насколько я понимаю можно добавить ведь только название Nested столбца?

48 партиций нормально

Подскажите, а в чем опасность бОльшего кол-ва партиций? Для повседневного бекапа очень удобно партиции по дням делать, что породит 365 партиций в год - могут быть какие-то проблемы?

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

в общем указал в order by nested.value, бум надеяться, что ClickHouse будет сжимать данные по нему :)

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

https://clickhouse.yandex/docs/ru/operations/settings/settings/#max_parallel_replicas но нужны sample

Добрый день. В какой момент ClickHouse для MergeTree перестаёт сливать куски одной партиции? Почему в конечном счёте партиция не состоит из одного куска. Есть какое-то ограничение по размеру куска, или по количеству записей, блоков?

Задается в конфиге, 200 гб по умолчанию. max_bytes_to_merge_at_max_space_in_pool, можно задать/ поменять для каждой таблицы, но через редактирование {table_name}.sql (с detach/attach). Он не перестает мержить. Просто вы еще не подождали 1000 лет. Т.е. последние мержи трудоемки и зачастую бессмысленны, поэтому кх их отодвигает на попозже.

Задается в конфиге, 200 гб по умолчанию. max_bytes_to_merge_at_max_space_in_pool, можно задать/ поменять для каждой таблицы, но через редактирование {table_name}.sql (с detach/attach). Он не перестает мержить. Просто вы еще не подождали 1000 лет. Т.е. последние мержи трудоемки и зачастую бессмысленны, поэтому кх их отодвигает на попозже.

? спасибо!

парни, если в зукипере для разных реплик в ../replica_name/parts разные данные (не полные в одной реплике) - это значит еще не доехала репликация? Надо ждать? Как понять, что все идет штатно?

В таблицах replication_queue смотрите

а такой вопрос в догонку, на сколько эффективнее запрос к партиции из одного куска, чем запрос к партиции из нескольких кусков, с использованием полей PK. Если кусков несколько, то CH придётся пробегать по всем кускам, и позиционироваться по разреженному индексу

А если в таблице replication_queue пусто?

А если в таблице replication_queue пусто?

значит все ОК, можно в system.parts посмотреть, там имена партов и размеры видны, можно сравнить по репликам.

а такой вопрос в догонку, на сколько эффективнее запрос к партиции из одного куска, чем запрос к партиции из нескольких кусков, с использованием полей PK. Если кусков несколько, то CH придётся пробегать по всем кускам, и позиционироваться по разреженному индексу

один кусок лучше, но партиции это очень мощный инструмент для фильтрации, поэтому лучше ухудшить 99% запросов на 0.0001% , но 1% запросов улучшить на 400%

ок, но через 1000 лет мы действительно дождёмся слияния всех партиций за один и тот же год?

там есть близкие по размеру, и хотелось бы получить из них одну большую партицию

там есть близкие по размеру, и хотелось бы получить из них одну большую партицию

OPTIMIZE

там есть близкие по размеру, и хотелось бы получить из них одну большую партицию

Всегда можно не ждать и сделать OPTIMIZE руками

OPTIMIZE

Опередил :)

Спасибо, попробуем!

В таблицах replication_queue смотрите

если там пусто, но select partition, sum(rows) from system.parts where table = 'dsp_raw' group by partition дает разное кол-во строк. Надо чинить репликацию для этой таблицы?

в 99.999% случаев из двух партиций по 100 вы получите одну по 200, и 0% прироста производительности, при этом 3 часа будет идти межр и три часа тормозить параллельные селекты.

хм. "правильная" реплика сейчас говорит в лог DB::Exception: Cannot write to ostream at offset 1030230037

если там пусто, но select partition, sum(rows) from system.parts where table = 'dsp_raw' group by partition дает разное кол-во строк. Надо чинить репликацию для этой таблицы?

При запросе к system.parts добавляйте условие на AND active

При запросе к system.parts добавляйте условие на AND active

ничего не изменилось

Когда я ищу по ключевому полю и CH берёт разреженный индекс, минимальное значение для ключевого поля он знает сразу, по первой записи в файле разреженного индекса, и если искомое значение меньше его то может сразу пропустить этот куско, а знает ли он максимальные значение ключевых полей из индекса, или начинает читать его целиком? и как выполняет поиск, последовательно или бинарным поиском?

не задумывался, индексы маленькие, лежат в ОЗУ (в специальном кеше).

https://clickhouse.yandex/docs/en/operations/table_engines/mergetree/#primary-keys-and-indexes-in-queries

create table test_cardinality (x String) engine = MergeTree order by tuple(); insert into test_cardinality (x) select concat('v', toString(number)) from numbers(10); alter table test_cardinality add column y LowCardinality(String); select * from test_cardinality; выдает ошибку Received exception from server (version 18.12.13): Code: 49. DB::Exception: Received from localhost:9000, 127.0.0.1. DB::Exception: Got empty stream in DataTypeWithDictionary::deserializeBinaryBulkStatePrefix: (while reading column y): (while reading from part /var/lib/clickhouse/data/vlk_test/test_cardinality/all_1_1_0/ from mark 0 with max_rows_to_read = 8192).

хм. "правильная" реплика сейчас говорит в лог DB::Exception: Cannot write to ostream at offset 1030230037

а dmesg и syslog что? у вас точно старый КХ остановился? проверьте ps

а dmesg и syslog что? у вас точно старый КХ остановился? проверьте ps

В общем, я прибил партиции в таблице сырых данных), так как у меня были нужны агрегированные данные. По итогу, в логе кликлахуса (не err) записи были, что "что-то идет" - но по факту кол-во строк не изменялось,. В общем, повторюсь, решил кардинально. Сейчас вроде все ок

Добрый день ! Скажите пожалуйста, если выполнить SHOW TABLES FROM database Вьюхи тоже отобразятся ? или нужно выполнить SHOW VIEWS FROM database ?

я верно понимаю что такого понятия как SHOW VIEWS в ClickHouse нет ?

я верно понимаю что такого понятия как SHOW VIEWS в ClickHouse нет ?

select * from system.tables where engine = 'MaterializedView'

Окей спасибо !!!

select * from system.tables where engine = 'MaterializedView'

Мне кажется это не совсем то

Вот у меня есть база