а в каком-то формате вывести нельзя? например 2017-01-01 - 2017-01-07 ?

:) SELECT now() AS dt, toRelativeWeekNum(dt) AS week_num, week_num * 7 AS day_num, toDate(day_num) AS date FORMAT Vertical Row 1: ────── dt: 2017-04-20 07:34:35 week_num: 2467 day_num: 17269 date: 2017-04-13

че-т типа того, очень грубо говоря

мне кажется, проще сделать юзер-френдли отображение на стороне штуки, которая будет потом эти данные отображать кому-то; не силами КХ

:) SELECT now() AS dt, toRelativeWeekNum(dt) AS week_num, week_num * 7 AS day_num, toDate(day_num) AS date FORMAT Vertical Row 1: ────── dt: 2017-04-20 07:34:35 week_num: 2467 day_num: 17269 date: 2017-04-13

??похоже на правду)) приду попробую

toMonday() же, нет?

а в каком-то формате вывести нельзя? например 2017-01-01 - 2017-01-07 ?

блин, а ведь и правда, если делать группировку не по toRelativeWeekNum, а по toMonday, должно быть точнее и нагляднее сорри :)

доберусь до дома поэкспериментирую. но вроде как toMonday похоже на правду

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

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

графану

@hagen1778 я так понял графана четко заточена под time-series, или я не прав (не юзал). А вот такое чтоб юзера строили свои таблицы выбирая произвольные дименшины вельюсы - такое вообще актуально для тех данных что обычно держат в КХ ? Почему спрашиваю, мы разрабатываем встраиваемое BI, такой себе легковесный микро-ROLAP, что-то вроде этого. Можно сделать коннектор к KX, но неясно может ли это быть кому-то нужно :)

я сделал для этого tabix.io - что бы проще было с запросом работать, там pivot есть над результатом

@hagen1778 я так понял графана четко заточена под time-series, или я не прав (не юзал). А вот такое чтоб юзера строили свои таблицы выбирая произвольные дименшины вельюсы - такое вообще актуально для тех данных что обычно держат в КХ ? Почему спрашиваю, мы разрабатываем встраиваемое BI, такой себе легковесный микро-ROLAP, что-то вроде этого. Можно сделать коннектор к KX, но неясно может ли это быть кому-то нужно :)

Действительно, графана заточена под timeseries. Но мы так же используем ее и для менеджеров: графики, таблицы, гистограммы, пайчарты. Правда, чарты уже заранее подготовлены для них. "чтоб юзера строили свои таблицы выбирая произвольные дименшины вельюсы" При работе с графаной этого можно достичь при умении писать запросы в КХ

SELECT ID, StartTime, Times AS Time FROM ( SELECT ID, minIf(Time, Event = 't') AS StartTime, arrayFilter(x -> (x >= StartTime), groupArray(Time)) AS Times FROM ( SELECT a.1 AS ID, a.2 AS Time, a.3 AS Event FROM ( SELECT [(1, 1, 'f'), (1, 2, 't'), (1, 3, 'f')] AS a ) ARRAY JOIN a ) GROUP BY ID ) ARRAY JOIN Times ┌─ID─┬─StartTime─┬─Time─┐ │ 1 │ 2 │ 2 │ │ 1 │ 2 │ 3 │ └────┴───────────┴──────┘

@garikanet и как трекшн есть? Народ спрашивает-пользуется? Просто не совсем неясно со стороны, какие сейчас потребности у тех кто использует КХ сейчас в продакшине.

SELECT ID, StartTime, Times AS Time FROM ( SELECT ID, minIf(Time, Event = 't') AS StartTime, arrayFilter(x -> (x >= StartTime), groupArray(Time)) AS Times FROM ( SELECT a.1 AS ID, a.2 AS Time, a.3 AS Event FROM ( SELECT [(1, 1, 'f'), (1, 2, 't'), (1, 3, 'f')] AS a ) ARRAY JOIN a ) GROUP BY ID ) ARRAY JOIN Times ┌─ID─┬─StartTime─┬─Time─┐ │ 1 │ 2 │ 2 │ │ 1 │ 2 │ 3 │ └────┴───────────┴──────┘

Спасибо, то что нужно.

Всем привет. Возник вопрос по кликхаусу, возможно даже стоит создавать ишью. Есть необходимость выбрать последнюю запись для "юзера" и вытянуть время этой записи. К примеру SELECT Time FROM events WHERE user = 'some' ORDER BY Time DESC LIMIT 1 но при этом кликхаус игнорирует ORDER и начинает выборку с самой первой записи (с учётом того, что есть EventDate формата Date для MergeTree) хотя казалось бы - более эфективно будет читать с конца, от последних записей

Или быть может есть какие-то альтернативы как создать запрос? Понятно, что можно кешировать в отдельную таблицу, или вообще отдельную базу, но это уже слишком. Хотелось бы возможностями самого кликхауса. Сейчас при 146М записей такой запрос занимает около 2.5 секунды В документации так же не нашел, что бы на ORDER BY влияли индексы

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

Только в ключе сначала должен быть user тогда, наверное

Не возникало с этим проблем, order by user, datetime desc limit 1 by user

Только в ключе сначала должен быть user тогда, наверное

Иначе будет побольше скан

Для теста сделал ORDER BY EventDate DESC Всё равно проходит через все записи) т.е. можно предположить, что никаки не анализирует лимит и сортировку

А у вас какой ключ?

EventDate - первичный как и принято для MergeTree user - вторичный

EventDate — это ключ партиционирования? Его надо в первичный ключ тоже добавлять, чтобы данные по нему сортировались

Его или Time

Перечитал документацию ещё раз по MergeTree. Похоже на то, что индексы используются только для WHERE При чтении из таблицы, запрос SELECT анализируется на предмет того, можно ли использовать индексы. Индекс может использоваться, если в секции WHERE/PREWHERE, в качестве одного из элементов конъюнкции, или целиком, есть выражение, представляющее операции сравнения на равенства, неравенства, а также IN над столбцами, входящими в первичный ключ / дату, а также логические связки над ними.

Ребят, а не подскажите, вот есть у меня кластер из 8 машин, есть данные разбитые, например, на 80 файлов примерно одного размера. Как лучше заливать данные? Если заливать через Distributed таблицу и использовать какой-нибудь адекватный ключ шардирования будут ли сильно лучше потом group by функции? Можно ли заливать через несколько Distributed таблиц на разныех машинах (чтобы увеличить параллельность процесса)? Будут ли тогда данные "одинаково" распределеяться по ключу шардирования для разных тачек? Просто делаю запрос с groupby и на локальной тачке получаю 0.1 сек, а на распределенной таблице 1.7 , все-таки большая разница

Стоит ли просто подготовить эти 80 файлов в отсортированном виде и заливать просто по принципе первые 10 в первую тачку, вторые 10 во вторую и т.п. ?

Заранее сортировать не нужно.

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

Будет быстрее

Нужно/не нужно зависит от того, как будет быстрее идти запрос в итоге :) После заливки все запросы идут в распределенную табличку, вот если данные на всех хостах будут разделены по ключу шардирования, будут ли запросы быстрее?

Есть какой-то бест практис на эту тему?

Скажите, detach partition - реплицируемая процедура?

из доков: "Запрос реплицируется - данные будут перенесены в директорию detached и забыты на всех репликах."

по опыту - реплицируется

FYI: провел несколько экспериментов и с правильным ключом шардирования при вставке получил те самые 0.2 сек на распределенном запросе, которые близки к локальному

FYI: провел несколько экспериментов и с правильным ключом шардирования при вставке получил те самые 0.2 сек на распределенном запросе, которые близки к локальному

Может в кратце описать что делали

Может в кратце описать что делали

Просто сделал вот такой ключ шардирования cityHash64(col1, col2, col3) для Distributed-таблицы и через нее все грузил (по факту через 6 Distributed-таблиц, мб это добавляет скорости загрузки, мб нет)

Первый запрос все равно может идти 1,5 секунды, но это типа прогрев, а дальше все резво

из доков: "Запрос реплицируется - данные будут перенесены в директорию detached и забыты на всех репликах."

а если несколько шардов? надо на каждом шарде детачить партиции или можно отправить детач на распределенную таблицу?

Народ, столкнулись с такой проблемой: Работали на сингл инстансе КХ. Подняли кластер 2 шарда по 2 реплики

сделали дистрибьютед таблицу

на сингл инстансе подключили кластер

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

в кластере стало данных больше

а там деньги...

как понять, что пошло не так?

Больше денег - это ведь хорошо!

тоже так подумал)

а что именно не так и как должно быть ?

на кластере данных больше становится

может я не правильно подключил удаленный кластер к сингл КХ?

я прописал конфиг кластера на сингл КХ

и создал дистрибьютед таблицу, которая указывает на кластер и локал таблицу

вот допустим

сингл КХ: 1607.24 - суммая по статистике

сделал инсерт селект

и локальной в дистрибьтед таблицу

и на кластере сумма стала: 2954.37

события на сингл КХ: 47067 кластер: 86392

сделал инсерт селект

А зачем, если распределённая таблица просто делегирует подзапросы на локальные?

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

Вы фактически заинсёртили в неё данные, которые там уже есть, ещё раз

почему они там есть?

в кластере пустые локал таблицы

Распределённая таблица у вас создана как ссылающаяся на локальную?

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

Можно глянуть show create table для распределённой таблицы, локальной исходной таблицы и локальных таблиц кластера? Можно в личку, чтоб тут не флудить

подскажите что это может значить? Code: 75. DB::Exception: Cannot write to file (fd = 1), errno: 32, strerror: Broken pipe

это ошибка на команду вида clickhouse-client -h 192.168.1.2 —query "select * from format Native" | clickhouse-client -h 192.168.1.1 —query "insert into format Native"

похоже что принимающий клиент закрыл соединение

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

https://github.com/moby/moby/pull/32691

вот и нету докера больше :/

жуть какая-то

вот и нету докера больше :/

https://github.com/moby/moby/pull/32691#issuecomment-295063346

кому он нахрен нужен этот их платный)

Здравствуйте, Денис!

Добрый день, всем! :)

Добрый вечер, вернее. И добрый вечер, Владимир :)

Можно глянуть show create table для распределённой таблицы, локальной исходной таблицы и локальных таблиц кластера? Можно в личку, чтоб тут не флудить

метедом научного тыка был достигнут успех. Судя по всему при переливе данных КХ не любит за раз получать по 100 млн записей.

экспорт пачками по 20 млн. вроде как дает успех

Денис, вы из Тарантула? :)

Ага :)

значит верно узнал))

Но мы же не конкуренты

вы так говорите, как будто я осуждаю :)

тут клевая тусовка собралась)

Все тут тихо сидят и показывают пальцем, вражина пришел :D

<joke mode=off>

)))

Мейлру использует клик много где