Я вот не понимаю до конца от чего зависит ибо с одного и того же сервера с 2ух компов разная скорость в разы

меряйте на клиенте, где-то там проблема скорее всего

Можно добавляеть если не меняется сортировка для ПК (т.е. в ключ добаляются поля с дефалтовыми значениями) и работает только для MergeTree.

Подскажите, пожалуйста, где можно почитать про эту фичу? Конкретно что интересует: - начиная с какой версии она поддерживается? - поддерживается ли ReplicatedMergeTree? - каким запросом можно добавить поля в ключ?

ReplicatedMergeTree не поддерживается, почитать можно тут https://github.com/yandex/ClickHouse/search?q=MODIFY+PRIMARY+KEY&unscoped_q=MODIFY+PRIMARY+KEY , но, там нет проверок на то что этот альтер может вам все развалить

ReplicatedMergeTree не поддерживается, почитать можно тут https://github.com/yandex/ClickHouse/search?q=MODIFY+PRIMARY+KEY&unscoped_q=MODIFY+PRIMARY+KEY , но, там нет проверок на то что этот альтер может вам все развалить

Спасибо. Это печально. Тогда получается единственное решение - заново создать таблицы и залить в них все данные?

Не знаю куда копать. Запускаю большой запрос и он виснет даже на пустой базе в логе бесконечно выводится подобное <Debug> InterpreterSelectQuery: MergeTreeWhereOptimizer: condition dtl >= '2018-08-13' moved to PREWHERE

около 350 раз в секунду %)

совпадение? возможно 162 млрд перестали влезать в дефолтный 5ГБ markscache что в select * from system.asynchronous_metrics where metric like '%ark%'

MarkCacheFiles 986 MarkCacheBytes 41328 Возможно действительно перестали влезать в какое-то стандартное значение. Вот данные по таблице: select active, table, sum(rows),formatReadableSize(sum(bytes)), formatReadableSize(sum(marks_size)), formatReadableSize(sum(primary_key_bytes_in_memory)), count() from system.parts group by table, active order by table, active 1 T 162573124579 252.25 GiB 1.18 GiB 227.11 MiB 133

Спасибо. Это печально. Тогда получается единственное решение - заново создать таблицы и залить в них все данные?

Да

Добрый день, коллеги! А можете, пожалуйста, подсказать, как сделать в ClickHouse group_concat?

groupArray

пример

SELECT groupArray(number) FROM ( SELECT number FROM system.numbers LIMIT 5 ) ┌─groupArray(number)─┐ │ [0,1,2,3,4] │ └────────────────────┘

Спасибо!

я когда вставляю данные, то передаю и date и datetime, date считает сам libclickhouse-cpp используя простой алгоритм timestamp/3600/24, datetime передается как есть, как unix timestamp.

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

MarkCacheFiles 986 MarkCacheBytes 41328 Возможно действительно перестали влезать в какое-то стандартное значение. Вот данные по таблице: select active, table, sum(rows),formatReadableSize(sum(bytes)), formatReadableSize(sum(marks_size)), formatReadableSize(sum(primary_key_bytes_in_memory)), count() from system.parts group by table, active order by table, active 1 T 162573124579 252.25 GiB 1.18 GiB 227.11 MiB 133

тогда странно, может и в правду баг.

тогда странно, может и в правду баг.

Да, проще завести баг и ждать комментов :) https://github.com/yandex/ClickHouse/issues/2914

Да, проще завести баг и ждать комментов :) https://github.com/yandex/ClickHouse/issues/2914

без шагов на воспроизведение и сравнения с пред. версиями, шансов примерно -100500.

без шагов на воспроизведение и сравнения с пред. версиями, шансов примерно -100500.

Можно, конечно, завернуть куда-нибудь 250 гигов данных, но малореально. А вот с прошлыми версиями сравню ночью когда падение сервера никто не заметит :) Спасибо за наводку

зачем 250 гигов, просто нагенерите данных с таким же распределением с помощью numbers % и rand https://gist.github.com/den-crane/a72614fbe6d23eb9c2f1bce40c66893f

Не знаю куда копать. Запускаю большой запрос и он виснет даже на пустой базе в логе бесконечно выводится подобное <Debug> InterpreterSelectQuery: MergeTreeWhereOptimizer: condition dtl >= '2018-08-13' moved to PREWHERE

если optimize_move_to_prewhere выставить в нолик, то запрос тоже подвисает, но хотя бы киляется сравнительно быстро.

коллеги, а можно как-то попросить кликхаус не генерировать <>-preprocessed.xml конфиги или указать отличную от оригиналов директорию?

в новых версиях уже вроде так https://github.com/yandex/ClickHouse/pull/2443 , не помню с какой

а нет, нифига не так, для словарей нету -preprocessed, а config-preprocessed.xml и preprocessed.xml все еще есть

не так, это еще не доделано и не смержено

ясно. решили в итоге индивидуальным маунтом нужных файлов

зачем 250 гигов, просто нагенерите данных с таким же распределением с помощью numbers % и rand https://gist.github.com/den-crane/a72614fbe6d23eb9c2f1bce40c66893f

Спасибо за помощь, на рандомных данных все то же самое, проапдейчу ишую добавив скрипт

если optimize_move_to_prewhere выставить в нолик, то запрос тоже подвисает, но хотя бы киляется сравнительно быстро.

при том если разобрать запрос на части - они выполняются моментально. может быть я упускаю какое-то ограничение на сложность запроса? у меня куча join и union в нём всё что нашёл на мой взгляд подходящее я подкрутил, хотя и дефолтов должно было хватить на сколько я могу понять <max_query_size>2097152</max_query_size> <!-- 2 MiB--> <max_subquery_depth>500</max_subquery_depth> <max_pipeline_depth>5000</max_pipeline_depth> <max_ast_depth>5000</max_ast_depth> <max_ast_elements>50000</max_ast_elements> правда версия довольно старая у меня 1.1.54385

Добрый вечер, какую агрегирующую ф-цию надо использовать чтоб добавлять элемент к массиву (который должен быть выходом агрегирующей ф-ции). Я про AggregatingMergeTree

в финальном запросе я хотел брать последний элемент из массива

как вариант я рассматривал Nested структуру и SummingMergeeTree, в качестве ключа указывать таймстемп

Добрый вечер, какую агрегирующую ф-цию надо использовать чтоб добавлять элемент к массиву (который должен быть выходом агрегирующей ф-ции). Я про AggregatingMergeTree

агрегатная функция чтоб собирать элементы группы в массив - groupArray. Вы об этом спрашиваете?

агрегатная функция чтоб собирать элементы группы в массив - groupArray. Вы об этом спрашиваете?

возможно, "Creates an array of argument values. Values can be added to the array in any (indeterminate) order." а как потом получить последнее значение (по таймстемпу)? В моем случае каждый элемент который я хочу добавлять к массиву состоит из 2х частей - таймстемп и некоторое Value. Мне надо в результате агрегации уметь вытаскивать это последнее Value

А нужны ли Вам в таком случае ВСЕ значения? Если вам нужно только последнее по значению таймстампа - то это argMax( value, timestamp)

А нужны ли Вам в таком случае ВСЕ значения? Если вам нужно только последнее по значению таймстампа - то это argMax( value, timestamp)

да, это хорошая идея, как понимаю. надо ее использовать как агрегатную функцию

то есть поле будет the_last_value AggergateFunction(argMax, UInt16, DateTime) ?

argMaxState функция, а тип AggregateFunction (MAX,тип)

Кто-нибудь пробовал подключатся из Power BI к ClickHouse ? Не пойму возможно ли это вообще. Может через ODBC там...

посмотрите можно ли через Mondrian подцепиться, я Mondrian прикрутил для PoC

а вообще ODBC вроде же есть

то есть поле будет the_last_value AggergateFunction(argMax, UInt16, DateTime) ?

Верно. Cинтаксис этих агрегатных функций иногда не совсем очевиден - я обычно просто создаю таблицу примерно так CREATE table x ENGINE=TinyLog AS SELECT argMaxState(number, toDateTime(number)) as last_value FROM numbers(10); и потом смотрю SHOW CREATE TABLE x; :)

Верно. Cинтаксис этих агрегатных функций иногда не совсем очевиден - я обычно просто создаю таблицу примерно так CREATE table x ENGINE=TinyLog AS SELECT argMaxState(number, toDateTime(number)) as last_value FROM numbers(10); и потом смотрю SHOW CREATE TABLE x; :)

это хорошая идея

Верно. Cинтаксис этих агрегатных функций иногда не совсем очевиден - я обычно просто создаю таблицу примерно так CREATE table x ENGINE=TinyLog AS SELECT argMaxState(number, toDateTime(number)) as last_value FROM numbers(10); и потом смотрю SHOW CREATE TABLE x; :)

я пытюась понять как туда инсертить, надо писать что-о типа INSERT INTO x VALUES (argMaxState(10, toDateTime(10))) ?

я пытюась понять как туда инсертить, надо писать что-о типа INSERT INTO x VALUES (argMaxState(10, toDateTime(10))) ?

Чаще всего движок AgregateMergeTree используют для materialized view поверх таблицы фактов.

Чаще всего движок AgregateMergeTree используют для materialized view поверх таблицы фактов.

да, так и собираюсь, просто хотел потестить вручную без МВ

Чтоб потестить лучше наверное что-то типа: INSERT INTO x SELECT argMaxState(number, toDateTime(number)) as last_value FROM numbers(10);

Но и с values по идее должно работать

Чтоб потестить лучше наверное что-то типа: INSERT INTO x SELECT argMaxState(number, toDateTime(number)) as last_value FROM numbers(10);

ваш запрос отработал, а вот мое вылетело с ошибкой insert into x values (argMaxState(10, toDateTime(10))) INSERT INTO x VALUES Exception on client: Code: 184. DB::Exception: Aggregate function argMaxState(10, toDateTime(10)) is found in wrong place in query

Ну потому что агрегатные функции довольно бессмыслены для единственного значения. Можно сделать на таблицах, если обязательно хочется получить конкретное состояние функции без запросов сторонних таблиц. Примерно так INSERT INTO x VALUES ( argMaxArrayState( [7, 5, 6], [ now(), now()+1, now()-1 ] ) );

А делиты уже есть в каком-нибудь релизовом и юзабельном виде?

Привет! Экспериментирую тут с кастомным PARTITION BY ключом в обычном MergeTree. Хочу партишнинг по (дата, группа), где группа - это 1000 числовых значений (можно считать, что это client_id mod 1000). Задача в том, чтобы эффективно использовать 1ТБ диск, удаляя слишком большие группы чаще, чем маленькие. То есть если в группе записей на 1МБ, она может жить и год (365 партиций для неё), а если 300ГБ, то, скажем, один или два дня только. Данные поступают из 10-15 источников, почти отсортироваными по группам и времени, но в кажом источнике есть почти все группы. Каждый источник вствляет по 50-100МБ за раз раз в 20-30 секунд. Раз в несколько минут бывают маленькие вставки в несколько мегабайт или даже меньше. Проблема на дефолтном конфиге - Too many parts. Если увеличить max_replicated_merges_in_queue, то всё какое-то время работает, но старые неактивные партиции не успевают удалятся и на файловой системе через какое-то время кончаются inodes. Если взять ФС без inodes, всё равно всё будет плохо ибо новые parts всё равно появляются быстрее, чем удаляются старые (пробовал также разные разные значения *_lifteme). А уж если перезагрузить сервер, кликхаус не запустится примено никогда (Loading parts...). Буферные таблицы не помогают, хотя сильно с ними не экспериментировал. Такое ощущение, что нужно разрешить кликхаусу не мёржить parts как можно дольше - типа делать это только раз в час или около того. Решение, которое сейчас приодит в голову - сделать две таблицы, одну с партицированием только по времени (типа каждый час, без группы), а другую - по дате и группе. Ну, и рукаи брать всё, что из предыдущего часа и раньше, INSERT ... SELECT * FROM partitioned_by_time ORDER BY time, mod_group и предыдущие партиции из такой псевдо-буферной таблицы удалять. Но выглядит как страшный костыль и могу представить слишком много мест, где это может поломаться. Может есть какие-то ещё параметры, которые стоит попробовать подкрутить под этот юзкейс?

Привет! Экспериментирую тут с кастомным PARTITION BY ключом в обычном MergeTree. Хочу партишнинг по (дата, группа), где группа - это 1000 числовых значений (можно считать, что это client_id mod 1000). Задача в том, чтобы эффективно использовать 1ТБ диск, удаляя слишком большие группы чаще, чем маленькие. То есть если в группе записей на 1МБ, она может жить и год (365 партиций для неё), а если 300ГБ, то, скажем, один или два дня только. Данные поступают из 10-15 источников, почти отсортироваными по группам и времени, но в кажом источнике есть почти все группы. Каждый источник вствляет по 50-100МБ за раз раз в 20-30 секунд. Раз в несколько минут бывают маленькие вставки в несколько мегабайт или даже меньше. Проблема на дефолтном конфиге - Too many parts. Если увеличить max_replicated_merges_in_queue, то всё какое-то время работает, но старые неактивные партиции не успевают удалятся и на файловой системе через какое-то время кончаются inodes. Если взять ФС без inodes, всё равно всё будет плохо ибо новые parts всё равно появляются быстрее, чем удаляются старые (пробовал также разные разные значения *_lifteme). А уж если перезагрузить сервер, кликхаус не запустится примено никогда (Loading parts...). Буферные таблицы не помогают, хотя сильно с ними не экспериментировал. Такое ощущение, что нужно разрешить кликхаусу не мёржить parts как можно дольше - типа делать это только раз в час или около того. Решение, которое сейчас приодит в голову - сделать две таблицы, одну с партицированием только по времени (типа каждый час, без группы), а другую - по дате и группе. Ну, и рукаи брать всё, что из предыдущего часа и раньше, INSERT ... SELECT * FROM partitioned_by_time ORDER BY time, mod_group и предыдущие партиции из такой псевдо-буферной таблицы удалять. Но выглядит как страшный костыль и могу представить слишком много мест, где это может поломаться. Может есть какие-то ещё параметры, которые стоит попробовать подкрутить под этот юзкейс?

А опишите ваши вставки не в Мб, а в кол-ве строк

Если заранее известно большая группа или маленькая то можно из 1000 номеров групп сделать несколько групп с разными retention policy.

365000 партиций - это много, нужно чтоб было меньше. При большом количестве партиций (или таблиц) у КХ "едет крыша".

А опишите ваши вставки не в Мб, а в кол-ве строк

может очень варьироваться, сам измеряю мегабайтами. Там может быть и 500 и несколько тысяч записей), но не более того.

365000 партиций - это много, нужно чтоб было меньше. При большом количестве партиций (или таблиц) у КХ "едет крыша".

Ожидаемое количество партиций - 20_000. Большинство из них никогда не будут задействованы ни в одном запросе.

может очень варьироваться, сам измеряю мегабайтами. Там может быть и 500 и несколько тысяч записей), но не более того.

Это важно. Если вы интенсивно вставляете пачками меньше 1к записей и чаще чем раз в секунду - у вас даже с настроенными партиционированием будут проблема с КХ

Заранее неизместно. большая группа или маленькая, но если сегодня она большая, то завтра тоже, скорее всего, будет большой и наоборот.

Ну и если допустим насколько различный retention policy - то первый вопрос который приходит в голову то почему данные с насколько различными retention policy лежат в одной таблице.

Другими словами если для большой группы допустима быстрая чистка, то почему "быстрая чистка" не допустима для маленькой группы.

Ну и если допустим насколько различный retention policy - то первый вопрос который приходит в голову то почему данные с насколько различными retention policy лежат в одной таблице.

+1. В КХ есть такой тип движка Merge (не путать с MergeTree). Разбейте ваши вставки на разные таблицы (с разным времени жизни, с разными ключами партиционирования). А если нужно обращаться ко всему массиву данных - делайте запрос к таблице типа Merge (подробности в доке)

Это важно. Если вы интенсивно вставляете пачками меньше 1к записей и чаще чем раз в секунду - у вас даже с настроенными партиционированием будут проблема с КХ

В среднем, всё же реже чем раз в секунду и больше 1к записей.

Ожидаемое количество партиций - 20_000. Большинство из них никогда не будут задействованы ни в одном запросе.

Все равно много. Сотни / тысячи - ок. Десятки/сотни тысяч и больше - плохо.

Я не знаю заранее большая группа или маленькая. Иногда это всё-таки может меняться, хоть и редко.

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

Попробуйте так - отдельная таблица для свежих данных в которой хранятся несколько последних дней. И MV который перекладывает данные из этой таблицы в таблицу "долгого хранения".

Ну и в ту таблицу "долгого хранения" перекладывайте только то что было не большим.

MV разве не на каждую вставку будет записывать данные в таблицу "долгого хранения"? Не получится ли та е проблема - вид с боку?

Типа в селекте для MV указать GROUP BY mod_group WHERE count() < .. ?

так вообще можно?

MV разве не на каждую вставку будет записывать данные в таблицу "долгого хранения"? Не получится ли та е проблема - вид с боку?

С MV я имел в виду - если набор тех маленьких клиентов фиксированный то можно просто только их выбирать в WHERE. А в этой таблице долгого хранения просто партиционирование по месяцам.

Типа в селекте для MV указать GROUP BY mod_group WHERE count() < .. ?

GROUP BY обработает данные вставляемой в исходную таблицу пачки (не всю таблицу)

Ну или просто INSERT ... SELECT раз в день запускать

Типа в селекте для MV указать GROUP BY mod_group WHERE count() < .. ?

Можно (правда должен быть having а не WHERE) ну и работать будет только в рамках "новоприехавшей" пачки данных.

ну вот я в первом сообщении про INSERT .. SELECT написал, да. Набор "маленьких" редко, но всё-таки меняется.

Ну при такой постановке задачи несколько таблиц с разным партиционированием кажется наиболее логичным. И при этом я бы не добавлял номер группы в ключ партиционированная.

Но тогда я не смогу менять ретеншины же? И по сути это надо для каждой группы отдельную таблицу.

то есть реализовывать партишенинг руками практически

Т.е. data_daily из которой данные для не очень больших клиентов через неделю перекладываются в weekly, а оттуда для ещё меньших в monthly.

Данные для больших клиентов будут жить только в daily. Для клиентов поменьше в daily и weekly. Для самых маленьких - в daily weekly и monthly.

Разумеется удобнее было бы делать не monthly а например 4 недельными интервалами.

Костыльно конечно

И момент перекладывания не атомарный.

Но и постановка задачи тоже чудновата.

Поверх этих трех таблиц можно сделать Distributed или Merge.

Ну или тупо UNION ALL.

Если хотите менее костыльно - сделайте наприемер просто недельные партиции и чистите их с помощью ALTER ... DELETE.

ALTER ... DELETE может быть интересно и типа даже дневные партиции, но насколько оно шустро?

Вполне себе шустро.

Кстати что-то там в цифрах ваших не клеится. 100 Мб на инсерт х 3 инсерта в минуту х 15 источников х 60 минут в часе х 24 часа = 6.5 терабайт в день. А вы писали о 1 Тб на год...

Это пиковые. В день меньше полтерабайта всего. Но некоторые группы за год могут всего 2гб набрать. Плюс, это всё без сжатия, а должно хорошо поджмматься.

Точно нельзя ему как-то сказать "не надо мёржить, если прошло меньше xx минут со вставки"?

Доброй ночи, еще есть вопрос, насколько я понимаю заполнить AggregatingMergeTree можно только с group by но когда я делаю CREATE MATERIALIZED VIEW ... ENGINE = AggregatingMergeTree(...) POPULATE AS SELECT ... GROUP BY вылетает сообщение о нехватке памяти

- если INSERT будет содержать намного меньше данных, то там подобных проблем с памятью быть не должно? - ну и как же сделать начальное заполнение MV ?

без POPULATE https://groups.google.com/forum/?utm_medium=email&utm_source=footer#!msg/clickhouse/SJ9arSTPsKk/3c_jh3NLCwAJ

без POPULATE https://groups.google.com/forum/?utm_medium=email&utm_source=footer#!msg/clickhouse/SJ9arSTPsKk/3c_jh3NLCwAJ

правильно я понимаю что по этой инструкции мне надо руками разбивать на блоки, чтоб влезало в 10 ГБ (мои ограничения) и загонять по одному все блоки

правильно я понимаю что по этой инструкции мне надо руками разбивать на блоки, чтоб влезало в 10 ГБ (мои ограничения) и загонять по одному все блоки

нет, не правильно, нет никаких ограничений.