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

как ее сделать нормальной?

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

где-то порт, где-то процессор

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

ну экстрактить заданные колонки для каждого вида путей... через конфиг http://metrics20.org/spec/ вот может быть сразу такой ресивер реализовать?

Вот прям сейчас начали процесс деплоя связки CH+graphite-clickhouse(и прочее)+grafana

у меня возник такой вопрос

на сколько graphite-clickhouse дает полный набор функций graphite? Можно там суммировать разные метрики например?

ну экстрактить заданные колонки для каждого вида путей... через конфиг http://metrics20.org/spec/ вот может быть сразу такой ресивер реализовать?

Экстрактить колонки на каждую метрику это очень и очень дорого с точки зрения ресурсов. Хочется колонки - нужен другой протокол. Metircs 2.0 конечно прекрасная инициатива, но она тоже со своими минусами - например очень многословна и сложна в парсинге (точно также).

на сколько graphite-clickhouse дает полный набор функций graphite? Можно там суммировать разные метрики например?

не дает вообще никаких, нужно брать graphite-api/graphite-web/carbonapi и использовать их

graphite-clickhouse реализует сабсет API который может использовать graphite-web в виде CLUSTER_SERVERS или carbonapi

более того, насколько я помню сейчас ты даже json данных получить не можешь

@rlomonosov или ты в итоге json уже реализовал?

а, ну т.е. если graphite-clickhouse+graphite-web 0.9.15, то все будет красиво и полно?

а, ну т.е. если graphite-clickhouse+graphite-web 0.9.15, то все будет красиво и полно?

да

отлично!

а горизонтально это все масштабируется?

а, ну т.е. если graphite-clickhouse+graphite-web 0.9.15, то все будет красиво и полно?

ну учти что оно в статусе что-то уровня pre-alpha

а горизонтально это все масштабируется?

никто не проверял

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

оно в статусе "вроде кажется работает если вгетом пнуть"

можно несколько экземпляров (graphite-clickhouse+graphite-web) развернуть для распределения нагрузки

они stateless?

@lexa_work я с carbonapi его интегрировал, с ним работает /render но были какие-то проблемы с /metrics/find

но графана могла данные даже показать

ну будем посмотреть

Еще сейчас graphite-clickhouse по времени запроса дает такой же оверхед как чтение данных

вот это не очень понял

про оверхэд, что там не так?

Можно пооптимизировать код. Наверно

про оверхэд, что там не так?

Выборка данных из кх - допустим 100мс. Потом оно еще 100 проведет делая доп работу

Вероятно это можно ускорить ощутимо

там никакого pushdown агрегаций в CH не делается?

выгребаются все данные и обрабатываются в graphite-clickhouse?

все сложные агрегации делаются вообще на стороне graphite-web. в graphite-clickhouse выгребаются данные и доделывается rollup (домердживает то, что КХ еще не успел). ну еще логика поиска метрик (ракрытие звездочек)

понятно, спасибо за консультации я с graphite как-то не очень работал

все же питал надежды решениям в стиле metrics2.0 обойтись

но сейчас понадобилась функция в которой пользователи моглибы сами форировать некие производные метрики (KPI) на базе основных/базовых счетчиков

а такое, хоть в каком-то виде, поддерживается только в graphite (ну и grafana как UI)

А агрегатные функции в условиях это вообще валидный фичреквест? Кажется, было бы удобно. :) select job_id from rt_details where sum(reqps)=0 group by job_id; DB::Exception: Aggregate function sum(reqps) is found in WHERE or PREWHERE in query.

having

+1 к having

О, точняк! спс

затупил

А есть те, кто все еще для мониторинга использует православный munin? Если есть, то возможно плагин будет полезен: https://github.com/roistat/clickhouse-munin

ru.yandex.clickhouse.except.ClickHouseUnknownException: ClickHouse exception, code: 1002, port: 8123; Xc ��y u}n � v �QCode: 27, e.displayText() = DB::Exception: Cannot parse input: expected \t before: NULL\t1\tNULL q10.0\t1

Почему ругается на jdbc setNull?

6. SQL support. If you are familiar with standard SQL, we can't really talk about SQL support. NULLs are not supported.

Так в jdbc драувере он есть

https://clickhouse.yandex/reference_en.html#Distinctive features of ClickHouse

jdbc - это стандарт,я так понимаю, там нельзя было не имплементировать метод, обозначенный интерфейсом

Т.е. для каждого типа какие-то дефолтные пустые значения вставлять?

Там не имлементированные методы исключения брасают

А этот нет

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

разве надо додумывать? если пустая строка в tsv - кликхаус сам запихнет дефолтное значение

ну, в смысле, INSERT INTO t1 FORMAT TabSeparated, где (x String, y String, z String) и tsv-файлик с содержимым x\t\tz вставит x='x', y='' и z='z'

А если длинное целое? 0 ?

ага

https://clickhouse.yandex/reference_ru.html#Значения%20по%20умолчанию

> Если выражение для значения по умолчанию не указано, то в качестве значений по умолчанию будут использоваться нули для чисел, пустые строки для строк, пустые массивы для массивов, а также 0000-00-00 для дат и 0000-00-00 00:00:00 для дат с временем. NULL-ы не поддерживаются.

ну, если кастомное DEFAULT выражение не указывали, конечно. если указывали, то оно

А этот нет

возможно, мейнтейнер просто сам об этом не знал, либо ожидается сделать поддержку нуллов в будущем. в любом случае иначе никак :\

Null уже в этом году

На каждый запрос создавать prepatedstatement только с ненулевыми колонками?

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

Я правильно понимаю, что сейчас, если все реплики шарда distributed-таблицы недоступны, то запись в таблицу продолжает идти, но та часть данных, которая должна была попасть на этот шард, просто теряется, при этом insert не возвращает ошибку?

Может есть какой-то механизм fall-back на этот случай?

>>из документации

The sampling expression (optional) can be any expression. It must also be present in the primary key. The example uses a hash of user IDs to pseudo-randomly disperse data in the table for each CounterID and EventDate. In other words, when using the SAMPLE clause in a query, you get an evenly pseudo-random sample of data for a subset of users.

проверил - могу создать семплирующую таблицу без выражения сэмпла в primary key

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

какой primary key я должен выбрать для таблицы, сейчса это MergeTree(date, sipHash64(sessionId), (domainId, eventType, ts, itemId, eventId, sipHash64(sessionId)), 8192). во всех запросах используется domainId, eventType, ts. в части используется itemId.

по-моему date не хватает в самом начале (перед domainId). ты же не будешь по всему промежутку данные гонять?

т.е. date всегда лучше ставить первым?

ну, не факт, зависит от запросов. если не будешь фильтровать по дате 100% запросов, то может и не надо первым ставить просто пока partition'ы делятся по месяцам, имхо, эффективнее будет сначала индексировать по дате, но я могу ошибаться

я думал если в запросе фильтр по domainId = AND eventType = то потом как раз timestamp должен быть в индексе

если так, то наверное да, domainId, eventType, date/ts

но вот ts timestamp если есть в ключе, после него же уже бесполезно по чему-то сортировать. надо тогда его в конец ключа сдвигать?

я в основном отталкиваюсь от этого https://groups.google.com/forum/#!searchin/clickhouse/primary$20key%7Csort:relevance/clickhouse/eUrsP30VtSU/903Smz8pAgAJ

и этого https://groups.google.com/forum/#!searchin/clickhouse/primary$20key|sort:relevance/clickhouse/ad7YEo4oLNQ/DaenZMiJCgAJ

Я правильно понимаю, что сейчас, если все реплики шарда distributed-таблицы недоступны, то запись в таблицу продолжает идти, но та часть данных, которая должна была попасть на этот шард, просто теряется, при этом insert не возвращает ошибку?

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

какой primary key я должен выбрать для таблицы, сейчса это MergeTree(date, sipHash64(sessionId), (domainId, eventType, ts, itemId, eventId, sipHash64(sessionId)), 8192). во всех запросах используется domainId, eventType, ts. в части используется itemId.

Ключ сэмплирования имеет смысл только если до него, для каждого значения префикса первичного ключа, есть достаточно большое количество строк. Для примера, ставить ключ сэмплирования после ts (timestamp с точностью до секунд) не имеет смысла, так как для каждой одной секунды есть мало данных. При выборе первичного ключа следует иметь ввиду, что он не обязан быть уникальным. То есть, itemId, eventId на конце, скорее всего, бесполезны. Да, по ссылке на Google Groups нормальное описание.

я использую ReplacingMergeTree, поэтому своя уникальность нужна.

возможно ли отделить storage отдельно?

В кодовой базе хранение и обработка запросов уже отделены. Например, мы недавно сделали (как обещали) программу clickhouse-local, которая позволяет гонять кликхаусный SQL по обычным файлам. Есть и другие варианты - например, можно поддержать Parquet в качестве формата данных, или наоборот, сделать, чтобы данные из ClickHouse можно было получить в виде RDD для Spark. Не знаю, кто и зачем будет это делать. Но как отдельная библиотека, хранение не оформлено.

я использую ReplacingMergeTree, поэтому своя уникальность нужна.

Тогда ключ сэмплирование перенесите поближе к началу. Например, между eventType и ts. Сэмплирование с sipHash может не особо хорошо работать, так как этот sipHash надо вычислять для выполнения запроса. А вообще, SAMPLE 0.1 - это синтаксический сахар для условия, примерно такого: ... AND sample_key < uint_max * 0.1 в WHERE.

а если делать hash как колонку в базе, возможно будет лучше

Да.

В кодовой базе хранение и обработка запросов уже отделены. Например, мы недавно сделали (как обещали) программу clickhouse-local, которая позволяет гонять кликхаусный SQL по обычным файлам. Есть и другие варианты - например, можно поддержать Parquet в качестве формата данных, или наоборот, сделать, чтобы данные из ClickHouse можно было получить в виде RDD для Spark. Не знаю, кто и зачем будет это делать. Но как отдельная библиотека, хранение не оформлено.

Спасибо

Хм, а у кликхауса есть ограничение на размер принимаеого POST запроса?

нет

вопрос: из-за чего может input csv-файла производиться не целиком? csv файлы делались экспортом из mysql, предыдущие файлы втягивались нормально, а последний из 4 миллионов записей вставляет только 40 тысяч.

ограничения есть у типичных отсылальщиков POST

вопрос: из-за чего может input csv-файла производиться не целиком? csv файлы делались экспортом из mysql, предыдущие файлы втягивались нормально, а последний из 4 миллионов записей вставляет только 40 тысяч.

а ты как импортируешь?