AP
Orca, к примеру.
Size: a a a
2021 March 04
DT
Al. P.
Это эпический таск конечно, но тем не менее, вдруг.
Начать стоит наверное с сбора статистики, а то оптимизировать будет нечего.
D
лучше не надо...
AP
Начать стоит наверное с сбора статистики, а то оптимизировать будет нечего.
Тема обширная, но пример выше (order by desc limit 10) упрется не в статистику, а в возможности переписать план запроса и выбрать с минимальной стоимостью. Стоимость же в том случае скорее всего будет full scan vs. index access.
AP
Где победит index search.
AP
Ну ладно, планов нет похоже 🙂
DT
Здравствуйте. Помогите пожалуйста.
Есть таблица:
Делаю запрос:
В результате идет сканирование всех партиций.
Как ускорит запрос? Ведь вринципе достаточно сканировать только посленюю партицию.
Есть таблица:
CREATE TABLE IF NOT EXISTS user_logs
(
user_id UInt64 CODEC(ZSTD),
message String CODEC(ZSTD),
ts DateTime CODEC(ZSTD)
) ENGINE = MergeTree()
ORDER BY (user_id, ts)
TTL ts + INTERVAL 1 MONTH DELETE
PARTITION BY toYYYYMMDD(ts)
SETTINGS index_granularity=8196
Делаю запрос:
SELECT * FROM user_logs order by ts desc limit 10
В результате идет сканирование всех партиций.
Как ускорит запрос? Ведь вринципе достаточно сканировать только посленюю партицию.
Ну эта штука решается и без анализатора, аналогично read_in_order
D
Al. P.
Тема обширная, но пример выше (order by desc limit 10) упрется не в статистику, а в возможности переписать план запроса и выбрать с минимальной стоимостью. Стоимость же в том случае скорее всего будет full scan vs. index access.
в КХ нет index access... а пример выше не работает потому что там в индексе ts не вначале
DT
в КХ нет index access... а пример выше не работает потому что там в индексе ts не вначале
Ну потенциально ничего не мешает кх выбрать последнюю партицию (кроме реализации фичи)
AP
в КХ нет index access... а пример выше не работает потому что там в индексе ts не вначале
Да, точно. Но партиция - это ведь, в принципе, сильно разреженый индекс?
AP
И из статистики (для стоимости) нужно фактически кол-во элементов в партиции.
D
Ну потенциально ничего не мешает кх выбрать последнюю партицию (кроме реализации фичи)
да, можно сделать очередность начиная с последних партиций, можно даже с последних партов, но эт слишком мелко
DC
Проблема в том что это поможет 3 инвалидам.
D
Al. P.
И из статистики (для стоимости) нужно фактически кол-во элементов в партиции.
эта информация уже есть, запрос я написал... только этот кейс не настолько важен имхо и партиции обычно очень большие... т.е скан миллиарда строк против 300 миллиардов в этом запросе вообще не решает
AP
эта информация уже есть, запрос я написал... только этот кейс не настолько важен имхо и партиции обычно очень большие... т.е скан миллиарда строк против 300 миллиардов в этом запросе вообще не решает
я бы сказал тут речь об общей эффективности. Т.е. необходимость сканировать в 300 раз меньше даст возможность исполнять грубо-говоря 300 таких запросов одновременно
AP
Но ладно, мне было интересно узнать вектор развития. Спасибо 🙂
D
такие запросы вообще не нужно исполнять... в мелких объемах разницы никакой, а в крупных надо тупо ставить force_index_by_date=1 и запрещать не писать условие для партиций
2021 March 05
S
clickhouse-router.ringostat.net :) SELECT * FROM system.metrics WHERE metric = 'DistributedFilesToInsert';
SELECT *
FROM system.metrics
WHERE metric = 'DistributedFilesToInsert'
┌─metric───────────────────┬──value─┬─description───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┐
│ DistributedFilesToInsert │ 906970 │ Number of pending files to process for asynchronous insertion into Distributed tables. Number of files for every shard is summed. │
└──────────────────────────┴────────┴───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┘
1 rows in set. Elapsed: 0.132 sec.
окей, а почему их так много может быть?
0) возможно потому что у вас кривой SAMPLING KEY получается из одного INSERT несколько кусков отдельных на каждый шард, а записей у вас так мало
1) потому что вы НЕПРАВИЛЬНО ВСТАВЛЯЕТЕ... вы их вставляете 5 одновременных вставок в секунду это 300 партов в минуту
2) вы в логи посмотрите, может быть у вас в remote_servers криво прописаны в конфигах хосты или реквизиты коннекта и данные тупо в ReplicatedMergeTree не попадают
3) потому что у вас может быть включен distributed через SYSTEM STOP DISTRIBUTED SENDS
см. тут
https://clickhouse.tech/docs/en/sql-reference/statements/system/#query-language-system-distributed
1) потому что вы НЕПРАВИЛЬНО ВСТАВЛЯЕТЕ... вы их вставляете 5 одновременных вставок в секунду это 300 партов в минуту
2) вы в логи посмотрите, может быть у вас в remote_servers криво прописаны в конфигах хосты или реквизиты коннекта и данные тупо в ReplicatedMergeTree не попадают
3) потому что у вас может быть включен distributed через SYSTEM STOP DISTRIBUTED SENDS
см. тут
https://clickhouse.tech/docs/en/sql-reference/statements/system/#query-language-system-distributed
M
Здравствуйте. Помогите пожалуйста.
Есть таблица:
Делаю запрос:
В результате идет сканирование всех партиций.
Как ускорит запрос? Ведь вринципе достаточно сканировать только посленюю партицию.
Есть таблица:
CREATE TABLE IF NOT EXISTS user_logs
(
user_id UInt64 CODEC(ZSTD),
message String CODEC(ZSTD),
ts DateTime CODEC(ZSTD)
) ENGINE = MergeTree()
ORDER BY (user_id, ts)
TTL ts + INTERVAL 1 MONTH DELETE
PARTITION BY toYYYYMMDD(ts)
SETTINGS index_granularity=8196
Делаю запрос:
SELECT * FROM user_logs order by ts desc limit 10
В результате идет сканирование всех партиций.
Как ускорит запрос? Ведь вринципе достаточно сканировать только посленюю партицию.
в sql есть приоритет выполнения операторов. ордер бай всегда идет раньше лимита, тк что бы получить первые 10 нужно сначала их все отсортировать. партиции больше про data manipulation