На скрине график LA по 4м шардам КХ. Подскажите, как

можно найти причину, почему неравномерная нагрузка? На бирюзовый запись не идет, и там понятно. Но почему красный вдруг стал недозагружен, а синий наоборот, в перегруз ушел. Речь идет о нагрузке по 150 LA на 40 ядрах. Т.е. совсем много

начиная от неправильного шардирования, заканчивая проблемами с выделенными ресурсами на ВМ (если это ВМ) или дисками на железе.

кх не балансирует запросы, если вы все запросы посылаете в один сервер, то так и будет.

Сергей Худояров
запросы все посылаются через haproxy на сервер на ...

я бы смотрел system.query_log, сравнивал какие запросы сколько обрабатывают и куда прилетают, скорее всего есть перекос

простите, а как это делать? есть ли какие нибудь готовые шаблоны запросов, чтобы проверить? запросов за час выполняется одинаково количество (60К) на проблемном и здоровом шарде. Есть какие-нибудь инструменты для сравнения? На что обращать внимание?

https://kb.altinity.com/altinity-kb-useful-queries/query_log/

Сергей Худояров
спасибо! Помогите понять, за что можно зацепиться ...

судя по количеству читаемых данных надо бы индексов или со структурой поиграться

у меня здесь мало опыта. Может есть возможность платной консультации?

Выполните explain indexes=1 ваш запрос

это надо с аналитиками или разрабами садиться, брать их запросы и разбираться что может помочь - работенка для полноценного дба в штате. От себя разве что могу посоветовать поразбирать что у клика по индексации https://clickhouse.com/docs/en/optimize/sparse-primary-indexes и https://clickhouse.com/docs/en/optimize/skipping-indexes У самого опыта не густо

Сергей Худояров
спасибо! Помогите понять, за что можно зацепиться ...

а какие сейчас primary key, order by и partition by на табличке buyouts_new_local? ну и есть ли другие индексы на ней

Сергей Худояров
спасибо! Помогите понять, за что можно зацепиться ...

и например хорошо бы разобраться почему у вас запросы возвращают 2.8кк строк (хеш с пастилы 14521524250897953175)

CREATE TABLE rtb_shard_new.buyouts_new_local ( ... ) ENGINE = MergeTree PARTITION BY toYYYYMMDD(buyout_date_time) ORDER BY (req_ssp_id, resp_dsp_id, req_site_id, resp_algorithm_id, resp_cpc_feed_id, resp_block_id, req_device_os, req_device_browser, req_device_osv, req_device_browser_v, req_sub_days, resp_seat_bid_bid_id, resp_seat_bid_bid_imp_id, resp_seat_bid_bid_price, resp_seat_bid_bid_nurl, resp_seat_bid_bid_burl, resp_seat_bid_bid_lurl, resp_seat_bid_bid_adm, resp_seat_bid_bid_ad_id, resp_seat_bid_bid_a_domain, resp_seat_bid_bid_bundle, resp_seat_bid_bid_iurl, resp_seat_bid_bid_cid, resp_seat_bid_bid_crid, resp_seat_bid_bid_tactic, resp_seat_bid_bid_cat, resp_seat_bid_bid_attr, resp_seat_bid_bid_api, req_site_name, resp_interests, resp_source, req_user_id, resp_new_id, resp_buying_type_id, req_ad_types, req_ad_output_type, resp_gender, req_sid_1, req_sid_2, req_sid_3, req_sid_4, req_sid_5, req_sid_6, req_sid_7, req_sid_8, req_sid_9, req_sid_10, req_sid_11, req_sid_12, req_sid_13, req_sid_14, req_sid_15, resp_top_id, resp_user_id, resp_campaign_id, req_site_news_id) SETTINGS index_granularity = 8192

скорее всего туда можно прикрутить MV, буду курить эту тему

выкиньте все, оставьте только buyout_date_time

так а в WHERE у вас что и что explain показывает по использованию партов и индексов?

можно ли ключ сортировки менять наживую?

нууу, там есть нюансы )))

https://gist.github.com/hsv000/1a6209efc329fc3e26887420e23d823e explain еще не делал

в таком количества полей в сортировке нет смысла каждая следующая делается внутри предыдущей

а в чем нюансы?

buyout_date_time - возможно будет достаточно построить по нему партиционирование req_ad_type и resp_dsp_id в сортировки clicks_coeffs - если не большая лучше сделать с движком джойн

спасибо, передам разрабам. будем думать

https://fiddle.clickhouse.com/1d97917b-d149-4c8d-b65d-089954af8ee9