2233 marks to read from 2167 ranges
(SelectExecutor): Reading approx. 571648 rows with 4 streams
1) у меня в запросе нет времени, в order by нет времени - как интерпретировать selected 24 parts by date - как он это сделал?
2) можно ли рулить количеством streams, или это где-то внутри делается и в зависимости от выбирается это число?
А сколько партов всего в таблице? Возможно это значит что был фулскан всех партов. А если партиционирование по дате - потому и пишет про дату
Партиционирования нет, активных партов 20 с чем-то, неактивных много. Я так понимаю, что число selected parts=число активных партов, что странно, у меня order by Kek, запрос делается с WHERE Kek IN, в моем мире он должен был в индексе найти, какой парт взять и потрогать только его (ну может парочку, из-за разреженности индекса), нет?
Так индекс в КХ разреженный, база может только обросить явно не нужные парты, и уже фулскан делать в нужных. Скиньте полный DDL таблицы. У вас походу даже с индексом - полное сканирование таблицы
CREATE TABLE extender ( `TraceID` String, `UserAgent` String, `UserIPv4` IPv4, `UserIPv6` IPv6, `CreatedAt` DateTime, `Version` Int64 ) ENGINE = ReplacingMergeTree(Version) ORDER BY TraceID TTL CreatedAt + toIntervalMonth(6) SETTINGS index_granularity = 256 Запросы вида SELECT UserIPv4, UserIPv6 FROM extender WHERE TraceID IN ? PS я знаю, что КХ не для KV)
Так а в чем проблема вашего селекта? Сколько записей в таблице и за сколько отрабатывает?
Проблема в том, что замер на 1ккк данных показал 90%tile в 5ms, а замер на 2ккк данных показал 90%tile в 10ms. Я не ожидал такого роста времени с ростом данных, ожидал, но не такой зависимости строгой прям. Или я не прав?
так а с чего такие ожидания? Если у вас объем таблицы растет, есть индексы, а размер выборки по условию - не растет. То тогда можно ожидать что с ростом таблицы время запроса не будет расти
Ожидания такие с того, что по факту становится больше только индекс, и хождение по нему увеличивается. Дальше трудозатраты по доставанию самих данных должны оставаться неизменными с ростом таблицы, мы знаем в каком месте на деске "примерно" почитать. Или я заблуждаюсь?
By date -- читайте by partition -- это кусок кода 4х летней давности , когда кх умел партиционирование только дате/месяцу
Принял. Это новояз какой-то что-ли? Положительная коннотация?
Обсуждают сегодня