Рефинк да

Роман батчер самописное что то?

да, собирает записи в один запрос и по достижению лимита записей или по таймауту отправляет запрос в кх

Кх по структуре оптимизирован под обработку хорошо структурированных данных с разумно маленькими полями

асболютно верно, писать json не самая лучшая идея

К сожалению, такая специфика приложения

а можно уплотнить json в messagepack

и сжать его эдак раза в полтора, это конечно не решит проблемы с 20кб

Сериализовать объект как угодно можно

Но это не решает проблемы реляционного преобразования

А какого вида будут запросы? Раз группировок не предвидится.

Просто выбрать эти самые сообщения по заданным критериям

Привет, есть ли возможность подключить SPSS Modeller к ClickHouse?

Проблема с жирными столбцами в том, что разреженный индекс с ними плохо справляется. Если взять дефолтное значение гранулярности 8192, то будет вообще плохо - в худшем случае для чтения одного сообщения придётся зачитать 20кб * 8192 = примерно 160МБ данных (с диска, конечно, меньше, но ведь их ещё и разжимать...) Можно взять гранулярность поменьше, но тогда вырастет размер индекса, а он резидентный в памяти.

Угу этого я и опасался

Есть какието эмпирики оценки объема индекса к гранулярности ?

Чтобы прикинуть, можно посчитать сумму размеров полей индекса * количество строк / гранулярность и округлить вверх до ближайшей степени двойки

Ну или заглянуть в system.parts

столбец primary_key_bytes_in_memory_allocated

Привет, коллеги! А как из count() возвращать 0, если нет совпадений?

(https://stackoverflow.com/questions/44307934/how-to-make-clickhouse-count-function-return-0-in-case-of-zero-matches)

А никто не сталкивался с проблемой " DB::Exception: Cannot read all data in NativeBlockInputStream."? При записи в MaterializedVieew

Привет, коллеги! А как из count() возвращать 0, если нет совпадений?

про это есть тикет

?

Что-то не нашёл на Github, а ссылочкой не поделитесь?

Коллеги, а есть поддержка Liquibase для Clickhouse ?

Что-то не нашёл на Github, а ссылочкой не поделитесь?

что-то тоже не нашел. хотя задача уже успела стать классической.

Приятно, что мы не одни.

Проблема с жирными столбцами в том, что разреженный индекс с ними плохо справляется. Если взять дефолтное значение гранулярности 8192, то будет вообще плохо - в худшем случае для чтения одного сообщения придётся зачитать 20кб * 8192 = примерно 160МБ данных (с диска, конечно, меньше, но ведь их ещё и разжимать...) Можно взять гранулярность поменьше, но тогда вырастет размер индекса, а он резидентный в памяти.

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

Всей таблицы

Спасибо. А что произойдет, если размер индекса превысит размер памяти? Сервер упадет?

столбец primary_key_bytes_in_memory_allocated показывает размер индекса партиции или всей таблицы?

Вопрос: а хранимые функции будут или лучше про это забыть?

столбец primary_key_bytes_in_memory_allocated показывает размер индекса партиции или всей таблицы?

Размер индекса куска (парта) (небольшая терминологическая путаница - партиция это всё-таки один месяц) - всё-таки таблица system.parts :) Для всей таблицы надо просуммировать.

Интересно, надо ли учитывать неактивные куски

Привет! скажите, а кто-нибудь пытался запускать клик-хаус в кластерном режиме, используя вместо zookeeper что-то иное? например, etcd с оберткой с эмуляцией zookeeper api? как быть, если ничего на яве использовать нельзя в проекте?

Техдир обещает распять?

А то и раз шесть ;)

Привет :) А ни у кого не возникало проблем с groupArrayUniq(...) от Tuple

хуже)

Всем привет! На сколько подходит кликхаус для систем с большим колличеством запросов на чтение?

Привет :) А ни у кого не возникало проблем с groupArrayUniq(...) от Tuple

а что с ним?

Пытаюсь сделать groupArrayUniq от нескольких колонок объединённых в tuple. Получаю DB::Exception: Cannot read all data in NativeBlockInputStream при чтении

Привет! скажите, а кто-нибудь пытался запускать клик-хаус в кластерном режиме, используя вместо zookeeper что-то иное? например, etcd с оберткой с эмуляцией zookeeper api? как быть, если ничего на яве использовать нельзя в проекте?

Тут кто то пробовал, не работает ничего кроме зукипера

Привет! скажите, а кто-нибудь пытался запускать клик-хаус в кластерном режиме, используя вместо zookeeper что-то иное? например, etcd с оберткой с эмуляцией zookeeper api? как быть, если ничего на яве использовать нельзя в проекте?

Кх использует функционал ЗК которого нет в zetcd

Сам groupArrayUniq в MaterializedView вставляется

Тут кто то пробовал, не работает ничего кроме зукипера

спасибо, Владимир

спасибо, Владимир

https://github.com/coreos/zetcd/issues/38

Но вообще Джава в проде это не так больно

А где можно почитать: что такое зукипер, чем он отличается от zetcd?

А где можно почитать: что такое зукипер, чем он отличается от zetcd?

https://zookeeper.apache.org

Zetcd реализация протоеола зукипера поверх etcd

Кстати, пару дней назад появился пулреквест в zetcd, который вроде бы добавляет поддержку multiop (то, чего не хватало)

Желающие могут протестировать, вдруг не упадёт :)

интересно, гляну. спасибо

Тут дело в том что по производительности zetcd будет хуже

Правда вопрос в том упретесь ли вы в нее

Тут дело в том что по производительности zetcd будет хуже

А есть бенчмарки?

А есть бенчмарки?

Я где то находил, zetcd был в 2-3 раза медленнее

После этого я для себя решил что в нем как то смысла пока нет

Добрый вечер. Передаю через GET запрос запрос, содержащий regexp. Символы \\ URL-энкодятся и регэксп не срабатывает. Не подскажите, что делать?

Для загрузки данных из умирающей influx в КХ надо из csv файла со строками типа: timestamp,tag, A=<значение> ... timestamp, tag, B=<значение> ... положить данные в таблицу КХ со структурой: (timestamp, tag, A, B) Засада в том, что строки с A и B для совпадающих значений timestamp,tag разбросаны случайно по csv файлу. gzip-нутых csv данных порядка 50-100 гигов. Как лучше это сделать? Пока надумал такое : 1) grep A < file | clickhouse-local -S ... -if CSV -q 'SELECT ... format CSV ' | clickhouse-client —query="INSERT INTO DB.tableA FORMAT CSV" 2) grep B < file | clickhouse-local -S ... -if CSV -q 'SELECT ... format CSV' | clickhouse-client —query="INSERT INTO DB.tableB FORMAT CSV" 3) INSERT INTO FinalTable FROM SELECT timestamp, tag, A, B FROM tableA INNER JOIN tableB USING timestamp, tag 4) DROP table tableA; DROP table tableB Или есть более оптимальный КХ-way способ?

Для загрузки данных из умирающей influx в КХ надо из csv файла со строками типа: timestamp,tag, A=<значение> ... timestamp, tag, B=<значение> ... положить данные в таблицу КХ со структурой: (timestamp, tag, A, B) Засада в том, что строки с A и B для совпадающих значений timestamp,tag разбросаны случайно по csv файлу. gzip-нутых csv данных порядка 50-100 гигов. Как лучше это сделать? Пока надумал такое : 1) grep A < file | clickhouse-local -S ... -if CSV -q 'SELECT ... format CSV ' | clickhouse-client —query="INSERT INTO DB.tableA FORMAT CSV" 2) grep B < file | clickhouse-local -S ... -if CSV -q 'SELECT ... format CSV' | clickhouse-client —query="INSERT INTO DB.tableB FORMAT CSV" 3) INSERT INTO FinalTable FROM SELECT timestamp, tag, A, B FROM tableA INNER JOIN tableB USING timestamp, tag 4) DROP table tableA; DROP table tableB Или есть более оптимальный КХ-way способ?

По аналогии https://stackoverflow.com/questions/31820281/linux-group-by-date-column-and-show-count

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

т.е. процессе clickhouse-server пишет/изменяет файлы, а вы в это время копируете их в другое место через обычные механизмы вроде "cp"?

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

конечно схема mergetree - это не изменение "in place", но я бы все равно не надеялся на удачное восстановление из таких бэкапов

а как насчет ФС со snapshot?

Для загрузки данных из умирающей influx в КХ надо из csv файла со строками типа: timestamp,tag, A=<значение> ... timestamp, tag, B=<значение> ... положить данные в таблицу КХ со структурой: (timestamp, tag, A, B) Засада в том, что строки с A и B для совпадающих значений timestamp,tag разбросаны случайно по csv файлу. gzip-нутых csv данных порядка 50-100 гигов. Как лучше это сделать? Пока надумал такое : 1) grep A < file | clickhouse-local -S ... -if CSV -q 'SELECT ... format CSV ' | clickhouse-client —query="INSERT INTO DB.tableA FORMAT CSV" 2) grep B < file | clickhouse-local -S ... -if CSV -q 'SELECT ... format CSV' | clickhouse-client —query="INSERT INTO DB.tableB FORMAT CSV" 3) INSERT INTO FinalTable FROM SELECT timestamp, tag, A, B FROM tableA INNER JOIN tableB USING timestamp, tag 4) DROP table tableA; DROP table tableB Или есть более оптимальный КХ-way способ?

Какого типа a и b и есть ли какие-нибудь характеристики по их физической близости друг к другу на диске?

Я сегодня первый раз столкнулся с тем, что кликхаус прекратил запрос со словами: 9g is too much for query, stop it

max_memory_usage или как-то так

Я скорее про то, что считать нормальным

Пока что у меня под это рабоает только один сервер с 32 гб памяти, очевидно надо просить хостера расширять

Какие разумные цифры тут ставить? 16 гигов на запрос? Или лучше попробовать пооптимизировать запрос?

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

я вроде где-то в этом канальчике видел советы делать просто select * fromat RowBinary в файл или что-то в таком духе

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

Консистентность бекапов проверяли? Далеко не факт что такой бекап нормально будет ресториться. Как по мне, лучше выделить сервак, на него сделать реплики и уже на них FREEZE PARTITION. Подробнее тут: https://clickhouse.yandex/docs/ru/query_language/queries.html#id5

т.е. процессе clickhouse-server пишет/изменяет файлы, а вы в это время копируете их в другое место через обычные механизмы вроде "cp"?

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

я вроде где-то в этом канальчике видел советы делать просто select * fromat RowBinary в файл или что-то в таком духе

привет. этот способ хорошо, но что будет если я буду селектит в файл 1 млрд данных это будет по времени наверное намного дольше чем копирование?

Какого типа a и b и есть ли какие-нибудь характеристики по их физической близости друг к другу на диске?

a и b - UInt64 (счётчики пакетов и байтов). Про близость строк с a и b и одинаковым набором остальных полей (тегов и timestamp) ничего определённого сказать нельзя. Насколько я понимаю это просто тупой дамп из key-value storage в потрохах InfluxDB. Маловероятно, что там будет какая-то гарантированная упорядоченность. Теоретически можно задачку решить чисто линуксовыми тулзами - слиянием через paste двух потоков (grep A|sort ...) и (grep B | sort ...), но я не пробовал и не знаю, как поведёт себя sort на многогигабайтном текстовом файле. Вот пример куска исходного файла: device_srcAS_nexthop_interfaces,device=10.146.0.1,iface_in=0,iface_out=22,nexthop=149.6.168.201,src_as=0 bytes=960000i 1488480600000000000 device_srcAS_nexthop_interfaces,device=10.146.0.1,iface_in=0,iface_out=22,nexthop=149.6.168.201,src_as=0 bytes=960000i 1488481200000000000 device_srcAS_nexthop_interfaces,device=10.146.0.1,iface_in=0,iface_out=22,nexthop=149.6.168.201,src_as=0 packets=10000i 1488479100000000000 device_srcAS_nexthop_interfaces,device=10.146.0.1,iface_in=0,iface_out=22,nexthop=149.6.168.201,src_as=0 packets=20000i 1488479400000000000 device_srcAS_nexthop_interfaces,device=10.146.0.1,iface_in=0,iface_out=22,nexthop=149.6.168.201,src_as=0 packets=10000i 1488480600000000000

Консистентность бекапов проверяли? Далеко не факт что такой бекап нормально будет ресториться. Как по мне, лучше выделить сервак, на него сделать реплики и уже на них FREEZE PARTITION. Подробнее тут: https://clickhouse.yandex/docs/ru/query_language/queries.html#id5

реплики не планируем пока использовать. FREEZE PARTITION создает ведь в папку detached партишины? может оттуда их копировать?

a и b - UInt64 (счётчики пакетов и байтов). Про близость строк с a и b и одинаковым набором остальных полей (тегов и timestamp) ничего определённого сказать нельзя. Насколько я понимаю это просто тупой дамп из key-value storage в потрохах InfluxDB. Маловероятно, что там будет какая-то гарантированная упорядоченность. Теоретически можно задачку решить чисто линуксовыми тулзами - слиянием через paste двух потоков (grep A|sort ...) и (grep B | sort ...), но я не пробовал и не знаю, как поведёт себя sort на многогигабайтном текстовом файле. Вот пример куска исходного файла: device_srcAS_nexthop_interfaces,device=10.146.0.1,iface_in=0,iface_out=22,nexthop=149.6.168.201,src_as=0 bytes=960000i 1488480600000000000 device_srcAS_nexthop_interfaces,device=10.146.0.1,iface_in=0,iface_out=22,nexthop=149.6.168.201,src_as=0 bytes=960000i 1488481200000000000 device_srcAS_nexthop_interfaces,device=10.146.0.1,iface_in=0,iface_out=22,nexthop=149.6.168.201,src_as=0 packets=10000i 1488479100000000000 device_srcAS_nexthop_interfaces,device=10.146.0.1,iface_in=0,iface_out=22,nexthop=149.6.168.201,src_as=0 packets=20000i 1488479400000000000 device_srcAS_nexthop_interfaces,device=10.146.0.1,iface_in=0,iface_out=22,nexthop=149.6.168.201,src_as=0 packets=10000i 1488480600000000000

Я думал где-то с месяц назад написать конвертер из InfluxDB в CH. Имя метрики - таблица. Но пока застопорилось на том что кажется надо свою библиотечку для КХ писать.

реплики не планируем пока использовать. FREEZE PARTITION создает ведь в папку detached партишины? может оттуда их копировать?

О том и речь. Отдельный сервер с репликами чтобы не аффектить на продуктивный кластер.

a и b - UInt64 (счётчики пакетов и байтов). Про близость строк с a и b и одинаковым набором остальных полей (тегов и timestamp) ничего определённого сказать нельзя. Насколько я понимаю это просто тупой дамп из key-value storage в потрохах InfluxDB. Маловероятно, что там будет какая-то гарантированная упорядоченность. Теоретически можно задачку решить чисто линуксовыми тулзами - слиянием через paste двух потоков (grep A|sort ...) и (grep B | sort ...), но я не пробовал и не знаю, как поведёт себя sort на многогигабайтном текстовом файле. Вот пример куска исходного файла: device_srcAS_nexthop_interfaces,device=10.146.0.1,iface_in=0,iface_out=22,nexthop=149.6.168.201,src_as=0 bytes=960000i 1488480600000000000 device_srcAS_nexthop_interfaces,device=10.146.0.1,iface_in=0,iface_out=22,nexthop=149.6.168.201,src_as=0 bytes=960000i 1488481200000000000 device_srcAS_nexthop_interfaces,device=10.146.0.1,iface_in=0,iface_out=22,nexthop=149.6.168.201,src_as=0 packets=10000i 1488479100000000000 device_srcAS_nexthop_interfaces,device=10.146.0.1,iface_in=0,iface_out=22,nexthop=149.6.168.201,src_as=0 packets=20000i 1488479400000000000 device_srcAS_nexthop_interfaces,device=10.146.0.1,iface_in=0,iface_out=22,nexthop=149.6.168.201,src_as=0 packets=10000i 1488480600000000000

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

другой вариант могу предложить: сделать собственный сторадж в котором строки вида: UTC:Int32, A:Int64, B:Int64 и пройтись по нему, перезаписав inplace

это вот два варианта, которые могу посоветовать

Я думал где-то с месяц назад написать конвертер из InfluxDB в CH. Имя метрики - таблица. Но пока застопорилось на том что кажется надо свою библиотечку для КХ писать.

Для КХ вроде достаточно связки "clickhouse-local | clickhouse-client". У меня засада в кривости Influx и его cmdline клиентов - вроде бы простой select * from somemeasurement where time > t1 and time < t2 легко выжирает всю память (50 свободных гигов не хватает). Пришлось influx_inspect export использовать, а он, как оказалось, поля (fields) в отдельные строки дампа выводит ? Что-то специально писать не хочется - задача миграции разовая.

Я с вопросом про размер query. Это вообще разумно поднимать max query memory до 20 или 30 гигабайт? Т.е. я задрать могу, а насколько это оправдано? Может я просто не так пользуюсь и это уже неправильное использование инструмента?

@maxlapshin возможно вы не совсем правильно используете кликхаус? Если был инфлюкс, где нормальной аграгации нету - а вы перешли на кликхаус, который заточен под агрегацию (т.е. не на стороне софта, а прямыми sql вытягивать данные) вот здесь уже нужно или лимитировать, или добавлять максимально доступное ОЗУ исходя из того, сколько может быть одновременных запросов т.к. при переполнении - падает весь демон, а не выдает ошибку для запроса

Не знаю как у кликхауса, но к примеру в касандре есть потоковое чтение что в вашем случае очень может помочь, т.е. оперативная память не будет сильно забиваться: прочитал->отдал, но с касандры только сырые данные можно будет получить + очень критично к параметрам WHERE по порядку выборки, или использовать ALLOW FILTERING и терять в скорости

Всем добрый день! Подскажите, можно ли корректно удалить партицию из materialized view вида MergeTree?

Всем добрый день! Подскажите, можно ли корректно удалить партицию из materialized view вида MergeTree?

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

Говорит, Method dropPartition is not supported by storage MaterializedView.

Если указать .inner, ругается на синтаксис

@maxlapshin возможно вы не совсем правильно используете кликхаус? Если был инфлюкс, где нормальной аграгации нету - а вы перешли на кликхаус, который заточен под агрегацию (т.е. не на стороне софта, а прямыми sql вытягивать данные) вот здесь уже нужно или лимитировать, или добавлять максимально доступное ОЗУ исходя из того, сколько может быть одновременных запросов т.к. при переполнении - падает весь демон, а не выдает ошибку для запроса

не уверен, что вас понял, но у меня именно агрегация в SQL.