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

выдвать переполнение памяти, в чем может быть проблема?
DB::Exception: Memory limit (for query) exceeded: would use 9.49 GiB

For example, which queries?

SELECT DISTINCT id,user_id, FROM request WHERE event_type = 'bid' and id IN ('238862824074244635', '238856329183581358', '238847979799178464', '238845048900672098', '238842809361202089', '238809601308967527', '238775717847339988') AND cr_id IS NOT NULL AND created_ts > 1621582193;

Есть подозрение, что просто поправили подсчет потребления памяти для таких запросов

а на какой параметр нужно обратить внимание?

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

у меня есть индекс, как раз во where эта колонка используется

и почему без попадания в индекс, как определили?

Реалистично, только первая колонка может использоваться, потому что id последняя в составном индексе, маловероятно, чтобы ClickHouse её мог использовать для запроса. Но я не об этом. Я о том, что для эффективного удаления дублей в DISTINCT выбираемые колонки в DISTINCT тоже должны быть в индексе, причем подряд, например такой запрос в теории может не держать всё в памяти, с Вашей структурой таблицы: SELECT DISTINCT sp_id, c_id FROM tbl WHERE event_type = 'ololo'

Без DITINCT тоже не работает.... Насчет индексов т.е. все колонки которые есть в индексе, они должны присутсвовать во WHERE. Но если колонка во WHERE не указана, которая стоит сама первая, то след колонки не будут учитываться в индексе запроса? Я правильно понимаю

Где можно подробно насчет этого почитать?

Если без DISTINCT тоже выдаёт ошибку по памяти, то это уже интереснее :). Возможно, ClickHouse все-таки пытается использовать индекс, но кусок с фиксированным event_type не влезает целиком в память? Интересно посмотреть на план исполнения в логах сервера

Еще одна важная тонкость, диапазон захватывает две партиции.

Насчет плана, это EXPLAIN?

Если EXPLAIN уже поддерживается в ClickHouse?

Вероятно тогда EXPLAIN PLAN

min_bytes_to_use_mmap_io = 0 https://github.com/ClickHouse/ClickHouse/issues/24505

https://clickhouse.tech/docs/en/sql-reference/statements/explain/

ClickHouse сортирует данные в порядке возрастания первичного ключа, поэтому, как и для обычного составного индекса в традиционных СУБД, гарантируется адекватная производительность только при поиске по точному совпадению префикса индекса, то есть col1 = 'A' AND col2 = 'B' и т.д. Любые другие запросы могут тоже работать, и в ClickHouse вроде как полно таких оптимизаций, то есть можно пропускать колонки, если кардинальность не слишком высокая, но расчитывать на это я бы не стал, особенно если характер данных может меняться.

Спасибо, попробую

Спасибо, уложилось у голове теперь

Эту настройку можно просто в конфиге добавить, смотрю там нет такого параметра?

cat /etc/clickhouse-server/users.d/min_bytes_to_use_mmap_io.xml <?xml version="1.0"?> <yandex> <profiles> <default> <min_bytes_to_use_mmap_io>0</min_bytes_to_use_mmap_io> </default> </profiles> </yandex>

Спасибо!

Этот файл нужно создать?

ну да. Вы вообще про параметры и конфиги доку почитайте. и вот тут https://kb.altinity.com/altinity-kb-setup-and-maintenance/altinity-kb-server-config-files

Спасибо