
Denis
05.07.2018
13:06:49
В обоих случаях будет ошибка и останется предыдущая версия данных в словаре.

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

Wolf
05.07.2018
13:14:13
по дате оно и так у вас будет отсортировано, поэтому дату ставят в конец

Yuran
05.07.2018
13:14:19

Google

Yaroslav
05.07.2018
13:14:42
спасибо

Yuran
05.07.2018
13:14:52
Но если нужно делать выборки по сильно меньшему диапазону, чем партиционирование, то тогда первым, конечно
Но всё зависит от ваших данных

papa
05.07.2018
13:17:03
Всем привет! Заметил в доках, что в ReplicatedMergeTree, если указан ключ партиционирования Date, то в первичном ключе его указывают последним. Как это работает? Просто необходимо потом делать селекты с условием prewhere date between .... В этом случае необходимо добавить Date в начало кортежа с первичным ключом или все так же в конце?
если у вас есть запрос id = 42 and date between date1 and date2, и при этом партиционирование по месяцам и сортировка по id, date, то данные по диапазону дат окажутся (в каждой партиции) одним куском, а если сортировка по date, id, то данные по каждому дню будут в своем куске, т.е. менее локальны.
при других запросах и других данных могут лучше работать другие варианты.

Stanislav
05.07.2018
13:18:20

Yaroslav
05.07.2018
13:18:23
партиционирование по суткам, поэтому думаю можно его вообще убрать

Stanislav
05.07.2018
13:35:49
Вопрос по регекспам. Читаю 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 │
└──────────────────────┘
Это только у меня так? Или требуется как-то обозначить, что регексп может быть не в начале строки?
Просто в документации никак не отражено, что регекспы требуют совпадения всей строки.

Alex
05.07.2018
13:39:06
Так тут получилось, что вы заматчились на число и его же вставили

Stanislav
05.07.2018
13:39:38
Э... И каким образом тут строка с буквами заматчилась на число?

Wolf
05.07.2018
13:39:54
а d3 разве не число ?

Google

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

Alex
05.07.2018
13:40:44
SELECT replaceRegexpOne('voip.in.123.answered', '(\\d{3})', 'abc') AS num
┌─num──────────────────┐
│ voip.in.abc.answered │
└──────────────────────┘
регэксп сработал

Denis
05.07.2018
13:41:16
он вырезать хочет

Wolf
05.07.2018
13:41:35
ну пусть там пустую строку оставит )

Stanislav
05.07.2018
13:41:58
Не-не-не! Хочу получить из строки цифрами только цифры.
Но вообще - понятно.
Правда, не из документации.

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

Stanislav
05.07.2018
13:43:00
Впрочем, мне, видимо, больше подойдёт extract, а не replace


Alex
05.07.2018
14:19:41
У меня вопрос по использованию индексов.
Есть таблица с движком 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. да, разумно было бы хранить класс где-нибудь рядом, и положить в индекс его, но представим, что мы не можем на это повлиять (:


Andrey
05.07.2018
14:24:39
У меня вопрос по использованию индексов.
Есть таблица с движком 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


Denis
05.07.2018
14:27:29
так регэкспы совпадают в запросе и индексе или нет?

Дмитрий
05.07.2018
14:37:41
а сделать вычисляемую колонку (materialized) и ее проиндексировать? заодно тип со String на UInt64 поменять?

Denis
05.07.2018
14:42:25
что-то вроде
valueclass UInt64 default replaceRegexpAll(str_column, *regexp*, ''),

Alex
05.07.2018
14:42:45

Denis
05.07.2018
14:42:46
хз, сработает или нет

Alex
05.07.2018
14:43:25

Дмитрий
05.07.2018
14:43:51
на лету alias считается.

Google

Alex
05.07.2018
14:48:22

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

Дмитрий
05.07.2018
15:11:41
date_column Date DEFAULT toDate(dateTime_column). А в WHERE все-таки придется указать

Michal
05.07.2018
15:35:42
Даже при том что они будут дублировать "полный" таймстамп.


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

Denis
05.07.2018
15:50:03
А зачем? Так же быстрее.

Дмитрий
05.07.2018
15:50:20
еще очень унизительно - нужно буквально пяток "нормальных" табличек небольших и ненагруженных - настроечки там хранить, простейшие справочники итп ради этого мускул рядом подымать... прикрутили бы какой-нить engine=SqlLite()
А зачем? Так же быстрее.
кому быстрее? движок может сам все это сделать и производительность будет идентичная зачем повторять два раза то? Если ему нужно поле типа date пусть создаст невидимое для меня поле и извлекает в него дату из datetime. А при поиске если видит константные ограничения на datetime пусть время отбросит и сам к date применит. зачем мне это дублировать то?

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

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

Michal
05.07.2018
16:00:12

Дмитрий
05.07.2018
16:08:00

Michal
05.07.2018
16:08:41

Vladimir
05.07.2018
16:10:32

Дмитрий
05.07.2018
16:11:17
Создайте :) Помочь вам написать CREATE TABLE? :)
EventDate materialized as toDate(EventDateTime) то я смогу ;) вот только в WHERE писать EventDateTime>=toDateTime(...) AND EventDateTime<=toDateTime(...) AND EventDate>=toDate(toDateTime(...)) AND EventDate<=toDate(toDateTime(...)) - вторая часть унизительна

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

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

Google

papa
05.07.2018
16:25:33

Дмитрий
05.07.2018
16:26:35

papa
05.07.2018
16:26:56
select ((1 between 2 and 3) between 4 and 5) between 6 and 7

Дмитрий
05.07.2018
16:30:48

papa
05.07.2018
16:35:06
чего-то специального, думаю, нет.

antuan
05.07.2018
17:15:37
подскажите, а словари можно только в памяти хранить, нельзя ли заставить кх держать данные для словаря на диске?

Alexey
05.07.2018
17:30:36
Опубликованы материалы с митапа в Берлине:
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

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

Vsevolod
05.07.2018
19:52:30
@milovidov_an а вы там не с heinlein в Берлине делали этот митап?

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

Egor
05.07.2018
20:04:31
подскажите, куда сунуть background_pool_size ?
сунул в конфиг в виде xml, рестартанул, не схавало
<background_pool_size>8</background_pool_size>
а то всё очень плохо, упал в out of memory

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

Egor
05.07.2018
20:07:19
всё равно SELECT *
FROM system.settings
WHERE name = 'background_pool_size'
16
получилось, спасибо

Google

Egor
05.07.2018
20:08:23
в acl совал

Denis
06.07.2018
05:50:47

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

Sergey
06.07.2018
06:07:41
Именно несколько, а не 1000..2000 строк?

Denis
06.07.2018
06:08:29
а тип таблицы какой? не collapsing какой-нибудь?

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

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

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


Denis
06.07.2018
07:33:30
вот, кстати, хотел похожий вопрос задать, но более теоретический - можно ли в кх хранить важные данные, которые нельзя терять?
так что мне этот случай интересен

Vasilij
06.07.2018
07:34:41


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

Vasilij
06.07.2018
07:36:25

Michal
06.07.2018
07:36:37

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

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

Denis
06.07.2018
08:03:14
идея была в том, чтобы сделать больше на тех же ресурсах.