Телеграмм чат группы clickhouse

17:23пожаловаться #1

AK

ничего не понял, но по идее order by pk desc/asc должен быть моментальным.

>Но тут хочу понять, можно ли на КХ в дополнение повесить OLTP нагрузку по подобным запросам, которые ложатся на primary key.

нельзя если QPS > 100. в КХ оверхед высокий. Лучше батчить запросы.

Сбатчевать то сможем на клиенте. Или написать батчующий прокси. Но не сильно понятно, как подобные запросы описать батчем.

Есть список таймстампов, и надо для каждого топ N строк перед этим таймстампом выбрать.

На ум приходит только
Select...
Union all
Select...
Union all
И так 100 раз

17:25пожаловаться #2

D

Сбатчевать то сможем на клиенте. Или написать батчующий прокси. Но не сильно понятно, как подобные запросы описать батчем.

Есть список таймстампов, и надо для каждого топ N строк перед этим таймстампом выбрать.

На ум приходит только
Select...
Union all
Select...
Union all
И так 100 раз

select * from table where myKey IN(2,3,4,100500,9000)

17:26пожаловаться #3

AK

select * from table where myKey IN(2,3,4,100500,9000)

Не, мне же надо не четкое вхождение, а "последние N записей перед X"

17:27пожаловаться #4

D

Не, мне же надо не четкое вхождение, а "последние N записей перед X"

тоже можно если уверены что условно куда-то войдет минимум Н записей

select magicArrayLambdas from (
select * from where
(timestamp between a and b) or
(timestamp between a and b) or
(timestamp between a and b) or
(timestamp between a and b) or
(timestamp between a and b)
)

17:28пожаловаться #5

D

union all в самом крайнем случае тоже ок

17:28пожаловаться #6

AK

тоже можно если уверены что условно куда-то войдет минимум Н записей

select magicArrayLambdas from (
select * from where
(timestamp between a and b) or
(timestamp between a and b) or
(timestamp between a and b) or
(timestamp between a and b) or
(timestamp between a and b)
)

Так такой синтаксис гору данных поднимет. А мне, по сути, нужен asof join, но через primary key

17:30пожаловаться #7

AK

union all в самом крайнем случае тоже ок

Попробовал. Почти линейно растёт время

Denny Crane [not a Y... in ClickHouse не тормозит

17:31пожаловаться #8

DC

Так такой синтаксис гору данных поднимет. А мне, по сути, нужен asof join, но через primary key

т.е. для большого кол-ва широких записей надо найти предыдущую? тут кх плохо подходит, индекс разреженный

17:36пожаловаться #9

AK

Denny Crane [not a Yandex bot]

т.е. для большого кол-ва широких записей надо найти предыдущую? тут кх плохо подходит, индекс разреженный

Там не btree?

17:36пожаловаться #10

D

Там не btree?

нет

Denny Crane [not a Y... in ClickHouse не тормозит

17:37пожаловаться #11

DC

Там не btree?

нет, и в индексе только 1 из 8192 записей, поэтому читаются лишние строки из таблицы

что будет если

prewhere Timestamp >= '2020-07-11 10:00:00' and Timestamp < '2020-07-12 10:00:00'

17:38пожаловаться #12

D

Попробовал. Почти линейно растёт время

сделайте ДДЛ и скрипт заливки рендом данных... так бесполезно пытаться

17:38пожаловаться #13

D

Так такой синтаксис гору данных поднимет. А мне, по сути, нужен asof join, но через primary key

конституция КХ. статья 1.
лучше один раз гору данных поднять, чем насиловать КХ по 100 раз.

17:39пожаловаться #14

AK

сделайте ДДЛ и скрипт заливки рендом данных... так бесполезно пытаться

Там реальных 37 млрд строк лежит) Зачем рендом?

17:39пожаловаться #15

D

Так такой синтаксис гору данных поднимет. А мне, по сути, нужен asof join, но через primary key

"Запомни: лучше день потерять, потом за пять минут долететь. "

17:39пожаловаться #16

D

Там реальных 37 млрд строк лежит) Зачем рендом?

блин, это если вам помощь нужна с запросом, а так, удачи )

17:39пожаловаться #17

AK

Denny Crane [not a Yandex bot]

нет, и в индексе только 1 из 8192 записей, поэтому читаются лишние строки из таблицы

что будет если

prewhere Timestamp >= '2020-07-11 10:00:00' and Timestamp < '2020-07-12 10:00:00'

Чуть-чуть улучшилось. Вместо 900 с хвостиком МБ в память 853 поднимается. Время и строки не поменялись

17:41пожаловаться #18

AK

Denny Crane [not a Yandex bot]

нет, и в индексе только 1 из 8192 записей, поэтому читаются лишние строки из таблицы

что будет если

prewhere Timestamp >= '2020-07-11 10:00:00' and Timestamp < '2020-07-12 10:00:00'

Есть минусы кроме роста объёма в RAM от уменьшения гранул?

17:42пожаловаться #19

D

Есть минусы кроме роста объёма в RAM от уменьшения гранул?

тормоза ещё... при планировании запроса... заметные