Господа, а очень плохо если в кликхаус лить 1 терабайт в день данных (с последующей агрегацией на лету) при условии что это узкая таблица? Знаю что она колоночная бд ...

(Плохо с точки зрения производительности я имею ввиду, и далее выдирать кейсами, тк данные изменчивы и нельзя сделать жесткую широкую структуру)

ну терабайт на одну ноду в день? аггрегация на лету что означает? AggregateMergeTree движок? через INSERT INTO SELECT ? а с исходной таблицей что делаете?

А как такое может быть, что свежесобранный clickhouse-client размером в 700Мб? оО

ну терабайт на одну ноду в день? аггрегация на лету что означает? AggregateMergeTree движок? через INSERT INTO SELECT ? а с исходной таблицей что делаете?

Хотелось бы хранит исходные данные а далее или хранить агрегаты (aggregation таблицей например) или же агрегировать group by при выводе

В идеале много кейсов и group by

ну если кластер сделаете в котором можно 365 терабайт в год поместить... в чем проблема то??? лейте! на одну ноду это коненчо не влезет но в целом если лить правильными чанками, если потом правильно аггрегировать, если понимать что нету UPDATE и DELETE то все вполне реально

какая хоть предметная область у данных?

какая хоть предметная область у данных?

Статистические замеры с оборудования RAN/транспорт

ну если кластер сделаете в котором можно 365 терабайт в год поместить... в чем проблема то??? лейте! на одну ноду это коненчо не влезет но в целом если лить правильными чанками, если потом правильно аггрегировать, если понимать что нету UPDATE и DELETE то все вполне реально

Кластер планируется 1-3 петабайт/год

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

а и еще вопрос - искал функцию SUBSTRING что бы можно было обрезать только последние N букв, по аналогии с HIVE/MYSQL тут этого же нет а?

А как такое может быть, что свежесобранный clickhouse-client размером в 700Мб? оО

Это фича. на самом деле там и сервер. если хочется размер поменьше но возможные проблемы с переносимостью бинарников - cmake -DUSE_STATIC_LIBRARIES=0

Тонкий момент - терабайт это до сжатия или после?

Тонкий момент - терабайт это до сжатия или после?

до

исходные 700-800гигов в день, после обработки и сжатия у меня утаптывались в 80-90М на диске. Заливал 10-минутными пачками до 15G за раз.

ок, понял, с насчет обрезки никто не знает? т.е у нас есть sample_name и я его хочу substring(sample_name,0,-1) что бы было sample_nam

substring / substringUTF8 - на выбор

там с минусом не работает

Code: 0, e.displayText() = DB::Exception: 2nd and 3rd arguments of function substring must be non-negative and must have UInt type., e.what() = DB::Exception

а что должен значить минус?

обрезать N симвулов с конца

length(..) - n не спасут?

по аналогии, простите, как в php $rest = substr("abcdef", 0, -1); // возвращает "abcde"

substring(sample_name,0,length(sample_name)-1)

length(..) - n не спасут?

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

substring(sample_name,0,length(sample_name)-1)

кстати тоже не работает

SELECT substring('asdasdasd', 1, CAST((length('asdasdasd') - 1) AS UInt32)) - работает

SELECT substring('asdasdasd', 1, CAST((length('asdasdasd') - 1) AS UInt32)) - работает

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

Это не баг, это фича

Сравнительно редкоиспользуемая операция vs минус одна операция ветвления

стали ловить ошибки "Code: 32. DB::Exception: Attempt to read after eof" и "Code: 210. DB::NetException: Connection reset by peer: while reading from socket (127.0.0.1:9000)", версия 1.1.54245. лечится только рестартом сервера. есть варианты решения?

Это фича. на самом деле там и сервер. если хочется размер поменьше но возможные проблемы с переносимостью бинарников - cmake -DUSE_STATIC_LIBRARIES=0

Ок, спасибо.

а почему не примут датасорс? )

потому что нет способа "подключить" такой плагин. Графана либо будет сбилджена с ним, либо нет. И если все таки удастся добавить свою реализацию, то авторам графаны придется ее поддерживать. Т.е. когда они решат внести изменения в алертинг, что уже происходило, то им нужно будет внести изменения в ваш код. Но в будущем планируется есть возможность подключения backend плагинов - https://github.com/grafana/grafana/issues/6841

стали ловить ошибки "Code: 32. DB::Exception: Attempt to read after eof" и "Code: 210. DB::NetException: Connection reset by peer: while reading from socket (127.0.0.1:9000)", версия 1.1.54245. лечится только рестартом сервера. есть варианты решения?

А что в стек трейсе в логе (можно найти по фрагменту ###). В версии 54245 есть известная проблема - используется слишком много потоков для параллельного мержа состояний агрегации. Сейчас готовим релиз, в котором это исправлено. https://github.com/yandex/ClickHouse/commit/4866a37a2b77a92e222d74bec5495599cce585bc

Это не баг, это фича

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

Fwd, здесь тоже будет полезно.

Про устройство первичного ключа можно почитать здесь: https://medium.com/@f1yegor/clickhouse-primary-keys-2cf2a45d7324 Суть в том, что выборки по условию на диапазон полей первичного ключа работают эффективно, если это поле стоит в нём первым, или если все поля, которые указаны до него, имеют большое количество повторяющихся значений. Также стоит отметить, что перечисление большого количества полей в PK не помогает для GROUP BY. Из этого следует, что указывать много полей не имеет смысла. Для примера, в таблице событий Метрики первичный ключ - (CounterID, Date, intHash32(UserID)). Потому что в запросах как правило используется условие на равенство CounterID и на диапазон дат. А intHash32(UserID) нужен для сэмплирования - для равномерного-случайного распределения данных в рамках каждой пары CounterID, Date. Что же делать, если запросы действительно тяжёлые и нужно, чтобы они работали быстрее? Например скорость обработки данных порядка миллиардов строк в секунду на простых запросах - это максимум, который можно выжать из одного сервера. Варианты такие: 1. Всё-таки можно делать предагрегацию данных с помощью материализованных представлений. Но лучше делать их немного и только для частых запросов. Редкие пусть могут работать медленно. 2. Использовать сэмплирование, если это подходит для задачи. 3. Контролировать, чтобы тяжёлых запросов было немного - с помощью квот на использование API сервиса и тому подобного. 4. Использовать больше шардов, при условии, что запросы хорошо масштабируются. Запросы с распределёнными IN/JOIN или со слабой фильтрацией/агрегацией данных могут масштабироваться хуже чем линейно.

полезно, спасибо

Нашёл тут выше в чатике кусок конфига для включения отправки graphite метрик, в доке так понимаю не описано. Кто знает может рассказать что тут и зачем кроме host и port конечно ;) <yandex> <use_graphite>true</use_graphite> <graphite> <host>127.0.0.1</host> <use_fqdn>true</use_fqdn> <port>42000</port> <root_path>one_min</root_path> <timeout>0.1</timeout> </graphite> </yandex>

Хотелось бы задать префикс также для метрик

Нашёл тут выше в чатике кусок конфига для включения отправки graphite метрик, в доке так понимаю не описано. Кто знает может рассказать что тут и зачем кроме host и port конечно ;) <yandex> <use_graphite>true</use_graphite> <graphite> <host>127.0.0.1</host> <use_fqdn>true</use_fqdn> <port>42000</port> <root_path>one_min</root_path> <timeout>0.1</timeout> </graphite> </yandex>

host - куда слать метрики, port - тоже куда слать. root_path - префикс

А timeout в чем и Use_fqdn за что отвечает?

я могу ошибаться, но use_fqdn - в метриках писать fqdn хоста, а не которокое имя

use_graphite больше не используется

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

Путь будет иметь вид: root_path.hostname.ClickHouse. ... Где root_path - префикс на ваше усмотрение, hostname - FQDN, если use_fqdn = true или системное имя хоста, иначе. Таймаут в секундах. Впрочем, отправка метрик всегда делается асинхронно и ничего не тормозит.

Внутри hostname точки заменяются на подчёркивания.

use_graphite больше не используется

Так так ;) а как правильно теперь?

Можно поставить отправку с разными интервалами - например, поминутно и посекундно. Пример:

<graphite> <host>localhost</host> <port>42000</port> <timeout>0.1</timeout> <interval>60</interval> <root_path>one_min</root_path> <metrics>true</metrics> <events>true</events> <asynchronous_metrics>true</asynchronous_metrics> </graphite> <graphite> <host>localhost</host> <port>42000</port> <timeout>0.1</timeout> <interval>1</interval> <root_path>one_sec</root_path> <metrics>true</metrics> <events>true</events> <asynchronous_metrics>false</asynchronous_metrics> </graphite>

Правильно - всё что не знаете оставить по-умолчанию.

<graphite> <host>localhost</host> <port>42000</port> <timeout>0.1</timeout> <interval>60</interval> <root_path>one_min</root_path> <metrics>true</metrics> <events>true</events> <asynchronous_metrics>true</asynchronous_metrics> </graphite> <graphite> <host>localhost</host> <port>42000</port> <timeout>0.1</timeout> <interval>1</interval> <root_path>one_sec</root_path> <metrics>true</metrics> <events>true</events> <asynchronous_metrics>false</asynchronous_metrics> </graphite>

Во, спасибо!

само наличие <graphite> </graphite> теперь означает использование

Ну все, теперь замониторю ))

а вот есть идея

сделать что-то типа

"тежёлые запросы on" и "тяжёлые запросы off"

чтобы временно отрубать кеш и т.п.

типа как в флаг SQL_NO_CACHE

Друзья, вообщем весь день я пытался сделать следующее: настроить линкед сервер от mssql до clickhouse

я открыл все порты, проверил телнетом ip сервера 8123

скачал драйвер, подключил. ошибок не отобразил

но он упорно не видит таблицы

ERROR: S client not available

задал пользователю default пароль

база default

просто не знаю в какую сторону копать

я проверил на клиенте, с параметрами все ок и пользователь и пароль и ip кроме порта вместо 8123 9000

может нужен другой порт?

8123 - http 9000 - native

Порт нужен того типа по которому работает драйвер

jdbc работает по 8123

tabix по 8123

логично что и odbc по 8123

удалось получить такую ошибку

There is an error in the query. Warning: A StringBuilder buffer has been overflowed by unmanaged code. The process may become unstable. Insufficient capacity allocated to the StringBuilder before marshaling it.

это я пытался написать select 1

windows 32 bit

Весьма интересно. Передам разработчику драйвера, может быть будет время разобраться.

Огромное спасибо!

Постарался сделать подробное issue

https://github.com/yandex/clickhouse-odbc/issues/25

Если удастся пофиксить ошибку, можно натравливать на Clickhouse Power BI , Excel , SSRS , Linked server делать ?

А никто не знает самый простой путь экспорта Oracle –> clickhouse ?

А никто не знает самый простой путь экспорта Oracle –> clickhouse ?

Csv

А у реплик сейчас поведение отличное от шардирования в плане обновления записей из DNS? Насколько я понимаю для шардов доменные имена разрешаются один раз и кэшируются, но у реплик видимо IP получают из ZK каждый раз, а тот их обновляет при изменении A записей?

Просто реплицированный сервер в ECS нормально работает с разрешением реплик по доменным именам, даже если меняются A записи...

Господа, занимаюсь немного ерундой пытаюсь понять какой будет размер базы. делаю такой вот запрос SELECT name, type, data_uncompressed_bytes / data_compressed_bytes AS `compress ratio` FROM system.columns WHERE (table = 'interface') AND (name IN ('packets_out', 'packets_in', 'load_in', 'load_out')) ┌─name────────┬─type───┬─────compress ratio─┐ │ packets_out │ UInt64 │ 19.37327848858 │ │ packets_in │ UInt64 │ 19.464664471097795 │ │ load_in │ UInt64 │ 8.07884175110083 │ │ load_out │ UInt64 │ 7.127004335631084 │ └─────────────┴────────┴────────────────────┘ хочу понять почему коэффициент сжатия так сильно отличается не нулевых рядов одинаковое колво.

всем привет. а нет ли в КХ операций сложения/вычитания массивов и аналога generate_series в pg (то есть генерация не с единицы до N как в range(N), а с произвольного числа)?

в доках не нашел ничего подобного

а, ну в принципе для вычитания и для generate_series можно использовать arrayFilter

но со сложением двух множеств вопрос остается открытым

а, сложение в принципе можно сделать так select groupArray(t) from (select arrayJoin([1,2,3,4]) as t union all select arrayJoin([5,6,7]) as t) но нет ли более простых путей? :) плюс это все таки не агрегатная функция для произвольного числа строк, а сложение именно двух массивов

несколько вопросов по движку GraphiteMergeTree функция any какая логика работы? какие имена функций в принципе доступны для использования? если метрика соответвует двум и более pattern какая логика применения параметров? возможно ли в pattern не указывать retention (будет ли использоваться из default)? аналог xFilesFactor - как то возможно задать ?

Ребят, а с последнего минского митапа презы не кидали ?