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

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

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

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

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

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

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

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

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

что значит слово "обновляется"? вы только новые данные вставляете или у вас там какой нибудь ReplacingMergeTree?
у вас один сервер или несколько?

что такое "витрина"? это отдельная таблица? или что?

доброе утро
из-за неаккуратных действий с DETACH/ATTACH partition (были выполнены сразу на нескольких репликах) в таблице задвоились-затроились парты
можно ли что-то с этим сделать? или только откатываться на бекап?

можно посравнить хеши и кол-во строк и осторожно убрать дубликаты

с помощью DETACH PART?

проблема с NUllable что все в раза медленее и больше места на диске

А какие рекомендации по избавлению от nullable? Если есть в таблице поля, у которых значения может не быть. Придумывать дефолтовое значение, заменяющее null? Или есть другие варианты?

красота, нашел Parsers/New/ClickHouseParser.g4, то что надо - спасибо