Такое решение задачи очевидно, но может есть уже готовый механизм (Вертика умеет работать с Кафкой "из коробки"). И нет необходимости придумывать свои костыли)

я не слышал про такое

Встает вопрос о том, в каком формата должны быть данные в кафке?

Нужен какой-то контейнер и тип упаковки данных

Текстовое - тормозить будет

Бинарное - потребуется пересборка формата/сериалайзера при правке схемы

Будет текстовая (JSON), тк переделывать то что уже взаимодействует с кафка не представляется возможным(

Джейсон в кафку....

"Ну я не знаю"

из кафки

мне лично вариант кафки не нравится как таковой

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

и всегда нужно выбирать из двух мест - то, что еще не было уложено в CH и то, что уже уложено

и мержить

а это уже 3 форамта хранения, различных и часто несовместимых между собой

Это да...

вдвойне сложнее, когда ты не "типичный data mining"

и у тебя нету этих зукиперов, кафок и прочего

а тупо нужно уложить ивенты в базу

а какой язык интересует?

язык чего?)

на каком языке вы хотите выгребать из кафки в кликхаус?

я уже выгребаю, на С++

хотя я отказался от Кафки пока что и заливаю в буфер таблицу, пока данных мало - работает прилично

Всем привет. А это разве нормально? SELECT number, if(number > 5, number, NULL) AS ifWithNull, if(number > 5, number, 0) AS ifWithoutNull FROM system.numbers LIMIT 10 ┌─number─┬─ifWithNull─┬─ifWithoutNull─┐ │ 0 │ \N │ 0 │ │ 1 │ \N │ 0 │ │ 2 │ \N │ 0 │ │ 3 │ \N │ 0 │ │ 4 │ \N │ 0 │ │ 5 │ \N │ 0 │ │ 6 │ \N │ 6 │ │ 7 │ \N │ 7 │ │ 8 │ \N │ 8 │ │ 9 │ \N │ 9 │ └────────┴────────────┴───────────────┘

а nullif такое же выдает? он вроде нормально работал

а так вообще нулы - сырые еще (

сами с нетерпением ждем, когда уже они нормально заработают )

включая nulls last / nulls first

SELECT number, if(number > 5, number, NULL) AS ifWithNull, if(number > 5, number, 0) AS ifWithoutNull, nullIf(1, NULL) AS nullIfs FROM system.numbers LIMIT 10 ┌─number─┬─ifWithNull─┬─ifWithoutNull─┬─nullIfs─┐ │ 0 │ \N │ 0 │ 1 │ │ 1 │ \N │ 0 │ \N │ │ 2 │ \N │ 0 │ \N │ │ 3 │ \N │ 0 │ \N │ │ 4 │ \N │ 0 │ \N │ │ 5 │ \N │ 0 │ \N │ │ 6 │ \N │ 6 │ \N │ │ 7 │ \N │ 7 │ \N │ │ 8 │ \N │ 8 │ \N │ │ 9 │ \N │ 9 │ \N │ └────────┴────────────┴───────────────┴─────────┘

Не очень понимаю логику nullIf...

в вашем кейсе сработает вот так

multiIf(number > 5, NULL, number) AS ifWithNull

@garikanet Чем вызвано требование "Пользователь с правами не readonly" для smi2/clickhouse-frontend?

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

для того чтобы случайно не получить результат в 50М строк

дополнительно ещё пару параметров передаётся, а если userRO то переназначить их нельзя => ошибка С обновление я выложу правки - чтобы можно было с RO работать

Через ALTER TABLE ADD COLUMN name можно ли добавить колонку в поле Nested, если обращаться через точку?

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

Ясно, спасибо за разъяснение. Часть пользователей спокойнее как раз с readonly правами пускать

можно поставить readonly=2

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

можно поставить readonly=2

отличная идея, спасибо

а тут есть ребята которые пишут smi2/clickhouse-frontend ?

да)

а может знаете proxy режим в планах есть ?

а может знаете proxy режим в планах есть ?

Мы выставили за прокси и CH и webgui. В хост порт надо писать со слэшем в конце, работает

нее. я немного про другое. я хотел бы что бы фронтенд общение с кликхаусом вел сам. сейчас же он стучится с веб браузера. но у меня нет и не будет возможности использовать его в таком режиме :(

А зачем вам это если не секрет? Чтоб данные авторизации не публиковать?

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

а iptables? прокинуть порт нельзя?

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

контроля над шлюзом нет?

графана молодец. она делет запросы от себя.

контроля над vpn шлюзом нету да

если есть доступ есть хоть по какому то порту, то можно сделать

есть по 22 и по 443

на обоих что логично висят демоны

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

Самый простой вариант nginx + proxy_pass на CH сервер, вроде как кто то такое запускал

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

ну если 443 есть то proxy_pass и все готово

Андрей, спасибо это вариант понятен и прост. однако на мой вгзляд выглядит костылем. мой вопрос был исключительно про корректную реализаицию когда nginx по дороге нету.

Тут скорее проблема с вашей стороны) Т.е. если бы ничего не висело на 443 порту, то можно было бы поменять порт в конфиге clickhouse и никакого nginx не было бы.

если хочется работы aka grafana, то nginx вполне вписывается на место графановского бекенда

ок. ответ понял. не горит вовсе.

а может знаете proxy режим в планах есть ?

Да, я планирую, точнее уже делаю серверную версию, что будет : - Автоматическая маршрутизация запроса между MySQL / CH - т/е gui будет уметь работать с mysql ( возможность добавить любую другую sqlLike базу ) - Шаринг запроса + результата - Дашбординг - LDAP auth - Хранение истории всех запросов на сервере - Работа с кластером CH Но срок когда "оно" будет +- в конце весны/начало лета в мечтах:))) Если интересно вот мой kanban/roadmap: https://tree.taiga.io/project/isublimity-chg/kanban

@garikanet спасибо! здорово.

как я говорю не горит вовсе и как делать обертки понятно. но хочется без оберток.

похоже на новую графану)

кстати clickhouse теперь умеет быть https сервером, но надо немного шаманства с сертификатами

когда ждать http2? :)

как только он в poco появится ;)

а зачем он нужен ?

боюсь, что только для галочки

слоу-poco

хотя встроенное сжатие может быть полезно, наверное, при активном обмене запросами

так сжатие и так есть

https://github.com/yandex/ClickHouse/blob/master/dbms/tests/queries/0_stateless/00302_http_compression.sh

да я не вижу смысла, признаться

это ж не кастомер фейсинг, пофигу что там летает :)

а куда сертификаты класть для https?

да куда угодно в конфиге же указать можно https://github.com/yandex/ClickHouse/blob/1af6311a9974fbbd7e5c5c9d14dd69cb9ee34686/dbms/src/Server/config.xml

по умолчанию server.crt и server.key, видимо, в той же папке, где и config.xml серверный

Добрый день. Пробовал фичу параллельного исполнения запроса между репликами - не удалось получить прирост производительности по сравнению с вариантом без параллелизма. При этом ключ сэмплирования - случайное UInt16 и сэмплированные запросы идут быстрее обратно пропорционально доле сэмпла (для сэмпла 0.1 запрос в 10 раз быстрее, чем по всем данным). Есть ли рекомендованная конфигурация, чтобы и репликацию включить, и запрос полноценно параллелился между репликами? P.S. Если я верно понял, при выполнении запросов вида SELECT sum(metric), dimensions... FROM fact group by dimensions... по Distributed таблице, он сначала агрегируется на шардах, входящих в таблицу, а затем результаты агрегируются на ноде, на которой находится Distributed таблица. Создалось впечатление, что распараллеливание по репликам работает иначе (все данные для агрегации поднимаются параллельно с реплик и пересылаются по сети на одну ноду). Есть ли возможность сделать, чтобы работало так же, как и при шардировании?

Плюс ещё вопрос: есть ли способ получить из ClickHouse план исполнения запроса или что-то вроде того?

Добрый день. Пробовал фичу параллельного исполнения запроса между репликами - не удалось получить прирост производительности по сравнению с вариантом без параллелизма. При этом ключ сэмплирования - случайное UInt16 и сэмплированные запросы идут быстрее обратно пропорционально доле сэмпла (для сэмпла 0.1 запрос в 10 раз быстрее, чем по всем данным). Есть ли рекомендованная конфигурация, чтобы и репликацию включить, и запрос полноценно параллелился между репликами? P.S. Если я верно понял, при выполнении запросов вида SELECT sum(metric), dimensions... FROM fact group by dimensions... по Distributed таблице, он сначала агрегируется на шардах, входящих в таблицу, а затем результаты агрегируются на ноде, на которой находится Distributed таблица. Создалось впечатление, что распараллеливание по репликам работает иначе (все данные для агрегации поднимаются параллельно с реплик и пересылаются по сети на одну ноду). Есть ли возможность сделать, чтобы работало так же, как и при шардировании?

При распараллеливании по репликам, реплики работают как отдельные шарды, с которых читается соответствующая часть сэмпла данных. То есть, ускорение должно быть таким же как при сэмплировании (за исключением деталей - передача большего количества данных по сети, суммирование случайных задержек при использовании большого количества серверов). Было бы интересно узнать, почему в вашем случае это не так. Надо больше подробностей. Вопрос - а сколько сейчас шардов и реплик?

При распараллеливании по репликам, реплики работают как отдельные шарды, с которых читается соответствующая часть сэмпла данных. То есть, ускорение должно быть таким же как при сэмплировании (за исключением деталей - передача большего количества данных по сети, суммирование случайных задержек при использовании большого количества серверов). Было бы интересно узнать, почему в вашем случае это не так. Надо больше подробностей. Вопрос - а сколько сейчас шардов и реплик?

Пробовал на конфигурациях 2 шарда по 2 реплики на каждый и 1 шард с 4 репликами.

Плюс ещё вопрос: есть ли способ получить из ClickHouse план исполнения запроса или что-то вроде того?

Что-то похожее на план выполнения запроса есть в логе - смотрите по словам Query pipeline: Там довольно скудная информация, к тому же этот план выводится по части запроса на локальном сервере.

Пробовал на конфигурациях 2 шарда по 2 реплики на каждый и 1 шард с 4 репликами.

Можно ли привести конфигурацию таблиц, конфигурацию кластера и примеры запросов с временем выполнения? Можно в почту на clickhouse-feedback. Вдруг получится догадаться.

Можно ли привести конфигурацию таблиц, конфигурацию кластера и примеры запросов с временем выполнения? Можно в почту на clickhouse-feedback. Вдруг получится догадаться.

Да, минут через 15 скину в почту.

Добрый день. Пробовал фичу параллельного исполнения запроса между репликами - не удалось получить прирост производительности по сравнению с вариантом без параллелизма. При этом ключ сэмплирования - случайное UInt16 и сэмплированные запросы идут быстрее обратно пропорционально доле сэмпла (для сэмпла 0.1 запрос в 10 раз быстрее, чем по всем данным). Есть ли рекомендованная конфигурация, чтобы и репликацию включить, и запрос полноценно параллелился между репликами? P.S. Если я верно понял, при выполнении запросов вида SELECT sum(metric), dimensions... FROM fact group by dimensions... по Distributed таблице, он сначала агрегируется на шардах, входящих в таблицу, а затем результаты агрегируются на ноде, на которой находится Distributed таблица. Создалось впечатление, что распараллеливание по репликам работает иначе (все данные для агрегации поднимаются параллельно с реплик и пересылаются по сети на одну ноду). Есть ли возможность сделать, чтобы работало так же, как и при шардировании?

Возможно с каждой реплики/шарда получается очень большой промежуточный результат. Если все данные по вашему group by доступны на одной ноде, то попробуйте переписать запрос с distributed_group_by_no_merge

Привет. А можите направить меня как лучше в кластере удалять по месяцам?

Добрый! Как будет обрабатываться вот такой запрос select description,price from goods where price>50 если я правильно понимаю то сначала КХ достанет столбец price в память и найдет записи где ценник больше 50 и только потом достанет соотвествующие куски из столбца description.... Или оба столбца будут сразу подниматься в память? (предполагаю что эти столбцы не входят в индекс и description тектовый с количеством знаков от 50 до 150 символов)... Или другими словами поддерживает ли КХ late materialization?

в кх есть where, а есть prewhere

в документации описано было, как работают

в кх есть where, а есть prewhere

спсб

А на кх какая лицензия? А то я в документации что-то не нашел.

apache 2

https://github.com/yandex/ClickHouse/blob/master/LICENSE