потому что я его потом буду читать

Это вообще из серии разработки софта, а не работы с БД

отлично

Это вообще из серии разработки софта, а не работы с БД

тут соглашусь. если от пользователя БД спрятана за ГУИ и он никогда не пишет запросы, можно хоть msgpack сделать языком запросов

я про это и говорю

в отдельных случаях

когда запрос генерится по каким-то внешним фильтрам

SQL просто банально неудобен

удобен.

неудобен - возможно, но он уже слишком популярен везде

Ежику и кактус вкусен

о чем спорить

я про это и говорю

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

разработчики чего?

монга, кстати, не заставляет BSON читать

Вопрос изначально был отм что нужен SQL . тк работать будут люди. они набирают пальцами SQL который знают. JSON это способ описания объекта а не запроса

эээ

SQL конвертируется в AST

так или иначе

разработчики чего?

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

по нему строится план

они обычно его знают

JSON точно так же конвертируется в AST

и по нему строится план

только JSON сам по себе уже дерево

только JSON сам по себе уже дерево

ещё раз. был бы yml - было бы дерево

а так - скобочки в кавычках

yml - надмножество json

какая разница?

только более читабельное. я в курсе.

кавычек и скобок с запятыми нет.

я не про json говорю

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

чем из дерева генератором делать SQL

юзер делает запрос руками в текстбоксе иногда

мы начали про графит

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

однофигственно, кмк. ладно, чат не про это - интересно продолжить, го в личку

только более читабельное. я в курсе.

читабельность - штука относительная. непечатный синтаксис далеко не всегда способствует читабельности

юзер в графане мышкой мышит

ага

вы еще про оракловых гуру расскажите, которые по SQL план запроса по запаху определяют

юзер в графане мышкой мышит

я там запросы ручками писал. я днище, видимо :)

кстати для grafana никто clickhouse адаптера еще не сделал?

https://grafana.net/dashboards/869 https://grafana.net/dashboards/882 не то?

на самом деле одно другому не мешает

я про то, что для доступа к данным в разные моменты может быть удобным разный API

https://grafana.net/dashboards/869 https://grafana.net/dashboards/882 не то?

Адаптер это штука позволяющая брать кликхаус как датасорс

сорри )

да, если бы был такой - выкинули бы influx нафиг

юзер в графане мышкой мышит

Ну оно четко все преобразуется в select ... Where Path in ... And Time > ...

ну или {"path": {"$in": [....]} .....

Я не думаю что если бы тут был json то было бы сильно лучше

да, если бы был такой - выкинули бы influx нафиг

Ну можно через прослойки к обычному граыиту прикрутить

Даже работает

а нужны ли они?

из инфлюкса графана забирает напрямую

а нужны ли они?

Легаси нельзя раз и заменить

если графит есть, то да

я даже вот про что

у influx'а достаточно удобно работать с тегами

в плане того, что пишется -- тип метрики и соответсвующие ей теги

CH колоночный

в нем можно было попробовать теги положить в виде колонок

скажем загрузку интерфейсов пишем как Interface | Load | In, object=<железка>, interface=<порт>

в нем можно было попробовать теги положить в виде колонок

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

в таблице метрик сделать при этом колонки object и interface

тогда ряд ненужных костылей вроде interface.load.in.<object>.* уйдет

и семантика запроса нормальная будет

в таблице метрик сделать при этом колонки object и interface

Я больше думаю про отдельную таблицу с текущими тэгами, без истории

https://github.com/lomik/carbon-clickhouse вот тут можно было бы как то парсить метрики в нормальные колонки =)

у influx эта таблица - самое слабое место

к ней постоянно lookup'ы идут

она в памяти должна быть

и пока не прососется - он просто писать не может

по сетевой части тегов относительно немного

несколько десятков от силы

> @BloodJazMan https://github.com/lomik/carbon-clickhouse вот тут можно было бы как то парсить метрики в нормальные колонки =) Есть такое желание. Только пока непонятно как это вписать в протокол графита и поддержать во всей цепочке доставки (carbon-c-relay etc)

О! Роман! и вы тут

Огромное вам спасибо за go-carbon

вы мне прямо сильно жизнь облегчили в свое время

=) Ну собственно я могу issue на github открыть мне видится это дело как набор параметризованных regexp которые просто экстрактят значение атрибута из названия метрики и все

т..е. эти данные только в конфиге carbon-clickhouse оставиться и все можно будет пробрасывать стандартным образом

=) Ну собственно я могу issue на github открыть мне видится это дело как набор параметризованных regexp которые просто экстрактят значение атрибута из названия метрики и все

Оно по скорости вставки вдарит

когда запрос генерится по каким-то внешним фильтрам

используйте ORM

ну тогда не regexp, а wildcards что нибудь типа такого [attributes:diamond-cpu] data-attibuted-table = graphite_attiributed_diamond_cpu attibute-wildcards= "servers.{host}.cpu.{cpu_name}.{metric_name}"

Вот все те, кто говорит, что SQL не удобен, вы кроме как с колокльни разработки кастылей и велосипедов в своем софте вообще расматриваете использование БД?

нет, не рассматриваем

для нас СУБД - элемент решения

в идеале - невидимый юзеру

ребят, может хватит про SQL?

вот да

вернемся к моему вопросу

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

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

по примеру WT, Inno и Rocks?

https://github.com/yandex/ClickHouse/tree/master/dbms/src/Storages где то тут посмотрите

ну тогда не regexp, а wildcards что нибудь типа такого [attributes:diamond-cpu] data-attibuted-table = graphite_attiributed_diamond_cpu attibute-wildcards= "servers.{host}.cpu.{cpu_name}.{metric_name}"

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

и немного вообще странно, т.к. проще делать колонку host, колонку cpu_name и забить на совместимость с графитом

да, спасибо