в запросе, не указывая их условие явно в WHERE?
Суть: есть таблица, в которой uuid является частью первичного ключа, и один uuid всегда соответствует одному дню данных. Мы всегда передаем в запросе where uuid in (x...), соответственно передавать еще и and date >= y and date <= z — избыточно с точки зрения выполнения запроса. Но сейчас это нужно, чтобы отбросить партишены, которые не содержат этот date. Соответственно вопрос в том, можно ли отбросить лишние партишены без того, чтобы происходила еще и дополнительная ненужная фильтрация самих строк?
таблицу в которой uuid часть первичного ключа можно выкинуть слишком сильное кардиналити у ключа получается сделайте поля типа дата и низко кардинальные поля в PK и bloom_filter data skip index лучше для UUID
https://clickhouse.tech/docs/en/engines/table-engines/mergetree-family/mergetree/#table_engine-mergetree-data_skipping-indexes
можно через виртуальную колонку _part типа select _part, * from tablename where _part like '20200907%'; Но я не вижу чем это проще чем date>= and date<
перечитал, так понял partition для ретеншна данных, а в обращении по ключу вы не хотите чтоб работа была по всем партишнам. если не будете давать условии по partition key, будут читатся все, и это будет ужасно когда партиций много (например у нас более 15 тыс, запросы просто не работаеют когда в where не указаны ключи partition key) Либо менять партиционирование, либо давать в where
да, все так. вариант о котором еще думал — кодировать дату и версию выгрузки в одно поле (еще и компактнее можно, например 16+16 бит, таплом или упаковывать руками), и для выборки делать тот же where uid in (...), а партишены делать по первому элементу тапла или по битовому выражению, если руками. но еще не проверял, имеет ли это смысл и работает ли как хочется (но по идее должно).
усложняете зачем то, тогда проще хранить дату и запрашивать по ней тоже как exact match Date IN (YYYYMMDD) and UUID IN (list)
тогда две фильтрации вместо одной, нет? так как раз сейчас работает
вас что именно тревожит в двух фильтрациях? какую проблему решить пытаетесь?
это делается указывая эти условия в where. Это именно так и работает. Нужные селекту партиции выбираются на самой первой стадии запроса, по метаданным партам в памяти
Да это понятно, вопрос был в другом. Но в любом случае, переделаем чтобы не надо было хотеть странного.
а если вопрос про update / delete то все иначе конечно.
В том, чтобы отбросить лишние партишены, но не делать лишнюю (не играющую роли с точки зрения бизнеслогики) фильтрацию на уровне строк.
Обсуждают сегодня