🧭 MinMax, set, bloom_filter, ngrambf_v1, tokenbf_v1 — какой индекс под какую задачу 🔥 Главная мысль Главная ошибка в ClickHouse — искать “лучший индекс вообще”. Его нет. Индекс выбирают не по названию, а по тому, какой у тебя фильтр в WHERE. Один индекс лучше работает на диапазонах, другой — на IN, третий — на тексте, четвёртый — на URL и path. То есть вопрос всегда не “какой индекс круче?”, а “что именно я фильтрую?”. ➕ Плюсы и минусы 🟢 Плюсы: • меньше лишнего чтения • быстрее фильтрация • можно точечно ускорять тяжёлые запросы Пример плюса: для IN по id подойдёт один тип индекса, а для поиска по payload — уже другой. 🔴 Минусы: • неправильный индекс почти не даст пользы • схема станет сложнее • ожидания будут выше результата Пример минуса: если поставить set на поле с высокой кардинальностью, он может почти не помочь. У него есть лимит на число уникальных значений в грануле. 🧪 Живые примеры MinMax Подходит для диапазонов и сравнений: • = • <, > • <=, >= • BETWEEN Это история про даты, числа, интервалы. Если данные можно хорошо отсекать по min/max — это его сценарий. set(N) Подходит для низкокардинальных полей, где немного уникальных значений. Например: • статус • тип • регион • категория Если уникальных значений в грануле больше N, индекс по ней уже не работает как надо. bloom_filter Нужен для проверок на вхождение, когда set уже не подходит. Полезен для: • IN (…) • has(array, value) Хороший вариант, когда значений много и нужен быстрый membership-check. ngrambf_v1 Нужен для поиска по тексту и по части строки. Подходит для: • payload • message • текстовые поля • regex / match Хорош, когда ищешь фрагмент внутри строки. tokenbf_v1 Похож на ngrambf_v1, но лучше работает там, где строка естественно делится на токены. Идеальные сценарии: • URL • path • endpoint • структурированные строки Для /api/v1/import токенами будут api, v1, import. Если совсем коротко: • MinMax — диапазоны • set(N) — мало уникальных значений • bloom_filter — IN и membership • ngrambf_v1 — текст и части строки • tokenbf_v1 — URL, path, токены 🏗 Архитектурная мысль В нормальной архитектуре индекс выбирают не “по памяти”, а по профилю запроса. Логика простая: • диапазон → MinMax • низкая кардинальность → set(N) • IN → bloom_filter • текст / regex → ngrambf_v1 • URL / path → tokenbf_v1 Главный риск — ставить индекс не под тот тип фильтра. Тогда индекс есть, а ускорения нет. ✅ Вывод В ClickHouse нет “лучшего вторичного индекса” ⚡ Есть только правильный индекс под правильный WHERE. ✅ Подходит: когда ты понимаешь, что именно фильтруешь ❌ Не подходит: когда индекс ставят “на всякий случай”