А какие метрики берёте? Я брал за основу метрики базы: query_duration_ms

и memory_usage. Но по итогу оказалось, что duration может на одном и том же запросе меняться, а memory_usage вообще не годится ибо (цитата: "CH выделяет максимум памяти ..." на каждый job), хотя я проверял - данная метрика на одном и том же запросе не меняется.

При игре в долгую используется теория СМО, методологии USE https://www.brendangregg.com/ и APDEX. Но это долгая тема из области APM (application performance monitoring). В первую очередь надо на запрос и структуру таблицы глядеть, 80% косяков уже там видны

Но я просто менеджер. Если технари в профильном чате не подсказали, то тут, наверное, случай непростой. Надо начинать именно с описания ситуации. Железо, таблица, запрос, на что жалобы

Антон, и не забывайте, что изучать тайминг правильно в консоли КХ, все остальные способы привносят сетевые задержки на передачу данных, которые в плохих случаях могут съедать до 99% времени.

Не забываю=) Я смотрю в системных таблицах базы.

Можно просто запросы позапускать в консоли и поглядеть на динамику. А можно, все-таки, чуть поконкретнее про времена и запросы? Может @volodin_dd что подскажет тоже?

Я уже говорил. Надо для начала задать нормальные ключи сортировки и партиционирования. Заодно по максимуму избавиться от nullable типов и вообще посмотреть в сторону более примитивных. Потом надо размазывать на кластер. После этого я бы поигрался с индексами пропуска строк и разными алгоритмами сжатия, но это мне ни разу не помогло, предыдущих пунктов хватало за глаза. Ну и надо смотреть запросы. Особенно в сторону использования функций массивов вместо их разворачивания. И, конечно, движок AggregatingMergeTree. Это киллер фича.

Да, я все советы записал=) Спасибо ещё раз!

От меня, лишь изредка заглядывающего в КХ, такой слог был бы не совсем убедителен :) Но нужно описание ситуации. Часто лечится просто путём просмотра кода :)

Последний пункт прямо жирнющий плюс. Я первые несколько месяцев на текущей работе занимался в основном переписыванием легаси кода

Отказ от nullable-типов на практике нецелесообразен для таблиц, которые уходят в другие языки под анализ. Это мб хорошо для выстраивания больших таблиц под rawdata Такое веселье, когда у тебя в строковом поле пустота = '', а в числовом 0. А если в столбце может быть 0 и пустота?) Когда код обрастает сложными деталями, такие штуки - постоянно в ногу стреляют. И так сложно, а здесь на базовом уровне путаница. И еще веселее, если первичная обработка пустот должна идти в громоздком sql-коде :)

Базовые метрики (RAM, ЦПУ, диск) обычно всё показывают информативно, хз. С метриками разве что можно экспериментировать в плане выбора периода (5-15 минут) под подсчет удельного потребления ресурсов (для ЦПУ/RAM). Обычного этого достаточно. Для всего остального есть планы запросов.

Побуду капитаном очевидность. Есть такая штука EXPLAIN. Ставите перед запросом и запускаете. Далее смотрите план запроса и оптимизируете. Тем не менее, как сказал Илья - в конечном итоге встретите узкое место сети. (Вот буквально только что получал - запрос на сервере выполняется 420ms, а в qliksense тащит аж 2m 20 s. И это никак не преодолимо, имхо).

Да, надстройки в виде jdbc/http отжирают время. Ну и explain да, конечно.

Там изначально два вопроса в одном было. 1. Отладка 2. Мониторинг постоянный. Если я правильно понял.