Привет всем, есть какой-то универсальный способ для поиска по тексту? Сейчас разбиваем строку на массив слов и потом hasAll(array, [‘hot, 'dog’]) по нужным словам

Есть. Elasticsearch, например.

снаружи проверяете, что в результирующем массиве нет 1, но кх под это не заточен

https://clickhouse.tech/docs/ru/sql-reference/functions/string-search-functions/#multisearchallpositions

я имел ввиду это отдельный железный диск? или какой нибудь iscsi \ EBS ?

отдельный железный диск

https://clickhouse.tech/docs/en/engines/table-engines/mergetree-family/mergetree/#available-types-of-indices
ngram data skip index можно попробовать, но это не полнотекстовый поиск ни разу

а по второму вопросу? SHOW DATABASES показывает что нибудь с названием tmp ?

Да, это база такая.

test_count - это таблица в ней, как выяснилось

ls -la /mount/rdisk2/metadata/tmp/test_count.sql
какого owner показывает?

SHOW CREATE DATABASE  tmp;
какой движок показывает?
Atomic или Ordinal?

ну и stacktrace нужен либо из логов возьмите /var/log/clickhouse-server
либо из system.stacktraces поищите

-rw-r----- 1 clickhouse clickhouse
SHOW выдает ошибку

Code: 76, e.displayText() = DB::ErrnoException: Cannot open file /mount/rdisk2/metadata/tmp.sql, errno: 13, strerror: Permission denied (version 21.3.2.5 (official build))

лог ищу

Как раз полнотекстовый не нужен, попробую

Я кстати так и не смог найти настройки, с которыми бы ngram индекс бы действительно что-то существенно ускорял для фильтрации текста логов :(. Может у кого-то есть пример?

Собственно, кажется с Вами я это и обсуждал год назад :). https://m.habr.com/ru/post/512084/comments/#comment_21885266

Могу себе представить, что для поиска редко встречающихся значений он может подойти

Теоретически — безусловно. Меня лично больше интересуют конкретные настройки, которые подходят для логов :). По ссылке выше я описывал свои варианты, которые пробовал.

(Я и есть youROCK на хабре, если что :))

Подскажите, что именно я делаю не так.

У меня имеется большая таблица которая обновляется через python скрипт. после обновления данных запускается другой скрипт который считает витрину по этим данным, но я заметил что данные не сразу становятся доступными.

К примеру: мы посчитали что у пользователей из группы А в день Х -> 200 кликов по разным страницам, то лишь спустя N минут эти данные можно будет получить при запросах.

Движок таблицы с которой возникают проблемы - MergeTree

Данные вставляются в таблицу батчами по 50 000 строк в несколько потоков. Потоки бьются по разным источникам чтобы за раз не исчерпывать много оперативы и проще было перезапустить упавшую задачу

В данный момент в таблице более 100 миллионов строк.

Также подобная проблемы была впервые обнаружена пару месяцев назад на старой версии кликхауса. Получилось решать ее при помощи ожидания optimize table final после окончания вставки всех данных.

Скорее всего я делаю что-то не так.

Для практики нужен датасет и ограниченных круг хотелок.