SC
А раз уж зашёл вопрос про AggregatingMergeTree. Расскажите, пожалуйста, в каком виде оно хранит данные? Потому что судя по документации КХ просто сохраняет промежуточные результаты агрегации, а заканчивает агрегацию уже во время запроса.
Size: a a a
2020 July 15
SC
Но я не совсем понимаю, что из себя представляют промежуточные результаты
l
Но я не совсем понимаю, что из себя представляют промежуточные результаты
в зависимости от агрегатной функции, для max это будет очевидно максимальное значение, для sum сумма, для uniqExact хештаблица
VM
Спасибо. Я обратила внимание на то, что у нас есть дубликаты, хотя по доке получается, что их не должно быть.
Вероятно, не было слияния в определенных партах.
Вероятно, не было слияния в определенных партах.
Как только все необходимые слияния пройдут, дублей не останется, некоторые используют поле timestamp, что бы понять, какая версия последняя. Rollup проаггрегирует более старые партиции и при уменьшении точнлсти освободит значительные объёмы диска
DC
А раз уж зашёл вопрос про AggregatingMergeTree. Расскажите, пожалуйста, в каком виде оно хранит данные? Потому что судя по документации КХ просто сохраняет промежуточные результаты агрегации, а заканчивает агрегацию уже во время запроса.
все движки КХ хранят парты.
парты сливаются во время мержей
вычисления делаются во время мержа, это просто побочный продукт мержа
т.е. вы вставляете два инсерта в summingMT
insert into summm values 1;
insert into summm values 1;
на диске два парта с 1, при слиянии будет суммирование , и в новый парт попадет 2
поэтому всегда нужно догруппировывать в select-х
парты сливаются во время мержей
вычисления делаются во время мержа, это просто побочный продукт мержа
т.е. вы вставляете два инсерта в summingMT
insert into summm values 1;
insert into summm values 1;
на диске два парта с 1, при слиянии будет суммирование , и в новый парт попадет 2
поэтому всегда нужно догруппировывать в select-х
SC
в зависимости от агрегатной функции, для max это будет очевидно максимальное значение, для sum сумма, для uniqExact хештаблица
Я так понимаю, имеет смысл AggregatingMergeTree в качестве вьюхи использовать тогда, когда данные поступают большим количеством пачек и вьюха MergeTree с group by не будет гарантировать правильную агрегацию?
l
Я так понимаю, имеет смысл AggregatingMergeTree в качестве вьюхи использовать тогда, когда данные поступают большим количеством пачек и вьюха MergeTree с group by не будет гарантировать правильную агрегацию?
смысл будет, когда у тебя допустим 100 строк из изначальной таблицы сожмутся в 1 стоку таблицы AggregatingMergeTree
DC
Я так понимаю, имеет смысл AggregatingMergeTree в качестве вьюхи использовать тогда, когда данные поступают большим количеством пачек и вьюха MergeTree с group by не будет гарантировать правильную агрегацию?
MV выполняет запрос над данными из insert-а, MV не читает таблицу
SC
MV выполняет запрос над данными из insert-а, MV не читает таблицу
Да, это я понял. Но пока не совсем понимаю преимущество MV на AggregatingMergeTree над MV на MergeTree с запросом group by
DC
Да, это я понял. Но пока не совсем понимаю преимущество MV на AggregatingMergeTree над MV на MergeTree с запросом group by
ну например вы аггрегируете в AggregatingMergeTree до суток, в сутки у вас делается 500тыщ инсертов, таким образом AggregatingMergeTree вам ужмет в 500тыщ. раз. Плюс MV работает с буфером, а не с инсертом даже. Поэтому даже один инсерт не схлопнут group by-ем.
SC
ну например вы аггрегируете в AggregatingMergeTree до суток, в сутки у вас делается 500тыщ инсертов, таким образом AggregatingMergeTree вам ужмет в 500тыщ. раз. Плюс MV работает с буфером, а не с инсертом даже. Поэтому даже один инсерт не схлопнут group by-ем.
Я немного сменю формулировку вопроса: в каком случае при создании MV лучше отдать предпочтение движку MergeTree, а в каком - AggregatingMergeTree. При условии, что мы будем аггрегировать данные. Допустим, mv будет выгляядеть так:
CREATE MATERIALIZED VIEW mv1
(
`timestamp` DateTime,
`requests_per_second` UInt64
)
ENGINE = MergeTree()
PARTITION BY toDate(timestamp)
ORDER BY timestamp
SETTINGS index_granularity = 8192
AS
SELECT
timestamp,
count(*) AS requests_per_second
FROM nginx.access_log_buffer
GROUP BY
timestamp
DC
Я немного сменю формулировку вопроса: в каком случае при создании MV лучше отдать предпочтение движку MergeTree, а в каком - AggregatingMergeTree. При условии, что мы будем аггрегировать данные. Допустим, mv будет выгляядеть так:
CREATE MATERIALIZED VIEW mv1
(
`timestamp` DateTime,
`requests_per_second` UInt64
)
ENGINE = MergeTree()
PARTITION BY toDate(timestamp)
ORDER BY timestamp
SETTINGS index_granularity = 8192
AS
SELECT
timestamp,
count(*) AS requests_per_second
FROM nginx.access_log_buffer
GROUP BY
timestamp
я бы сказал что тут можно использовать summingMT , хуже не будет
SC
Ну вообще да.
SC
Я правильно понимаю, что summingMT (как и AggregatingMergeTree) просто лучше уплотняет данные во время мерджа партов относительно MergeTree?
DC
Я правильно понимаю, что summingMT (как и AggregatingMergeTree) просто лучше уплотняет данные во время мерджа партов относительно MergeTree?
SummingMT/AMT
Просто MT оставит все записи.
еще раз повторю что
ORDER BY timestamp -- после слияний у вас будет оставаться одна запись для каждой секунды. Просто MT оставит все записи.
еще раз повторю что
FROM nginx.access_log_buffer GROUP BY timestamp выполняется на буфером, и легко вставит вам больше 1 записи на каждую (некоторые) секундуD
Я немного сменю формулировку вопроса: в каком случае при создании MV лучше отдать предпочтение движку MergeTree, а в каком - AggregatingMergeTree. При условии, что мы будем аггрегировать данные. Допустим, mv будет выгляядеть так:
CREATE MATERIALIZED VIEW mv1
(
`timestamp` DateTime,
`requests_per_second` UInt64
)
ENGINE = MergeTree()
PARTITION BY toDate(timestamp)
ORDER BY timestamp
SETTINGS index_granularity = 8192
AS
SELECT
timestamp,
count(*) AS requests_per_second
FROM nginx.access_log_buffer
GROUP BY
timestamp
про АМТ уже написали.
просто МТ в МВ можно использовать например:
- фильтрованные наборы данных
- другая сортировка для ускорения других запросов
просто МТ в МВ можно использовать например:
- фильтрованные наборы данных
- другая сортировка для ускорения других запросов
SC
Ок. Вроде понял.
Большое спасибо, что объяснили!
Большое спасибо, что объяснили!
AS
ребят всем добрый вечер, вопрос следующий, если я сделаю 3-4 запросов параллельно в ch с помощью jdbc для получения в среднем по 5 млн записей, не станет ли ch плохо?
DT
ребят всем добрый вечер, вопрос следующий, если я сделаю 3-4 запросов параллельно в ch с помощью jdbc для получения в среднем по 5 млн записей, не станет ли ch плохо?
Скорее плохеть будет jdbc драйверу,
DT
А эти запросы подразумевают какую то тяжелую агрегацию?