следующим поведением: при запросе к distributed таблице с параметром use_query_cache=1, помимо основного запроса на ноде инициаторе, в кеш на каждом шарде таблицы попадают все внутренние запросы к таблице лежащей под distributed. Запросы к шардам выполняются под отдельным юзером interserver. Как сделать так, чтобы кеш использовался только для основного запроса на ноде инициаторе? Из мыслей только попробовать завести отдельный профайл для intersever и там отключить enable_writes_to_query_cache, enable_reads_from_query_cache. Кто-то сталкивался или имеет хорошее решение? Прошу поделиться.
Поптытки назначить профиль или settings с отключенным кешем запросов для interserver провалились. Прошу мудрого совета 🤔
как сделать так чтобы use_query_cache не передался дальше по цепочке, IMHO сложно SELECT * FROM (SELECT * FROM distributed_table WHERE ... SETTINGS use_query_cache=0) SETTINGS use_query_cache=1 не думаю что такое прокатит кроме того памяти будет жрать больше
Я вот думаю, должно ли оно вообще работать так, как работает by design. Советуете ли вы завести issue?
да логично это две независимые части, настройки и engine=Distributed исполнение запроса use_query_cache это просто настройка поведения которая в distributed запросах передается на все остальные ноды, чтобы добиться одинакового поведения соответсвенно кеш включается везде вы же хотите ускорения вот вам ускорение, распределенный кеш какая гарантия того что в следующий раз distributed запрос не будет исполнен на другой ноде кластера? и он уже будет ускорен, потому что локальные данные для него из локальных таблиц в кеше... но вообще не очень понятно, зачем вам вообще query cache? вы понимаете как этот кеш инвалидируется? вы меряете miss / hit соотношение?
Имею кластер с неизменяемыми данными, сделал чтобы запросы попадли на нужные шарды, чтобы был хороший cache hits. С этим всё ок. Но вот этот cache amplification который под капотом образовался, мне совсем не нужен. Для запросов LIMIT 50 OFFSET 100000 нода инициатор закеширует 50 строк, а все шарды под капотом 100050, мне кажется так не должно быть 🫤
SELECT * FROM (SELECT * FROM distributed_table WHERE ... SETTINGS use_query_cache=0) SETTINGS use_query_cache=1 вот так пробовали? сам по себе кеш не знает в каком контексте он исполняется...
Да, так не прокидывается сеттинг, спасибо, но красота решения, конечно, смущает сильно.
вы сказали что вам надо 50 записей закешировать, так оно закеширует 50 записей... как вы и хотели и получаете то поведение которое хотели
В любом случае, спасибо за помощь.
Обсуждают сегодня