вот такие для теста.
INDEX receiption_date_index documentReceptionDate TYPE minmax GRANULARITY 3,
INDEX receiption_date_index_dd toDate(documentReceptionDate) TYPE minmax GRANULARITY 2
) ENGINE = ReplacingMergeTree(loadDate) PARTITION BY toStartOfWeek(documentReceptionDate) ORDER BY documentID SETTINGS index_granularity = 8192
Данные в таблице примерно так распределены:
За один toDate(documentReceptionDate) примерно 20-30к уникальных documentID
Для разных documentID дата documentReceptionDate может быть одинаковой, может разной. Чаще разная
Методом подбора/тыка
Такие параметры, вроде как дают ожидаемый результат. Если в таком запросе select count() from trafficTarificationDrKzWithPayer where toDate(documentReceptionDate) BETWEEN toDate('2020-10-13') and toDate('2020-11-25') количество Selected 3 parts by key, то в таком select count() from data_vault_business_layer.trafficTarificationDrKzWithPayer FINAL where toDate(documentReceptionDate) BETWEEN toDate('2020-09-13') and toDate('2020-11-25') количество Selected 11 parts by key. Так же я могу убедиться, что индекс работает и лишнее не читается? Или надо на что-то еще посмотреть?
это сообщения про партиции и первичный ключ. про skip индекс написано dropped marks
Index receiption_date_index_dd has dropped 0 granules. Index receiption_date_index has dropped 0 granules. Выходит, не работает он тогда( А Если включить documentReceptionDate в ключ ORDER BY, по идее я же тогда получу ожидаемый результат, то есть чтобы не читалось лишнее?
да, если есть "локальность" или "коррелированность" documentReceptionDate относительно documentID. например documentID уникален и все время растет. далее тут https://clickhouse.tech/docs/ru/engines/table-engines/mergetree-family/mergetree/#primary-keys-and-indexes-in-queries
Обсуждают сегодня