Да, я уже думал об tokenbf... Мне кажется, всё-таки не всегда в логах ищут целиком слова, хотя, наверное, в большинстве случаев это так. С другой стороны, часто и поиск по регулярному выражению нужен, и тут я сомневаюсь, что у ClickHouse есть оптимизации для этого сценария (особенно если использовать tokenbf вместо ngrambf), ну, или, по крайней мере в документации (https://clickhouse.tech/docs/en/engines/table-engines/mergetree-family/mergetree/) про оптимизации для регулярок ничего не сказано.

https://clickhouse.tech/docs/en/engines/table-engines/mergetree-family/mergetree/#functions-support

вот поддерживаемые функции для скипиндексов..

регулярок вообще нет, таких индексов вообще ни в каких sql базах нет, вам в elastic, solr, в том направлении

Я скорее ищу, есть ли какой-то компромисс между full scan, который делает ClickHouse при хранении просто сырых данных, и ElasticSearch, который конечно ищет всё очень быстро, но вставка в него уж очень медленная

Мне в статье https://habr.com/ru/post/512084/ предложили посмотреть на n-gram индексы (и, видимо, token индексы тоже), и пока что не уверен, делают ли они лучше или нет :)

(возможно, немного удивительно, но) индекс вида ngrambf_v1(3, 16384, 2, 0) на отзывах амазона и размере блока 8192 действительно помогает почти моментально (1 секунда против 100 секунд) ответить на вопрос, что какой-то подстроки нет, и отфильтровывает практически все блоки

(средняя длина отзыва в амазоне около 300 символов)

надо еще проверять на 20.7 последних, там вроде скан скип-индекса распалллелен

Вообще нет, я проверил на других сценариях, и иногда он сильно помогает, иногда — не особо. Но ещё больше делать блум-фильтр, кажется, идея так себе, поскольку тогда этот индекс уже будет сопоставим с размером самих данных и толку от него будет не очень много :)

(я тестирую на 20.5.3.27)

Спасибо!

Создал также для интереса ещё и индекс ngrambf_v1(3, 524288, 2, 0) и теперь действительно ClickHouse ощутимое время тратит на предварительную фильтрацию блоков (около 5 секунд на моём датасете, тогда как сканирование всей таблицы занимает около 100 секунд), но всё равно на множестве (реалистичных) запросов фильтрует от силы половину записей. Экспериментировать с tokenbf пока нет желания, но в целом, по крайней мере, я выяснил, что ngrambf_v1(3, 16384, 2, 0) дает результат не сильно хуже, почти не имеет оверхеда, и в среднем позволяет пропускать ~50% блоков, что тоже неплохо (опять же, повторюсь, на датасете из отзывов на амазоне).

50% это плохо. Ну и попробуйте на своих данных. А вообще с order by при определенной эвристике можно добиться нормальных результатов (например если в логе есть некий eventid и поиск по нему, добавьте его в order by). Тогда скип индекс будет в разы эффективней

Это же логи, там под произвольный пользовательский паттерн не подберёшь сортировку/эвристику

Выглядит так, что можно просто несколько разных ngrambf и tokenbf фильтров навесить, и хотя бы один да сработает для каждого блока в большинстве случаев, и будет хорошо :). Но желание экспериментировать у меня, к сожалению, где-то на этом месте уже закончилось :).

Кажется что если ты начнёшь вешать несколько полнотекстовых фильтров, то получишь, внезапно... ElasticSearch! И будешь огребать на деградации вставки (сейчас ты, как я понял, добавляешь индекс к существующим данным, и там жрётся CPU, а на реальных вставках этот CPU будет жраться в момент инсерта)

Слушай, ну вроде бы не сказать, чтобы прямо очень много CPU съедается этими фильтрами при вставке, и основные тормоза идут из-за того, что оно идёт в один поток (видимо, для мержей это раньше было не страшно, поскольку они упираются в диск как правило). Всё-таки одно дело немного ускорить отсечение лишних блоков по умному блум-фильтру, а другое — строить полноценный полнотекст. В общем, elastic же много диска жрет и из-за этого основные проблемы, а если ты ешь немного больше CPU и совсем немного диска при вставке, то я думаю, что это может получиться более сбалансированное решение для логов, чем чистый ClickHouse+fullscan и чем чистый ElasticSearch и полнотекстовый индекс.

ещё можно делать структурированные логи

Это несомненно большой плюс, особенно для ClickHouse, но не все логи можно хорошо структурировать, особенно когда они приходят извне, например если логами является вывод ffmpeg, или error-логи PHP. Какие-то колонки можно заполнять, но в целом зачастую это произвольный текст :)

и прям постоянно по ним искать приходится?

Постоянно — нет, но когда хочется и данных много, наличие дешёвого способа уменьшить время сканирования, скажем, с 10 минут до одной очень даже приветствуется :)