Ip_trie словарь со списком всех интернет сетей и автономок, connection_log на несколько миллиардов строк, и запрос с группировкой и сортировкой по номеру автономки отрабатывает за разумное количество секунд.

ммм, а вот например запихнуть туда пачку ip и получить соответствие ip<->подсеть? это можно как-то сделать через, условно говоря, where IP IN (ip_trie_clause)

ммм, а вот например запихнуть туда пачку ip и получить соответствие ip<->подсеть? это можно как-то сделать через, условно говоря, where IP IN (ip_trie_clause)

т.е. без цикла по запихиваю одного айпи пачками (извините если вопрос совсем страшный)

Извините что туплю

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

SELECT sum(value) FROM Metrics SAMPLE 1 / 10 ┌───────────sum(value)─┐ │ 17577274172239137000 │ └──────────────────────┘ 1 rows in set. Elapsed: 9.238 sec. Processed 3.69 billion rows, 44.23 GB (398.96 million rows/s., 4.79 GB/s.) tsf-data11.us.sematext.com :) select sum(value) from Metrics; SELECT sum(value) FROM Metrics ┌───────────sum(value)─┐ │ 17577889402538699000 │ └──────────────────────┘ 1 rows in set. Elapsed: 7.030 sec. Processed 3.69 billion rows, 29.48 GB (524.30 million rows/s., 4.19 GB/s.) tsf-data11.us.sematext.com :) select sum(value) from Metrics SAMPLE 1/100; SELECT sum(value) FROM Metrics SAMPLE 1 / 100 ┌───────────sum(value)─┐ │ 17578875733901701000 │ └──────────────────────┘ 1 rows in set. Elapsed: 9.241 sec. Processed 3.69 billion rows, 44.23 GB (398.87 million rows/s., 4.79 GB/s.) tsf-data11.us.sematext.com :) show create Metrics SHOW CREATE TABLE Metrics ┌─statement───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┐ │ CREATE ... ORDER BY (appId, metricId, timestamp) SAMPLE BY metricId SETTINGS index_granularity = 8192 └─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┘ 1 rows in set. Elapsed: 0.001 sec.

Судя по сумме семплирования не происходит

а metricId у вас равномерно распределен по значениям своего типа?

ммм, а вот например запихнуть туда пачку ip и получить соответствие ip<->подсеть? это можно как-то сделать через, условно говоря, where IP IN (ip_trie_clause)

Не понимаю вопрос. ip_trie ищет подсеть с самым длинным подходящим префиком.

Т.е. в ip_trie может быть несколько подходящих под условие подсетей. Типа 10.0.0.0/8 и одновременно 10.1.2.0/23 . И если спросите про адрес 10.1.2.3 то выберет вторую подсеть, как более "специфичную" хотя первая тоже подходит.

Круто, спасибо :) Ещё бы tag добавили в hub.docker.com, а то там только в latest и 1.1 залили новую stable

https://github.com/yandex/ClickHouse/issues/2576#issuecomment-401773171 И спасибо, @ztlpn :)

Т.е. в ip_trie может быть несколько подходящих под условие подсетей. Типа 10.0.0.0/8 и одновременно 10.1.2.0/23 . И если спросите про адрес 10.1.2.3 то выберет вторую подсеть, как более "специфичную" хотя первая тоже подходит.

Спасибо) может быть попозже еще спрошу если протуплю

День добрый! Можно ли для клика использовать zookeeper с kerberos? Если да, то где прочитать о настройке?

господа, а как truncate table сделать?

господа, а как truncate table сделать?

truncate по партишенам

сорян ...drop partition

мне целиком табличку почистить

Если туда не пишется ничего - подропать все партишны и всё

а metricId у вас равномерно распределен по значениям своего типа?

не совсем понял вопроса это поле имеет значение от 1 до 10000 и распределение не совсем равномерное Ну тоесть значении 2 может быть миллион а 2002 может быть 20 миллионов

sample 1/100 эквивалентно условию metricId < max_value/100

теперь понял

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

Привет! Используется кворумная запись, для чтения стоит по дефолту select_sequential_consistency=1. После перехода на следующий месяц (партиционирование таблицы по месяцам), предыдущий перестал попадать в результаты селекта (но никаких ошибок не кидает). Ставим select_sequential_consistency=0 - данные видны. Запись идет нормально. Это баг или мы что-то неверно настроили?

Это баг.

судя по запросам семплинг вообще не работет

max_value это не 10000, а 2^32 или какой у вас тип у metricId

упс

это все поменяло

в таких случаях можно семплировать например по inthash32(.)

и как быть если надо аггрегировать по метрикИд но значении может быть так много что нужно только по 10% например

но нужно чтобы на один appId было много metricId

так и есть

в таких случаях можно семплировать например по inthash32(.)

это как?

это при создании таблицы

как эту част переписать?

ORDER BY (appId, metricId, timestamp) SAMPLE BY (metricId);

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

вместо metricId

inthash32(metricId) ?

угу

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

и это же выражение в первичном ключе?

угу, если не отсортировать, то фокус не получится.

а условие metricId=xxx будет при таком ключе по ключу отрабатывать? ORDER BY (appId, inthash32(metricId), timestamp) SAMPLE BY (inthash32(metricId));

а условие metricId=xxx будет при таком ключе по ключу отрабатывать? ORDER BY (appId, inthash32(metricId), timestamp) SAMPLE BY (inthash32(metricId));

Скорее inthash32(metricId)=inthash32(xxx)

или в запросе надо будет писать inthash32(metricId)=xxx ?

уфф, красота будет

предположу что нет. но metricId=xxx and intHash32(metricId)=intHash32(xxx) должно.

понял спсб

спсб большое

sample 1/100 эквивалентно условию metricId < max_value/100

уфф только что понял что мне это не подходит У меня в запросе есть условие *metricId=2* например и мне надо чтобы сумма была построена не по всем точкам а только по 10% например Получается мне семплирование по таймстемпу надо но это вроде бы не есть гуд

Всем привет! А где почитать про ORDER BY и как его лучше указывать? Вот допустим у нас есть Immutable Event Log по userId с eventType и eventId, а так же timestamp (DateTime). Мы используем ReplacingMergeTree (на случай если два раза одно и тоже событие запишется в ClickHouse), на данный момент вот так: ENGINE = ReplacingMergeTree PARTITION BY toYYYYMM(timestamp) ORDER BY (userId, eventType, eventId) на сколько это правильно \ нет? ORDER BY очень сбивает с толку названием, я так понимаю он тут больше как кассандровский PRIMARY KEY, не?

Всем привет! А где почитать про ORDER BY и как его лучше указывать? Вот допустим у нас есть Immutable Event Log по userId с eventType и eventId, а так же timestamp (DateTime). Мы используем ReplacingMergeTree (на случай если два раза одно и тоже событие запишется в ClickHouse), на данный момент вот так: ENGINE = ReplacingMergeTree PARTITION BY toYYYYMM(timestamp) ORDER BY (userId, eventType, eventId) на сколько это правильно \ нет? ORDER BY очень сбивает с толку названием, я так понимаю он тут больше как кассандровский PRIMARY KEY, не?

зависит от того как вы потом будете все это читать.

зависит от того как вы потом будете все это читать.

Планируем отдать на Business Analytics

и создавать materialized views

в основном ad hoc запросы в стиле "а сколько у нас юзеров <...>"

юзеров - это userid?

Угу

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

т.е. только по eventId?

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

может вам так и надо.

А вынесение event_id в PKEY не сожрёт всю память?

А вынесение event_id в PKEY не сожрёт всю память?

не совсем тогда ясно как обеспечить replacing поведение

не должно, это же разреженный индекс.

Я конечно извиняюсь за повторение вопроса, но до конца понять так и не удалось ? ORDER BY - это Cassandra/Dynamo-like PKEY, по которому так же происходит merge, верно?

ORDER BY - колонки или список колонок, по которым в MergeTree (первичный ключ): - данные всей таблицы упорядочены - создан разреженый индекс - в "слопывающихся" движках данные слопываются по этому ключу

Сформулирую полный вопрос с вашего позволения. Есть CREATE TABLE XXX ... ORDER BY (appId, metricId, timestamp) SAMPLE BY (metricId); Есть запросы вида SELECT SUM(v) FROM XXX where appId=1 and metricId=1 and timestamp>YYY and timestamp<ZZZ; Для некого metricId данных может быть очень много и запрос выполняется долго. Думали прикрутить семплинг для этого SELECT SUM(v) FROM XXX SAMPLE 1/10 where appId=1 and metricId=1 and timestamp>YYY and timestamp<ZZZ Но похоже все работет не так как думалось Нужно заводить искусственную переменную sampleId значения которой равномерно будут распределены от 0 до 9 И делать так CREATE TABLE XXX ... ORDER BY (appId, metricId, sampleId, timestamp) SAMPLE BY (sampleId); Но тогда запросы без семплирования будут работать медленнее ТК мы "запохабили" немного первичный ключ, верно? Есть какой-то способ ровнее?

а если помимо timestamp добавить в индекс день (day Date toDate(timestamp), и дополнительно в where также указывать day, быстрее не будет?

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

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

Вот с семплингом засада как-то после чтения документации по другому думалось оно работает, а сейччас вроде как пришло понимание а что делать непонятно

Кто то нибудь в курсе появились ли вложенные структуры, т.е вложенность более одного уровня ? Вроде обещали эту функциональность завести в первом квартале 2018 года

Кто то нибудь в курсе появились ли вложенные структуры, т.е вложенность более одного уровня ? Вроде обещали эту функциональность завести в первом квартале 2018 года

Кликхаус в курсе :) Лучше такие вещи у него спрашивать: CREATE TABLE xxx_nestes ( a UInt32, b Array(Array(Tuple(String, String))) ) ENGINE = Log Ok. 0 rows in set. Elapsed: 0.006 sec. :) insert into xxx_nestes values (1, [[('hello','world'),('foo','bar')],[('','')]] ); INSERT INTO xxx_nestes VALUES Ok.

Кликхаус в курсе :) Лучше такие вещи у него спрашивать: CREATE TABLE xxx_nestes ( a UInt32, b Array(Array(Tuple(String, String))) ) ENGINE = Log Ok. 0 rows in set. Elapsed: 0.006 sec. :) insert into xxx_nestes values (1, [[('hello','world'),('foo','bar')],[('','')]] ); INSERT INTO xxx_nestes VALUES Ok.

Я имел ввиду структуру Nested

Я у КХ уже спрашивал) не работало) но из роуд мапа это фича исчезла

Я имел ввиду структуру Nested

а чем массивы массивов не подходят?

Вот с семплингом засада как-то после чтения документации по другому думалось оно работает, а сейччас вроде как пришло понимание а что делать непонятно

А вы посмотрите на это с другой стороны: вот у вас есть черезчур много данных. На каком основании вы предпочли бы отбросить бОльшую их часть, так чтобы их качество не ухудшилось? На основании metricID явно бессмысленно, если вы хотите для конкретной метрики данные выбирать. Т.е. берем все записи для данного metricID и обрасываем из них такую часть для которой?..

а чем массивы массивов не подходят?

Многомерные массивы не придерживаются для таблиц типа mergetree

Я имел ввиду структуру Nested

Nested - это только syntax sugar для нескольких параллельных таблиц.

Многомерные массивы не придерживаются для таблиц типа mergetree

Извините, но кликхаус с вами не согласен :) : :) create table xxx_nestes2 ( a UInt32, b Array(Array(Tuple(String,String))) ) Engine = MergeTree ORDER BY a; CREATE TABLE xxx_nestes2 ( a UInt32, b Array(Array(Tuple(String, String))) ) ENGINE = MergeTree ORDER BY a Ok. 0 rows in set. Elapsed: 0.007 sec. :) insert into xxx_nestes2 values (1, [[('hello','world'),('foo','bar')],[('','')]] ); INSERT INTO xxx_nestes2 VALUES Ok. 1 rows in set. Elapsed: 0.002 sec.

Nested - это только syntax sugar для нескольких параллельных таблиц.

А что будет работать эффективнее, 2 таблицы с джоином или таблица с nested структурой)

Извините, но кликхаус с вами не согласен :) : :) create table xxx_nestes2 ( a UInt32, b Array(Array(Tuple(String,String))) ) Engine = MergeTree ORDER BY a; CREATE TABLE xxx_nestes2 ( a UInt32, b Array(Array(Tuple(String, String))) ) ENGINE = MergeTree ORDER BY a Ok. 0 rows in set. Elapsed: 0.007 sec. :) insert into xxx_nestes2 values (1, [[('hello','world'),('foo','bar')],[('','')]] ); INSERT INTO xxx_nestes2 VALUES Ok. 1 rows in set. Elapsed: 0.002 sec.

Это не мои слова, так в доке написано, видимо уже устарело)

А вы посмотрите на это с другой стороны: вот у вас есть черезчур много данных. На каком основании вы предпочли бы отбросить бОльшую их часть, так чтобы их качество не ухудшилось? На основании metricID явно бессмысленно, если вы хотите для конкретной метрики данные выбирать. Т.е. берем все записи для данного metricID и обрасываем из них такую часть для которой?..

Ну да, получется или rand()/10=0 использовать или sampleId добавлять Верно?

А что будет работать эффективнее, 2 таблицы с джоином или таблица с nested структурой)

Если данные всегда предполагается использовать совместно (т.е. те данные которые в нормальной форме были бы в правой таблице - сами по себе не используются, а только в сочетании с левой таблицей) - то по моим наблюдениям Nested / Array всегда быстрее.

Если данные всегда предполагается использовать совместно (т.е. те данные которые в нормальной форме были бы в правой таблице - сами по себе не используются, а только в сочетании с левой таблицей) - то по моим наблюдениям Nested / Array всегда быстрее.

Такая ситуация и складывается

Если данные всегда предполагается использовать совместно (т.е. те данные которые в нормальной форме были бы в правой таблице - сами по себе не используются, а только в сочетании с левой таблицей) - то по моим наблюдениям Nested / Array всегда быстрее.

А как можно осуществлять эффективный поиск по многомерным массивам ?

Если данные всегда предполагается использовать совместно (т.е. те данные которые в нормальной форме были бы в правой таблице - сами по себе не используются, а только в сочетании с левой таблицей) - то по моим наблюдениям Nested / Array всегда быстрее.

Допустим у меня есть древовидная структура, сессия -> хиты -> товары

Если данные всегда предполагается использовать совместно (т.е. те данные которые в нормальной форме были бы в правой таблице - сами по себе не используются, а только в сочетании с левой таблицей) - то по моим наблюдениям Nested / Array всегда быстрее.

В одной сессия несколько хитов, в одном хите несколько товаров

Ну да, получется или rand()/10=0 использовать или sampleId добавлять Верно?

Ну рандом всегда остается как запасной вариант, для него в принципе и SAMPLE BY не нужен (правда результаты будут недетерминированные если этот rand не хранить физически). Но часто например можно отсеять по какому-то иному признаку, например id пользователя.

timestamp%10=0 детерминированно будет, но что-то меня смущает скорости не даст, читать все равно все

Т.е. если пользователей много (или так МНОГО), то даже если половину их выбросить статистически картина меняется мало. А вот если выбросить случайную половину событий у случайных пользователей - то характерестики данных могут пострадать.

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

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

Тогда может проще всего выкинуть просто определенный интервал времени? Просто заузить день? Или от каждого часа взять по 10 мин?

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

допустим 100000 измерении в минуту и так 30 дней можно оставить 100 измерении в минуту но каждую минуту оставить

извините за двусмысленность