В обоих случаях будет ошибка и останется предыдущая версия данных в словаре.

Всем привет! Заметил в доках, что в ReplicatedMergeTree, если указан ключ партиционирования Date, то в первичном ключе его указывают последним. Как это работает? Просто необходимо потом делать селекты с условием prewhere date between .... В этом случае необходимо добавить Date в начало кортежа с первичным ключом или все так же в конце?

по дате оно и так у вас будет отсортировано, поэтому дату ставят в конец

Всем привет! Заметил в доках, что в ReplicatedMergeTree, если указан ключ партиционирования Date, то в первичном ключе его указывают последним. Как это работает? Просто необходимо потом делать селекты с условием prewhere date between .... В этом случае необходимо добавить Date в начало кортежа с первичным ключом или все так же в конце?

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

спасибо

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

Но всё зависит от ваших данных

Всем привет! Заметил в доках, что в ReplicatedMergeTree, если указан ключ партиционирования Date, то в первичном ключе его указывают последним. Как это работает? Просто необходимо потом делать селекты с условием prewhere date between .... В этом случае необходимо добавить Date в начало кортежа с первичным ключом или все так же в конце?

если у вас есть запрос id = 42 and date between date1 and date2, и при этом партиционирование по месяцам и сортировка по id, date, то данные по диапазону дат окажутся (в каждой партиции) одним куском, а если сортировка по date, id, то данные по каждому дню будут в своем куске, т.е. менее локальны.

при других запросах и других данных могут лучше работать другие варианты.

В обоих случаях будет ошибка и останется предыдущая версия данных в словаре.

Благодарю. Осталось отловить ошибку.

партиционирование по суткам, поэтому думаю можно его вообще убрать

Вопрос по регекспам. Читаю https://clickhouse.yandex/docs/ru/functions/string_replace_functions/#replaceregexponehaystack-pattern-replacement Делаю и получаю: SELECT replaceRegexpOne('voip.in.123.answered', '(\\d{3})', '\\1') AS num ┌─num──────────────────┐ │ voip.in.123.answered │ └──────────────────────┘

Это только у меня так? Или требуется как-то обозначить, что регексп может быть не в начале строки?

Просто в документации никак не отражено, что регекспы требуют совпадения всей строки.

Так тут получилось, что вы заматчились на число и его же вставили

Э... И каким образом тут строка с буквами заматчилась на число?

а d3 разве не число ?

Тут регексп не сработал и не заменил. Правильный регексп тут .*(\\d{3}).*

SELECT replaceRegexpOne('voip.in.123.answered', '(\\d{3})', 'abc') AS num ┌─num──────────────────┐ │ voip.in.abc.answered │ └──────────────────────┘

регэксп сработал

он вырезать хочет

ну пусть там пустую строку оставит )

Не-не-не! Хочу получить из строки цифрами только цифры.

Но вообще - понятно.

Правда, не из документации.

SELECT extract('voip.in.123.answered', '\\d{3}') AS num ┌─num─┐ │ 123 │ └─────┘

Впрочем, мне, видимо, больше подойдёт extract, а не replace

У меня вопрос по использованию индексов. Есть таблица с движком merge tree, каждый день в нее льется порядка миллиарда записей. Есть строковый столбец, выглядящий примерно так: a.b.c.d.{*id*}.e, где в качестве id может быть разношорстная информация, а сам id может располагаться в разных частях строки, но всегда обрамлён и его можно без проблем выкинуть регуляркой. А a.b.c.d. определяют класс принадлежности значений. Обычно субд не используют индексы, если в левой части условия столбец из индекса каким либо способом преобразуется. Но кх то необычный :) Поэтому я решил попробовать добавить в индекс столбец с регекспом, который выбросит из него все айдишики (как-то так MergeTree(date_column, (date_column, replaceRegexpAll(str_column, *regexp*, '')))). Ну и в дальнейшем в условиях запроса указывать этот регексп + конкретное условие с id. Некоторый отчёт по этой таблице за сутки рассчитывается за ~30-40 минут. После добавления индекса с регэкспом он стал выполняться за 10-20 секунд. Похоже, что индекс таки используется, несмотря на то, что в условии запроса к нему применяется регексп. Ну и собственно вопрос: насколько адекватен такой подход? Какие могут быть подводные камни? P.S. да, разумно было бы хранить класс где-нибудь рядом, и положить в индекс его, но представим, что мы не можем на это повлиять (:

У меня вопрос по использованию индексов. Есть таблица с движком merge tree, каждый день в нее льется порядка миллиарда записей. Есть строковый столбец, выглядящий примерно так: a.b.c.d.{*id*}.e, где в качестве id может быть разношорстная информация, а сам id может располагаться в разных частях строки, но всегда обрамлён и его можно без проблем выкинуть регуляркой. А a.b.c.d. определяют класс принадлежности значений. Обычно субд не используют индексы, если в левой части условия столбец из индекса каким либо способом преобразуется. Но кх то необычный :) Поэтому я решил попробовать добавить в индекс столбец с регекспом, который выбросит из него все айдишики (как-то так MergeTree(date_column, (date_column, replaceRegexpAll(str_column, *regexp*, '')))). Ну и в дальнейшем в условиях запроса указывать этот регексп + конкретное условие с id. Некоторый отчёт по этой таблице за сутки рассчитывается за ~30-40 минут. После добавления индекса с регэкспом он стал выполняться за 10-20 секунд. Похоже, что индекс таки используется, несмотря на то, что в условии запроса к нему применяется регексп. Ну и собственно вопрос: насколько адекватен такой подход? Какие могут быть подводные камни? P.S. да, разумно было бы хранить класс где-нибудь рядом, и положить в индекс его, но представим, что мы не можем на это повлиять (:

O_o

так регэкспы совпадают в запросе и индексе или нет?

а сделать вычисляемую колонку (materialized) и ее проиндексировать? заодно тип со String на UInt64 поменять?

что-то вроде valueclass UInt64 default replaceRegexpAll(str_column, *regexp*, ''),

так регэкспы совпадают в запросе и индексе или нет?

да, совпадают

хз, сработает или нет

да, совпадают

тогда всё логично

а сделать вычисляемую колонку (materialized) и ее проиндексировать? заодно тип со String на UInt64 поменять?

а можно делать индекс по materialized колонке? она ж на лету вроде считается всегда?

на лету alias считается.

на лету alias считается.

хм, ну если хранится, то индекс по ней будет более подходящим решением. Спасибо :)

Меня раздирают противоречия "В таблице типа MergeTree обязательно должен быть отдельный столбец, содержащий дату, здесь это столбец EventDate. Тип столбца с датой — обязательно Date (а не DateTime)." - у меня в любом случае есть колонка DateTime, получается мне этот столбец надо дублировать а потом еще и в WHERE указывать (у меня запрос по диапазону DateTime)... Никак низя чтобы оно "само" без лишних ухищрений?

date_column Date DEFAULT toDate(dateTime_column). А в WHERE все-таки придется указать

Меня раздирают противоречия "В таблице типа MergeTree обязательно должен быть отдельный столбец, содержащий дату, здесь это столбец EventDate. Тип столбца с датой — обязательно Date (а не DateTime)." - у меня в любом случае есть колонка DateTime, получается мне этот столбец надо дублировать а потом еще и в WHERE указывать (у меня запрос по диапазону DateTime)... Никак низя чтобы оно "само" без лишних ухищрений?

После введения кастомового партиционирования - поле типа Date в принципе не обязательно. Но если у вас данные имеют какой-то таймстамп - наличие колонки типа Date очень сильно поможет для партиционирования и для выборки данных за определенный диапазон дат.

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

а никак не планируется в будущих версиях КХ пофиксить чтобы можно было вместо чистого date указывать datetime чтобы оно "само" внутри toDate при партиционировании делала и при запросах сама в where "дублировала" ограничения наложенные на datetime?

А зачем? Так же быстрее.

еще очень унизительно - нужно буквально пяток "нормальных" табличек небольших и ненагруженных - настроечки там хранить, простейшие справочники итп ради этого мускул рядом подымать... прикрутили бы какой-нить engine=SqlLite()

А зачем? Так же быстрее.

кому быстрее? движок может сам все это сделать и производительность будет идентичная зачем повторять два раза то? Если ему нужно поле типа date пусть создаст невидимое для меня поле и извлекает в него дату из datetime. А при поиске если видит константные ограничения на datetime пусть время отбросит и сам к date применит. зачем мне это дублировать то?

Разработчик всего одну строчку добавит и всё будет работать. А невидимо городить - можно сделать лишнюю работу или не сделать нужную.

кому быстрее? движок может сам все это сделать и производительность будет идентичная зачем повторять два раза то? Если ему нужно поле типа date пусть создаст невидимое для меня поле и извлекает в него дату из datetime. А при поиске если видит константные ограничения на datetime пусть время отбросит и сам к date применит. зачем мне это дублировать то?

Я думаю, что может быть с кастомным партиционированием так можно сделать. Т.е. завести primary key на DateTime и партиционирование по toYYYYMM(time) и оно будет работать. Но лучше проверить, конечно.

Просто зачастую Date добавляют именно в primary key и тогда она становится нужна. Пример, как у Яндекс.Метрики: (CounterID, Date, cityHash64(userID)) — и по последнему полю сэмплирование

Я думаю, что может быть с кастомным партиционированием так можно сделать. Т.е. завести primary key на DateTime и партиционирование по toYYYYMM(time) и оно будет работать. Но лучше проверить, конечно.

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

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

Ну так я и предлагаю эту date создавать автоматом из datetime чтобы корректно работало

Ну так я и предлагаю эту date создавать автоматом из datetime чтобы корректно работало

Создайте :) Помочь вам написать CREATE TABLE? :)

Я думаю, что может быть с кастомным партиционированием так можно сделать. Т.е. завести primary key на DateTime и партиционирование по toYYYYMM(time) и оно будет работать. Но лучше проверить, конечно.

Вам лучше Date Materialized toDate(datetime)

Создайте :) Помочь вам написать CREATE TABLE? :)

EventDate materialized as toDate(EventDateTime) то я смогу ;) вот только в WHERE писать EventDateTime>=toDateTime(...) AND EventDateTime<=toDateTime(...) AND EventDate>=toDate(toDateTime(...)) AND EventDate<=toDate(toDateTime(...)) - вторая часть унизительна

а сделать вычисляемую колонку (materialized) и ее проиндексировать? заодно тип со String на UInt64 поменять?

Чего-то не прокатило. Спустя пару десятков инсертов начало падать не очень информативное Code: 44, e.displayText() = DB::Exception: Cannot insert column str_column_mask, e.what() = DB::Exception. Этот str_column_mask materialized колонка над str_column. В инсерте ее не указано.

Запись через буффер. Может буффер не учитывает, что в родительской таблице есть materialized колонка и явно перечисляет все при вставке?

Уважаемые разработчики, а вот скажите x between 10 and 20 это для движка (не логически а именно для движка) тождественно x>=10 and x<=20? Если x проиндексирован никаких хитростей не применяется? Вообще поиск по вхождению в диапазон можно представить на поиск пересечения точки с отрезком - для этого есть очень быстрые spartial-индексы. КХ их часом не поддерживает?

Уважаемые разработчики, а вот скажите x between 10 and 20 это для движка (не логически а именно для движка) тождественно x>=10 and x<=20? Если x проиндексирован никаких хитростей не применяется? Вообще поиск по вхождению в диапазон можно представить на поиск пересечения точки с отрезком - для этого есть очень быстрые spartial-индексы. КХ их часом не поддерживает?

between при парсинге разворачивается в >= and <=, на этом при желании можно например экспоненциальную длину ast получить.

between при парсинге разворачивается в >= and <=, на этом при желании можно например экспоненциальную длину ast получить.

понятно т.е. это именно синтаксический сахар.

select ((1 between 2 and 3) between 4 and 5) between 6 and 7

понятно т.е. это именно синтаксический сахар.

да. что касается оптимизации попадания в отрезок, обычно у вас один отрезок (запрос) и много точек (строк), два неравенства и без индекса вроде ок.

select ((1 between 2 and 3) between 4 and 5) between 6 and 7

жесть... но вторая часть вопроса была об использовании геометрических индексов для ускорения поиска в диапазоне значений. Особенно при обратном поиске: where 10 between column1 and column2

чего-то специального, думаю, нет.

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

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

Держать словари на диске средствами ClickHouse нет возможности. Можно частично кэшировать из внешнего источника - см. тип словаря cache.

Опубликованы материалы с митапа в Берлине: http://yandex.github.io/clickhouse-presentations/meetup16/introduction.pdf http://yandex.github.io/clickhouse-presentations/meetup16/spotify.pdf http://yandex.github.io/clickhouse-presentations/meetup16/internals.pdf

Это читал, думал есть какая хитрость. Спасибо за ответ.

@milovidov_an а вы там не с heinlein в Берлине делали этот митап?

@milovidov_an а вы там не с heinlein в Берлине делали этот митап?

Нет - с DeliveryHero.

У нас началось согласование митапа в Спб. Предположительное время - середина августа.

подскажите, куда сунуть background_pool_size ?

сунул в конфиг в виде xml, рестартанул, не схавало

<background_pool_size>8</background_pool_size>

а то всё очень плохо, упал в out of memory

В users.xml, профиль default. https://www.google.com/search?source=hp&q=background_pool_size+clickhouse

всё равно SELECT * FROM system.settings WHERE name = 'background_pool_size' 16

получилось, спасибо

в acl совал

жесть... но вторая часть вопроса была об использовании геометрических индексов для ускорения поиска в диапазоне значений. Особенно при обратном поиске: where 10 between column1 and column2

так если у вас индекс (column1,column2), то он достаточно быстро найти должен

Пишем в Clickhouse маленькие пачки событий, по 1000-2000 строк (плюс мат вью, которые их копируют). Но в течении суток отмечаем, что несколько событий в базу не попадает (из десятков миллионов). Может ли бытьпричина где то в Clickhouse? Куда можно копнуть? Непонятных ошибок в логах нет. Используется кворумная запись. Скорее всего причина всё таки не в Clickhouse, но хочется как-то проверить и его.

Именно несколько, а не 1000..2000 строк?

а тип таблицы какой? не collapsing какой-нибудь?

Обычный ReplicatedMergeTree. Именно несколько, причем интервалы между ниим бывают 30-40 строк.

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

Пишем в Clickhouse маленькие пачки событий, по 1000-2000 строк (плюс мат вью, которые их копируют). Но в течении суток отмечаем, что несколько событий в базу не попадает (из десятков миллионов). Может ли бытьпричина где то в Clickhouse? Куда можно копнуть? Непонятных ошибок в логах нет. Используется кворумная запись. Скорее всего причина всё таки не в Clickhouse, но хочется как-то проверить и его.

Вряд ли кликхаус. Там в реплицируемых таблицах идентичные блоки выкидываются (но вы говорите что это не ваш случай), если какие-то проблемы с форматом входных данных (например плохой JSON) и включенаа толеранция ошибок - то несколько строк могут пропасть. Ну и если используете движок типа Replacing / Collapsing. Если тем не менее подозреваете кликхаус - то можете например включить query_log и при каждом инсерте записывать количество отправленных в кликхаус строк в какое-нибудь внешнее хранилище (да хоть в логфайл, таймстамп и кол-во отправленных строк). Потом можете сравнить что было выслано, с тем что кликхаус получил согласно query_log.

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

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

так что мне этот случай интересен

Вряд ли кликхаус. Там в реплицируемых таблицах идентичные блоки выкидываются (но вы говорите что это не ваш случай), если какие-то проблемы с форматом входных данных (например плохой JSON) и включенаа толеранция ошибок - то несколько строк могут пропасть. Ну и если используете движок типа Replacing / Collapsing. Если тем не менее подозреваете кликхаус - то можете например включить query_log и при каждом инсерте записывать количество отправленных в кликхаус строк в какое-нибудь внешнее хранилище (да хоть в логфайл, таймстамп и кол-во отправленных строк). Потом можете сравнить что было выслано, с тем что кликхаус получил согласно query_log.

Ага, спасибо! Наметил пути. "включенаа толеранция ошибок" - каким образом это делается? Не гуглится что-то.

Точно знаю что кликхаус "на замечает" разрыва соединения если выполняет большой селект. Селект выполнится до конца, даже если результат уже никому не нужен. См. https://github.com/yandex/ClickHouse/issues/1403

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

Мы вот например пытаемся :) Теоретически да, при соблюдении ряда условий: реплицировать, использовать кворумную запись, использовать sequential select (пока что нельзя, т.к. баги)

Ага, спасибо! Наметил пути. "включенаа толеранция ошибок" - каким образом это делается? Не гуглится что-то.

input_format_allow_errors_num / input_format_allow_errors_ratio https://github.com/yandex/ClickHouse/blob/7fcf609812325d0addb5b00da8ce19a39870be4e/dbms/src/Interpreters/Settings.h#L168

При этом sequential select уже относится только к "чистому" чтению, а не к хранению.

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

Кликхаус - инструмент для аналитики, в аналитике важны тенденции и обобщения, тренды, а не конкретные единичные события. Кликхаус не соответствует требованиям ACID - хотя бы по причине отсутствия транзакций. Если вам нужно выполнять аналитику на каких-то очень важных данных, то просто копируйте это данные из вашей любимой базы соответствующей требованиям ACID в кликхаус.

В принципе КХ довольно прост и при определенной ловкости обращения с ним можно считать что всё надежно. Тем не менее как главную БД например для финансовых организаций я бы советовал выбрать что-нибудь другое :)

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