`product_id` Int32,
`keyword_stat_id` UUID,
`created_at` DateTime DEFAULT now(),
)
ENGINE = MergeTree
ORDER BY (keyword_stat_id, created_at)
SETTINGS index_granularity = 8192
product_id ~ 60.000.000 уникальный значений
keyword_stat_id - бесконечность
На один product_id на данный момент в среднем 900 keyword_stat_id (и будет увеличиваться со врменем)
На один keyword_stat_id в среднем 600 product_id
Вся таблица весит ~200 GB
и которых 5 GB весит keyword_stat_id
Задача сделать так, чтобы можно было быстро выбирать данные по product_id
Попробовал через проекцию
PROJECTION pid_ksid
(
SELECT *
ORDER BY product_id
)
Всё летает конечно же, но теперь таблица вместо 200GB весит 1TB из которых 600GB это keyword_stat_id 😢
Было решено переписать проекцию, чтобы оставить только поля product_id и keyword_stat_id.
Может есть какая-то возможность сделать поиск по product_id таким же быстрым, но чтобы общий вес таблицы при этом не выростал в 5 раз?
Индекс попробуйте
Попробовал, не получилось правильно настроить. minmax выдавал почему-то 0 гранул set(0) не дал смысла Может подскажите пример?
INDEX idx_product_id product_id TYPE bloom_filter(0.0002) GRANULARITY 1
Благодарю, попробую
Index `idx_product_id` has dropped 121940/122072 granules 🥲
я может в смайликах не разбираюсь, но всё же хорошо, не? Индексом отброшены почти все гранулы.
Вот когда-то спрашивал как поступить
Обсуждают сегодня