я что-то не так делаю, или с Enum'ами жутко неудобно работать? INSERT INTO events (type, ...) SELECT 'hit', ... FROM hits; - не прокатит. надо в селекте CAST('hit' AS Enum8(...) AS type писать. SELECT * FROM events WHERE type = 'hit'; - не прокатит, type = 1 - тоже. или toInt8(type) = 1, или toString(type) = 'hit'.

sumIf(conn,site='aaa') у меня вполне себе катит

site - как раз enum

А. то есть просто в WHERE приведение типа не работает, а в функциях норм. SELECT countIf(type = 'hit') FROM event WHERE date = '2016-10-15'; - работает, но не используется индекс по type. SELECT count() FROM event WHERE date = '2016-10-15' AND if(type = 'hit', 1, 0); - работает с индексом, но выглядит дико, конечно :D

Вы что-то не так делаете.

SELECT count(*) FROM site_activity WHERE site = 'rt' ┌─count()─┐ │ 23727 │ └─────────┘ 1 rows in set. Elapsed: 0.004 sec. Processed 174.21 thousand rows, 174.21 KB (38.49 million rows/s., 38.49 MB/s.)

Возможно, я поэтому и спрашиваю :О

столбец определен как site Enum8(...)

и там Enum8('rt' = 1) например?

угу

Ыыы. Прикольно. У меня так же. Спасибо, пойду разбираться

с enum-ами засада когда надо расширить их количество.

версия у меня не самая свежая - 1.1.53981. Может чего и поменяли

понял, это из-за индекса в MergeTree по Enum8-полю. В таблице без индекса всё ОК.

причем после OPTIMIZE TABLE кол-во данных, доступных по простому type = '..', меняется где-то видел обсуждение подобного (но не связанного с енамами), то ли на гуглогруппах, то ли на гитхабе

понял, это из-за индекса в MergeTree по Enum8-полю. В таблице без индекса всё ОК.

то есть в индекс лучше не пихать enum?

ну, похоже, но я не претендую на авторитет :) я сделал пока String от греха подальше

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

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

https://clickhouse.yandex/reference_ru.html#MergeTree Движок принимает параметры: имя столбца типа Date, содержащего дату; выражение для семплирования (не обязательно); кортеж, определяющий первичный ключ таблицы; гранулированность индекса. Пример: Пример без поддержки сэмплирования: MergeTree(EventDate, (CounterID, EventDate), 8192)

Понятно, аналог по составному ключу, у которого жесткое правило ввиде "Тип столбца с датой - обязательно Date (а не DateTime)."

да, его индексом, наверное, некорректно называть

Понятно, аналог по составному ключу, у которого жесткое правило ввиде "Тип столбца с датой - обязательно Date (а не DateTime)."

Не совсем, сама дата именно в ключе не обязательна. Дата обязательна для mergetree, т.к. по ней идет партиционирование

А ключ - это как будут отсортированы записи в рамках партиции. Это надо выбирать исходя из запросов

я что-то не так делаю, или с Enum'ами жутко неудобно работать? INSERT INTO events (type, ...) SELECT 'hit', ... FROM hits; - не прокатит. надо в селекте CAST('hit' AS Enum8(...) AS type писать. SELECT * FROM events WHERE type = 'hit'; - не прокатит, type = 1 - тоже. или toInt8(type) = 1, или toString(type) = 'hit'.

SELECT * FROM events WHERE type = 'hit'; - не прокатит, type = 1 - тоже. В последней версии такие запросы должны работать. Там действительно была проблема когда Enum был в ключе: любые забросы типа enum_field = 'что-то' были false.

о, спасибо большое :)

существует ли какой-то инструмент для накатывания миграций?

https://bitbucket.org/nocproject/noc/src/5b5463bc8c62d07853dc3d995f35a1737889d3f3/core/clickhouse/model.py?at=feature%2Fmicroservices&fileviewer=file-view-default#model.py-74

мы как-то так сделали

существует ли какой-то инструмент для накатывания миграций?

Мы начали реализовывать, https://github.com/smi2/phpMigrationsClickhouse Но "новости" о том что скоро появится поддержка в самом CH - раскатка ALTER по всем серверам кластера => приостановили разработку. Если интересно будет сообществу - можем продолжнить "пелить" ))

не думали сделать это расширением к phinx?

не думали сделать это расширением к phinx?

Первый раз увидел, мы mybatis используем для mySql) Посмотрю можно ли прикрутить, но основная проблема которая была и почему начали свое делать - несколько кластеров , разное кол-во реплик/шардов. И разные стратегии донакатывать миграцию или откатывать )

Ребята, существует инструмент для управления миграциями и очень хороший. Liquibase. Для CH я понимаю его надо обработать напильником.

Кроме ликвибейза есть еще куча вариантов, практически у каждого языка есть свой фаворит. Тащить джаву на сервак php-приложений не очень хорошо.

zk всё равно на java, мне этот аргумент кажется несколько странным

Разобрался с rollup'ами - я сам накосячил в конфиге и incl не include'ил делая пустую секцию с роллапами

но теперь другие вопросы

ибо я вот подождал 12 часов при той же схеме (age=0, precision=1 -> age=3600, precision=60)

делаю селект: echo "select Time from graphite where Path='haggar1.agent.0.metrics.0' and Time < toUInt32(now()-3*3600) order by Time limit 5" | clickhouse-client ожидаю увидеть уже пороллапленные значения, а получаю посекундные. Методом тыка смог найти 2-3 интервала где они поролаплены

Ролап происходит при мерже. Мерж происходит в фоне

И вызывается по обычным правилам

С optimize final можно вызвать принудительно

ок, поставил делаться OPTIMIZE TABLE graphite_local PARTITION 201611 FINAL

посмотрим что станет

ага. FINAL нужен для того, что бы КХ переобрабатывал уже существующие партиции

но его как я понимаю имеет смысл выполнять только на что-то старше месяца?

Зависит от настроек ролапа

а url unescape функции в КХ нету?

а то вот extractURLParameter отображает плюсики вместо пробелов :(((

это не эксейпинг, afair

ну, да, чаще url encode / decode называют

url unescape нет. Можно добавить в список мелких фич. extractURLParameter не разбирает %-encoding и плюсики. Это сделано потому что в Метрике URL-ы записываются в базу частично раскодированными (раскодированы все символы кроме отдельных). А это сделано, в свою очередь, по двум причинам: - чтобы удобнее отображать данные и искать в данных; - потому что из браузеров приходят URL-ы зачастую в неизвестной, в неправильной, в испорченной кодировке, в дважды испорченной кодировке и т. п., и приходится делать много работы, чтобы привести их к человеческому виду.

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

спасибо!

у меня очень мощный вопрос: почему ReplacingMergeTree не был задокументирован? это непроверенный engine который никогда-никогда не должен использоваться, или я просто должен создать пулл реквест с документацией?

ыыыы! да! тоже сильно удивился в свое время

просто создай пулл-реквест с документацией

тогда его начнут проверять :)

ну может это страшная тайна которая должна умереть

Если я правильно понимаю, то ReplacingMergeTree основа для GraphiteMergeTree

который тоже не задокументирован

> We have not done these optimizations, because we don't use FINAL for production queries in serious load, only for rare queries or for small load. > Even ReplacingMergeTree was developed by request of another department, who convinced me, that they will use it in small workload.

( https://groups.google.com/forum/#!topic/clickhouse/jYwoyPblsk8 ) т.е. похоже, что он не используется в, собственно, метрике; и работает медленнее, чем мог бы

Медленно, если использовать select final (не рекомендуется)

Правильно писать все запросы с расчетом на то, что данные могут быть ещё не схлопнуты

т.е. например argMax() по версии использовать

кстати, а нет способа селектить из GraphiteMergeTree сразу накладывая правила агрегации как заданы в конфиге?

select final, но будет медленее

final не работает на GraphiteMergeTree

Можно сделать, чтобы работал, но будет действительно медленно.

когда я копирую данные из одной таблицы в другую insert from select, какой формат передачи данных? я копирую из таблицы 240гб данных на примерно 60гб. Progress: 183.94 million rows, 267.35 GB. какие накладные расходы на копирование? потому что я ожидал что количество прочитанных данных будет ~60гб, или по крайней мере ~120гб(в два раза больше)

т.е. я копирую только часть данных, которая по моим оценкам 60гб

Можно сделать, чтобы работал, но будет действительно медленно.

А как вы сами обходите то что графитные данные нужно выавнивать и пр.

т.е. я копирую только часть данных, которая по моим оценкам 60гб

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

А как вы сами обходите то что графитные данные нужно выавнивать и пр.

Что ты имеешь ввиду под выравнивать?

Что ты имеешь ввиду под выравнивать?

графит ожидает данные выравненные по precision

timestamp-timestamp%precision

фактически

равными кусками

черер precision промежутки

Даже если бы был final, то это не помогло бы. Запрос на большой интервал может покрыть несколько маленьких с разным precision

Мы сейчас эту часть допиливаем, расскажу как будет. При формирование запроса мы выбираем один presision и запросом в КХ доагрегируем до него. Presision выбирается наиболее крупный из периода куда попадает запрос. Например если у нас минутная метрика и мы хотим данные за 10 последних дней, а начиная с недели происходит угрубление до 5ти минут мы весь запрос угрубляем до 5ти минут

черер precision промежутки

Округляем время путём intDiv на константу и домножения обратно в SELECT.

Т.е. схема все равно у вас хранится и в клиенте тоже? Чтобы он константу мог выбрать

Да. Но сейчас есть FR, чтобы можно было смотреть схему в системной таблице в ClickHouse.

Вот мне тоже хочется такого - хотябы прямо в виде xml. Только не очень понятно что делать, если клиента натравят на distributed или merge таблицу

А в чем проблема?

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

Имхо это вообще не надо делать. Правила должны быть одинаковые

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

запрос вида "все данные старее этой даты". дата в primary key есть

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

вроде разжатые, но я не уверен

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

Нет, так не бывает

Если фильтр такой есть, должно работать