пишу сюда.
Как можно ускорить простой запрос и можно ли вообще:
SELECT * FROM transactions WHERE clickid='74af6c278b79a7bcbe18aaa3725cdece'
КХ на одной машине (с коробки, не тюнили), MergeTree, clickid типа FixedString(32), в индекс не добавлено (есть более приоритетные поля для индекса),
результат: 0.15 sec.| 5,521,409 rows.| 175 MB
Куда можно покопать?
это не очень хороший юзкейс для кх (точечные поиски). немного поможет вторичный индекс, но вы уверены, что вам это нужно? 🙂
а в кх завезли вторичный индекс?
вроде бы да? https://clickhouse.tech/docs/ru/sql-reference/statements/alter/index/
Сделать таблицу с ПК на clickid
Понимаю, что не очень юзкейс, но точно нужно ускорить)
он давно есть, но он "ненастоящий". Это скип индекс...
если кардинальность очень высокая скип индекс может помочь, если у вас повторяется в каждой грануле, то не поможет, добавьте в индекс, чем раньше (в плане порядка) тем лучше
это не те индексы, они не инверсные
KV база нужна, нахера тут КХ ?
А можно пояснение или пинок в сторону документации с пояснениями?
https://clickhouse.tech/docs/en/engines/table-engines/mergetree-family/mergetree/#table_engine-mergetree-data_skipping-indexes
индекса как такого нет, нельзя узнать в каком парте, в какой грануле, в какой строке хранится значение col=345645674567567 skip индекс хранится в парте КХ , например можно сделать индекс bloom_filter , в каждом парте будет лежать огромный blob = 10 МБ , который будет отвечать почти всегда: "да тут есть в парте 345645674567567" (у блум фильтра большой false positive). потом будет переход в колонку и поиск там 345645674567567, там конечно нету 345645674567567, в итоге все работает медленее чем без индекса. min_max работать не будет, потому что в каждом парте будет примерно min = минус_бесконечность, max = плюс_бесконечность, поэтому 345645674567567 попадает в этот диапазон set тем более не работает, это тоже самое что колонку еще раз положить в парт.
А какие объекты индекс «скипает»? Парты целиком?
гранулы основного индекса, skip индекс покрывает одну или несколько гранул основного индекса (задается при создании) для поиска каких-то рандомных значений размазанных по столбцу вообще не работает
Ну так гранулы уже не так плохо. Есть ощущение, что при правильно подобранных параметрах того же блума все же можно получить выигрыш (ну грубо прочитать пару лишних false positive гранул может быть выгоднее, чем фигачить фулкан по колонке)
блум просто писец насколько тяжелый в размере и в cpu нужном для вычисления, в 99% дешевле всю колонку просканировать
Партиционирование по хешу от ид, разве что. Отключить кастомные кодеки сжатия для колонки кликид. Ну и селектить * из клика как обычно плохая идея.
Обсуждают сегодня