Как получить версию CH через запрос? ввожу version(), show version() но все выдает ошибку.

Так ведь когда конектишься к базе пишется версия

А у меня снова вопрос по компрессии. LZ4 по дефолту включалась всегда, или только начиная с какой-то версии? Возможен ли вариант, что база была создана ещё до введения сжатия, и сейчас существует в несжатом виде? Как таковой information_schema, похоже, не существует, и какую-то информацию о базах и столбцах черпать неоткуда. Или я ошибаюсь?

сжатие было вроде всего, был выбор чем именно жать , легко посмотреть на диске открыв файл в просмотрщике

SELECT version()

спасибо

сжатие было вроде всего, был выбор чем именно жать , легко посмотреть на диске открыв файл в просмотрщике

Благодарю!

сжатие было вроде всего, был выбор чем именно жать , легко посмотреть на диске открыв файл в просмотрщике

Этим запросом можно посмотреть что и на сколько сжато: SELECT table, name, formatReadableSize(sum(data_compressed_bytes)) AS compressed, formatReadableSize(sum(data_uncompressed_bytes)) AS uncompressed, sum(data_uncompressed_bytes) / sum(data_compressed_bytes) AS ratio FROM system.columns WHERE database != 'system' GROUP BY table, name ORDER BY table, ratio DESC;

Привет. Есть ли в CH способ вынуть время прошедшее с предыдущего события? Т.е. есть таблица вида date | devId | eventDateTime 2018-08-01 | 100 | 2018-08-01 12:00:00 2018-08-01 | 100 | 2018-08-01 12:10:00 2018-08-01 | 100 | 2018-08-01 12:15:00 Нужен запрос, который вернёт devId | eventDateTime | fromPrev 100 | 2018-08-01 12:00:00 | 100 | 2018-08-01 12:10:00 | 600 100 | 2018-08-01 12:15:00 | 300

Привет. Есть ли в CH способ вынуть время прошедшее с предыдущего события? Т.е. есть таблица вида date | devId | eventDateTime 2018-08-01 | 100 | 2018-08-01 12:00:00 2018-08-01 | 100 | 2018-08-01 12:10:00 2018-08-01 | 100 | 2018-08-01 12:15:00 Нужен запрос, который вернёт devId | eventDateTime | fromPrev 100 | 2018-08-01 12:00:00 | 100 | 2018-08-01 12:10:00 | 600 100 | 2018-08-01 12:15:00 | 300

runningDifferenceStartingWithFirstValue,runningAccumulate,runningDifference ?

runningDifferenceStartingWithFirstValue,runningAccumulate,runningDifference ?

Что-то я в документации не могу найти. Есть где об этом почитать или примеры?

Можно поискать здесь в чате (есть примеры), или в исходниках на гитхабе, в тестах всегда есть примеры каждой функции.

Можно поискать здесь в чате (есть примеры), или в исходниках на гитхабе, в тестах всегда есть примеры каждой функции.

Ok, спасибо

Что-то я в документации не могу найти. Есть где об этом почитать или примеры?

https://clickhouse.yandex/docs/ru/query_language/functions/other_functions/#runningdifferencex

Коллеги, можно ли в кликхаусе сделать join таблиц без using? то есть просто берём две любые таблицы и надо смёржить всё со всем

Коллеги, можно ли в кликхаусе сделать join таблиц без using? то есть просто берём две любые таблицы и надо смёржить всё со всем

можно все столбцы в using перечислить

Коллеги, можно ли в кликхаусе сделать join таблиц без using? то есть просто берём две любые таблицы и надо смёржить всё со всем

декартово произведение?

декартово произведение?

ага

можно все столбцы в using перечислить

сейчас попробую

сейчас попробую

это будет только не декартово

сейчас попробую

Можно добавить в каждой таблице по столбцу, содержащему константу и по нему джойнить

Можно добавить в каждой таблице по столбцу, содержащему константу и по нему джойнить

не представляю пока как это сделать даже в моём случае

то есть по сути будет две таблицы первая с временными точками сгенерёнными через numbers и нулями

вторая будет с нужными группировками string столбцов

надо смёржить эти две таблицы так чтобы все группы string имели по всем временным точкам

как-то так

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

select * from (select *, 1 as c from t1) all inner join (select *, 1 as c from t2) using c

select * from (select *, 1 as c from t1) all inner join (select *, 1 as c from t2) using c

хм, ну кстати может это и прокатит, сейчас попробую

select * from (select *, 1 as c from t1) all inner join (select *, 1 as c from t2) using c

работает) спасибо большое

выглядит как костыль конечно, но элегантный))

а cross join не работает разве?

я его даже в доке не увидел, UPD: cross join тоже работает кстати, но по нему доки нету

https://github.com/yandex/ClickHouse/issues/2857

сжатие было вроде всего, был выбор чем именно жать , легко посмотреть на диске открыв файл в просмотрщике

Согласно спецификации, первые четыре байта LZ4 - 0x184D2204. Прошёлся по .bin-файлам хексдампом, не нашёл. Походу Кликхаусом пишется raw stream.

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

Этим запросом можно посмотреть что и на сколько сжато: SELECT table, name, formatReadableSize(sum(data_compressed_bytes)) AS compressed, formatReadableSize(sum(data_uncompressed_bytes)) AS uncompressed, sum(data_uncompressed_bytes) / sum(data_compressed_bytes) AS ratio FROM system.columns WHERE database != 'system' GROUP BY table, name ORDER BY table, ratio DESC;

Сработало. Благодарю.

Ещё вопрос: если задать zstd вместо lz4, данные пережмутся в фоновом режиме, или это требуется вызывать принудительно? Хотя побаиваюсь вообще что-то делать с датасетом на полтора тб.

Согласно спецификации, первые четыре байта LZ4 - 0x184D2204. Прошёлся по .bin-файлам хексдампом, не нашёл. Походу Кликхаусом пишется raw stream.

откройте в текстовом редакторе и увидите

сжатые там данные или не сжатые ,а у ж чем пожаты это второй вопрос

runningDifferenceStartingWithFirstValue,runningAccumulate,runningDifference ?

Я так понимаю эти функции нельзя использовать при изменяющихся devId. Если в таблице несколько devId: date | devId | eventDateTime 2018-08-01 | 100 | 2018-08-01 12:00:00 2018-08-01 | 100 | 2018-08-01 12:10:00 2018-08-01 | 100 | 2018-08-01 12:15:00 2018-08-01 | 200 | 2018-08-01 12:00:00 2018-08-01 | 200 | 2018-08-01 12:05:00 то надо вернуть devId | eventDateTime | fromPrev 100 | 2018-08-01 12:00:00 | 100 | 2018-08-01 12:10:00 | 600 100 | 2018-08-01 12:15:00 | 300 200 | 2018-08-01 12:00:00 | 200 | 2018-08-01 12:05:00 | 300

Привет. А можно как-нибудь изменить формат логов Кликхауса? Убрать\добавить колонки, изменить формат таймстемпа, всё в таком духе

Привет. А можно как-нибудь изменить формат логов Кликхауса? Убрать\добавить колонки, изменить формат таймстемпа, всё в таком духе

Если можете C++ то всё возможно ;)

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

Есть два варианта заполнения пустых дат / временных диапазонов. В обоих случаях требуется для начала создать полный диапазон полностью с помощью запроса типа SELECT today() + number FROM numbers(100). Ну и дальше первый вариант который приходит в голову - это сделать JOIN с настоящими данными. Но в кликхаус JOIN - не всегда наилучшая идея, поэтому я в таких случаях предпочитаю UNION ALL с дальнейшей группировкой результата по времени/дате.

Я так понимаю эти функции нельзя использовать при изменяющихся devId. Если в таблице несколько devId: date | devId | eventDateTime 2018-08-01 | 100 | 2018-08-01 12:00:00 2018-08-01 | 100 | 2018-08-01 12:10:00 2018-08-01 | 100 | 2018-08-01 12:15:00 2018-08-01 | 200 | 2018-08-01 12:00:00 2018-08-01 | 200 | 2018-08-01 12:05:00 то надо вернуть devId | eventDateTime | fromPrev 100 | 2018-08-01 12:00:00 | 100 | 2018-08-01 12:10:00 | 600 100 | 2018-08-01 12:15:00 | 300 200 | 2018-08-01 12:00:00 | 200 | 2018-08-01 12:05:00 | 300

Да, тут наверное придется что-то напридумывать, в постобработке результатов, например. Неверной ведь получается только первая строчка после изменения devId, которая должна стать = 0.

Ну т.е. что-то типа SELECT date, sum(column1), sum(column2) FROM ( SELECT date, column1, column2 FROM realtable UNION ALL SELECT today() + number, 0,0 FROM numbers(100) ) GROUP BY date

Да, тут наверное придется что-то напридумывать, в постобработке результатов, например. Неверной ведь получается только первая строчка после изменения devId, которая должна стать = 0.

Я кажется придумал костыль вида if(runningDifference(devId)==0, runningDifference(eventDateTime), 0).

Есть два варианта заполнения пустых дат / временных диапазонов. В обоих случаях требуется для начала создать полный диапазон полностью с помощью запроса типа SELECT today() + number FROM numbers(100). Ну и дальше первый вариант который приходит в голову - это сделать JOIN с настоящими данными. Но в кликхаус JOIN - не всегда наилучшая идея, поэтому я в таких случаях предпочитаю UNION ALL с дальнейшей группировкой результата по времени/дате.

я тоже заюзал union all, но проблема в том что у меня ещё 3 поля типа string по которым происходит группировка из-за чего просто union all недостаточно мне пришлось сначала найти все эти поля и сделать cross join с numbers и потом сунуть в union all

то есть этот вариант работает только если group by date и никаких других группировок нет

Даже тогда JOIN не обязателен, вместо numbers можно использовать range + arrayJoin. SELECT ... FROM ( SELECT id1, id2, date, ... FROM table UNION ALL select id1, id2, arrayJoin( arrayMap( x -> today() + x, range(10) ) ) as date2 from table WHERE date=today() GROUP BY id1, id2 ) GROUP BY id1, id2, date

Ещё вопрос: если задать zstd вместо lz4, данные пережмутся в фоновом режиме, или это требуется вызывать принудительно? Хотя побаиваюсь вообще что-то делать с датасетом на полтора тб.

Насколько мне известно: указание конфигурации сжатия влияет на новосоздаваемые куски данных. При этом используемый алгоритм сжатия зашит в файлах данных, т.е. расжатие данных всегда происходит тем чем было сжато и конгфигурация на это никак не влияет. Новые куски данных пишутся при инсертах, или при фоновых слияниях. Т.е. если изменить LZ4 на ZSTD, то фоновые слияния будут пережимать данные в таком темпе который сочтут нужным, но скорее всего если данных много то ВСЕ данные будут пережаты примерно никогда. Можно использовать OPTIMIZE ... FINAL чтобы заставить пережать старые/большие части.

Привет. Есть ли в CH способ вынуть время прошедшее с предыдущего события? Т.е. есть таблица вида date | devId | eventDateTime 2018-08-01 | 100 | 2018-08-01 12:00:00 2018-08-01 | 100 | 2018-08-01 12:10:00 2018-08-01 | 100 | 2018-08-01 12:15:00 Нужен запрос, который вернёт devId | eventDateTime | fromPrev 100 | 2018-08-01 12:00:00 | 100 | 2018-08-01 12:10:00 | 600 100 | 2018-08-01 12:15:00 | 300

В случае необходимости считать разность в стролбце внутри групп можно использовать массивы и функции высшего порядка. См. тут https://stackoverflow.com/questions/51856397/clickhouse-running-diff-with-grouping/51873915#51873915

В случае необходимости считать разность в стролбце внутри групп можно использовать массивы и функции высшего порядка. См. тут https://stackoverflow.com/questions/51856397/clickhouse-running-diff-with-grouping/51873915#51873915

Спасибо

Подскажите как вставлять (insert) записи пачками? Словил ошибку "Too many parts (300). Merges are processing significantly slower than inserts". Только через файлы csv, tsv ?

не пачку инсертов, а инсерт пачки нужен

что-то типа INSERT .... VALUES (....), (...), (...) ...

Грубо говоря, один инсерт - одна новая часть на диске.

Подскажите как вставлять (insert) записи пачками? Словил ошибку "Too many parts (300). Merges are processing significantly slower than inserts". Только через файлы csv, tsv ?

INSERT INTO table VALUES (1, 'первая строка данных'), (2, 'вторая строка данных'), ..., (100, 'строка данных номер сто');

они никак не склеиваются? записей же миллионы

Можно в таблицу типа Buffer, тогда немного полегче

Но тоже не панацея

у нас так свалился сервер, создало 20 миллионов файлов

или например INSERT INTO table FORMAT JsonEachRow {"id":1,"str":"первая строка данных"} {"id":2,"str":"вторая строка данных"} {"id":100,"str":"строка данных номер 100"}

они никак не склеиваются? записей же миллионы

Одна из особенностей кликхаус - данные нужно вставлять пачками. Нельзя по одной строке. Т.е. или вы напишете один инсерт и потом в нем перечислите 100 тысяч строк для вставки - то это хорошо, а если сделаете 100 тысяч инсертов по одной строке - то это очень плохо.

Есть масса разных способов для преодоления этой проблемы. Один из них - это встроенный движок Buffer который лояльно относится к инсертам по одной строке и перебрасывает данные в финальную таблицу по мере накопления. Но он имеет свои ограничения, поэтому его обычно не рекомендуют широко использовать.

Ещё один - использование кафки.

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

Ещё один - использование кафки.

А как обрабатывать плохие данные в кафке? Я пытался так сделать и не нашел. Если кликхаусовский движок kafka не может распарсить данные, он просто бесконечно выдает ошибку.

А как обрабатывать плохие данные в кафке? Я пытался так сделать и не нашел. Если кликхаусовский движок kafka не может распарсить данные, он просто бесконечно выдает ошибку.

Знаю что ответ произвучит "так себе", но правильнее всего не пихать плохие данные в кафку.

Если необходима какая-то фильтрация перед КХ - то наверное можно попробовать читать из "плохого" стрима и писать в "хороший" чем-нибудь для потоковой обработки. А кликхаус настроить чтоб читал "хороший".

Если необходима какая-то фильтрация перед КХ - то наверное можно попробовать читать из "плохого" стрима и писать в "хороший" чем-нибудь для потоковой обработки. А кликхаус настроить чтоб читал "хороший".

+1. Мы используем раббит, но принцип тот же (для раббита нет коннектора, всё пишем нодом)

Насколько я помню, сжимаются блоки с данными Native формата, а всё остальное (всякие номера пакетов и т. п.) передаётся без сжатия. Сжатые данные устроены так. Они представляют собой набор сжатых фреймов. Каждый фрейм имеет следующий вид: чексумма (16 байт), идентификатор алгоритма сжатия (1 байт), размер сжатых данных (4 байта, little endian, размер не включает в себя чексумму, но включает в себя остальные 9 байт заголовка), размер несжатых данных (4 байта, little endian), затем сжатые данные. Идентификатор алгоритма: 0x82 - lz4, 0x90 - zstd. Чексумма - CityHash128 из CityHash версии 1.0.2, вычисленный от сжатых данных с учётом 9 байт заголовка. См. CompressedReadBufferBase, CompressedWriteBuffer, utils/compressor, TCPHandler.

Согласно спецификации, первые четыре байта LZ4 - 0x184D2204. Прошёлся по .bin-файлам хексдампом, не нашёл. Походу Кликхаусом пишется raw stream.

про заголовки сжатия в КХ ^

про заголовки сжатия в КХ ^

Низкий поклон за столь подробный разбор

Низкий поклон за столь подробный разбор

Ваши кудосы отправляются в копилку Алексею @milovidov_an :)

Приветствую. Подскажите пожалуйста, есть кластер из 4 нод (2 шарда по 2 реплики) хочу на всех 4 нодах открепить партицию в таблице за 1 запрос , нашел ноду с признаком в system.replicas is_leader=1 , есть 2 таблица: tablename = Distributed tablename_sharded = ReplicatedMergeTree делаю так: alter table database.tablename detach partition ’201807’ и получаю: DB::Exception: Method dropPartition is not supported by storage Distributed.

или же alter table detach не реплицируется?

ClickHouse client version 1.1.54383.

и правильно ли я понимаю что если я хочу открепить партицию на каждой ноде отдельно то нужно делать: alter table database.tablename_sharded detach partition ‘201807’ на каждой ноде?

alter table database.MergeTree-table on cluster xxx должно сработать

понял, спасибо большое

привет! пожалуйста, дайте совет - как сделать так, чтобы аггрегатная функция count возвращала 0, если записей нет?

привет! пожалуйста, дайте совет - как сделать так, чтобы аггрегатная функция count возвращала 0, если записей нет?

UNION ALL если не думать ?

можно ли использовать haproxy для балансировки между 2-мя репликами?

можно ли использовать haproxy для балансировки между 2-мя репликами?

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

@Mike_Er не подкините пример с боевого сервера?

Конфига хапрокси?

да

привет! пожалуйста, дайте совет - как сделать так, чтобы аггрегатная функция count возвращала 0, если записей нет?

Это вроде уже давно исправлено

То есть вам нужно просто обновить кликхаус ?

То есть вам нужно просто обновить кликхаус ?

т.е. сейчас он по-дефолту 0 выдает?

на версии 1.1.54385 уже выдает

на 1.1.54342 ещё нет

1.1.54343 у меня эта стоит

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

1.1.54343 у меня эта стоит

Обновите (осторожно, с бекапами или хотя бы FREEZE PARTITION) хотя бы до 1.1.54385 и станет выдавать ?