Tabix всё же требует писать SQL. Хотелось чего-то более простого, типа metabase

проще табикса ничего нет

ну, или я не встречал

@TanVD есть, но запрос все равно хотя бы раз написать надо будет )

seektable.com буквально на днях додебажили CH коннектор. Вроде бы работает, главное чтобы GROUP BY запрос отдавался в приемлимое время.

Ребят, а есть ли какой-то способ в range_hashed словаре использовать не числовой ID?

нескромный вопрос, а есть лимит на размер батча при вставке?

есть настройка max_insert_block_size (по умолчанию 1048576) - при вставке большего количества строк они будут вставляться батчами такого размера

Привет, а есть возможность соеденить два массива в select запросе?

У кого нибудь была задача посчитать номер недели с начала года? Как решали?

У кого нибудь была задача посчитать номер недели с начала года? Как решали?

https://clickhouse.yandex/docs/en/functions/date_time_functions.html#torelativeweeknum

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

Хочется с начала того же года. что и дата, или какого-то определенного года в прошлом?

Хочется с начала того же года. что и дата, или какого-то определенного года в прошлом?

того же года что и дата. Аналог SELECT EXTRACT(WEEK FROM now()); в Postgres.

Кажется, должна помочь комбинация toStartOfYear и toMonday. Что-то типа такого SELECT (toMonday(now()) - toMonday(toStartOfYear(now()))) / 7

Вопрос: если инициировать выборку из дистрибьютед таблицы под пользователем с ограниченными правами, то запросы в остальные шарды пойдут от имени какого пользователя? Указанного в конфигурации кластера <remote_servers> ?

Да, от указанного в <remote_servers>

Просите за нубский вопрос, но в ClickHouse возможно использование алиасов для неагреггированных полей? select t.field as SomeField from t

Возможно.

select field as SomeField from t будет работать

Кажется, должна помочь комбинация toStartOfYear и toMonday. Что-то типа такого SELECT (toMonday(now()) - toMonday(toStartOfYear(now()))) / 7

Спасибо! Это похоже то что нужно!

select field as SomeField from t будет работать

Спасибо, разобрался

Коллеги, кто-то в курсе проектов использования кх как централизованного хранилища логов приложения? Каждая запись кроме стандартных атрибутов содержит еще json размером до 10-20кб. Известны ли подводные камни ?

зависит от объема "стандартных аттрибутов"

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

он не предназначен для логов в "свободном формате"

Да, от указанного в <remote_servers>

Тогда возникает вопрос использования лимитов и квот. Если запрос приходит от условного юзера web с лимитами на память и время, то на другие шарды он уходит от уже другого пользователя без этих лимитов

Параметры попадаются на реплики

а что вы хотите сделать, допустим у вас есть логи (user_id, visit_date) и (user_id, purchase_date), и вам нужно по ним посчитать что?

Всем привет, подскажите, вот в ReplicatedMergeTree работает дедупликация, если в батче <100 строк, верно? Есть возможность обойти ее? Использовать Buffer перед RMT? Или может настройка use_uncompressed_cache влияет?

> Запрос INSERT разбивается на блоки данных размером до max_insert_block_size = 1048576 строк.

>Блоки данных дедуплицируются.

зачем обходить?

Параметры попадаются на реплики

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

зачем обходить?

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

а, ну сингл инсерты не рекомендуют, если батчи копить, то дублей не будет. Buffer да, решение. Но может что-то получше подскажут

День защиты детей 2017 #GoogleDoodle https://g.co/doodle/u9cqwz

Оке, а вот еще момент, который мне непонятен, если батчем, но в батче менее 100 строк? или там априори не работает дедупликация?

работает. В доке речь про последние 100 блоков. Про 100 строк ничего не написано.

Да верно.. Спасибо

День защиты детей 2017 #GoogleDoodle https://g.co/doodle/u9cqwz

https://www.youtube.com/watch?v=eB7owerZNo4

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

Что значит делать нечего ? Есть более эффективные хранилища ? Или кх будет падать ? Тормозить при 5 rps ?

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

тормозить не будет, падать не будет

Это обоснованное утверждение или просто мнение ?

это мнение основанное на базовом понимании дизайна column ориентированных БД и небольшом опыте эксплутации CH в случае когда данные в формате, который CH обрабатывает хорошо

Что значит делать нечего ? Есть более эффективные хранилища ? Или кх будет падать ? Тормозить при 5 rps ?

logstash+kibana+elasticsearch

logstash+kibana+elasticsearch

В чем преимущество ?

именно так, ELK просто создана для такого

оно создавалась для этого

а кликхаус не создавался))))

Оракл например для всего создавался, но тормозить везде ему это не мешает.

это офтоп, CH - это не "обычная субд"

это узко-специализированная СУБД

Да, отлично она заточена под то, что данные только вставляются.

нет, опять нет.

это не причина, это следствие

Павел, давайте начнем с простого. Вы разработчик кх ?

нет, я его пользователь

Вы изучали его код ?

который внимательно прочитал документацию и имеет пару баз в продакшене

Понятно. Значит просто мнение.

я это изначально сказал, выше

Спасибо за него. Но я бы хотел услышать обоснованное мнение по моему вопросу. Которое базируется на фактах а не на базовом понимании колоночных субд.

https://habrahabr.ru/company/yandex/blog/303282/

Если вам нужно просто хранить логи, у вас есть много вариантов. Вы можете загружать логи в Hadoop, анализировать их с помощью Hive, Spark или Impala. В этом случае вовсе не обязательно использовать ClickHouse. Всё становится сложнее, если вам нужно выполнять запросы в интерактивном режиме по неагрегированным данным, поступающим в систему в реальном времени. Для решения этой задачи, открытых технологий подходящего качества до сих пор не существовало.

этого достаточно, как ответ разработчиков?

Вопрос в количестве записей логов. Профит вы будете получать в случае множества записей. Например если льете логи доступа и разбиваете на нужные колонки для хранения в КХ миллион событий в день. Тогда дальнейший анализ или аналитика будет выполняться Очень Быстро. Если логов мало, то смысл КХ теряется

У меня ведь другой вопрос был.

Меня больше интересует сколько рпс можно ожидать ( при заданном сайзинге серверов) на вставку данных. Анализ логов будет ограничен только выборкой по нескольким полям. Никаких группировок и тп не требуется. Время на выполнение запросов на чтение достаточно "разумное для ожидания" может составлять и минуты.

Меня больше интересует сколько рпс можно ожидать ( при заданном сайзинге серверов) на вставку данных. Анализ логов будет ограничен только выборкой по нескольким полям. Никаких группировок и тп не требуется. Время на выполнение запросов на чтение достаточно "разумное для ожидания" может составлять и минуты.

1 реквест в секунду, расчитывайте на это

Это для какого сервера ? Откуда взята такая оценка ?

Потому, что в CH запиь не меряется в рпс

нужно вставлять редко, но много

а скорее в размере батча, который, желательно в тащах штук строк измеряется

Ок, уже лучше

батчи в несколько десятков/сотен тысяч строк в секунду - это норм

Меня больше интересует сколько рпс можно ожидать ( при заданном сайзинге серверов) на вставку данных. Анализ логов будет ограничен только выборкой по нескольким полям. Никаких группировок и тп не требуется. Время на выполнение запросов на чтение достаточно "разумное для ожидания" может составлять и минуты.

Зависит и от сложности вставки

Что значит сложность вставки ?

Что значит сложность вставки ?

Я писал графитные данные, сразу в бинарном формате. Это string, float64, int 32, date

Что значит сложность вставки ?

чем больше колонок и данных в них тем медленнее

У меня есть опыт записи логов с приложений в кх. Стр-ра примерно следующая: Date, Time, appName, Type, Message, где Message json в несколько kb. Логи собираются в батчере и пушаться по достижению лимита или таймаута. Вставка примерно 20к/с на 16core, 32gb ram. Существенной нагрузки сервер не испытывает. Но были проблемы с выводом последних сообщений из таблицы в графане, т.к. колонка Message имеет огромный размер. имхо

Таких строк я впихивал 2.5млн в секунду, батчами по примерно 250 тысяч.

У меня есть опыт записи логов с приложений в кх. Стр-ра примерно следующая: Date, Time, appName, Type, Message, где Message json в несколько kb. Логи собираются в батчере и пушаться по достижению лимита или таймаута. Вставка примерно 20к/с на 16core, 32gb ram. Существенной нагрузки сервер не испытывает. Но были проблемы с выводом последних сообщений из таблицы в графане, т.к. колонка Message имеет огромный размер. имхо

Ура !

Но на 16 ядерном цпу, 128гб рам

В смысле задача аналогичная

20к/с это чего ?

Строк или запросов с батчами ?

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

10 полей по 1кб ему лучше чем 1 поле на 10кб

Строк или запросов с батчами ?

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

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

было дело, такое еще умела RethinkDB, которая как монга, но сильно легче

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