Итак, следующий вопрос про переезд с одного сервера КХ на

кластер.

В standalone таблицах используется движок CollapsingMergeTree, который необходим для периодического очищения таблиц от специфического мусора. И всё работало отлично в плане схлопывания, но сейчас перевели данные на ReplicatedCollapsingMergeTree, в которые, соответственно, происходит запись через Distributed. И выясняется, что часть данных «схлопнулась», а часть — осталась. И непонятно, «схлопнутся» ли оставшиеся, и если да, то когда, а если нет, то почему…

Раньше был способ — выполнить OPTIMIZE при необходимости и радоваться жизни, но с Distributed это не работает 🤷
И как теперь быть?

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

Тут вроде 2 проблемы. Первая это что оптимайз теперь надо запускать на replicated таблицу (если прям очень сильно надо). Вторая проблема это если ключ order by не соответствует ключу шардирования и эту проблему только что объяснили выше)

А не подскажете, как тогда указать правильный ключ?

А вы собираетесь в будущем добавлять новые сервера/шарды?

ну правильный будет тот, который строки, которые в теории должны схлопнуться будет отправлять на один и тот же шард)

https://clickhouse.tech/docs/en/engines/table-engines/special/distributed/ Тут есть про sharding_key.

Ну, это как пойдёт. В ближайшие пару лет, наверное, нет

Всё именно так и оказалось, спасибо за наводку… murmurHash3_64(column_name) решил проблему корректного ключа шардирования

👍🏻🎉

Радость была преждевременной, оказывается: на одном наборе данных (небольшой набор, чуть более 5кк записей) всё отработало как надо, на чуть более большем (130кк) уже пару часов данные не «схлопываются». Причём с разными знаками они лежат на одном шарде (проверил, на других шардах их нет), ключ совпадает, но не схлопываются. Что это может быть и что делать?

Доагрегировать в самих запросах. По крайней мере так в документации написано. схлопывание работает в фоне и не стоит на него полагаться.

Понятно, что в фоне, вопрос лишь, в какие сроки это событие всё ж таки наступает

В документации написано, что некоторые может никогда не схлопнуть

Перечитал документацию, не нашёл такого. В случае, если разные количества и непонятный порядок состояний — да, может быть всякое. Но в случае, что все условия для свёртывания строк выполнены корректно — в документации не говорится про «никогда» 🤔

>CollapsingMergeTree выполняет это при слиянии кусков данных. >алгоритм слияния не гарантирует, что все строки с одинаковым ключом сортировки будут находиться в одном результирующем куске данных >Если необходимо получить полностью свёрнутые данные из таблицы CollapsingMergeTree, то необходимо агрегирование. >Если вставить данные одним запросом, ClickHouse создаёт один кусок данных и никогда не будет выполнять слияние. Документация: https://clickhouse.tech/docs/ru/engines/table-engines/mergetree-family/collapsingmergetree/amp/

Некоторые фразы вы вырвали из контекста и придали им смысл, которого авторы документации в них, как мне кажется, не вкладывали 🤷‍♂️ Никогда — это именно никогда. Но в документации говорится иное: «ClickHouse объединяет куски данных в неизвестный момент времени, который мы не можем предсказать.»

попробуйте optimize table ... final, оно доагрегирует даже если данные в одном парте

Да, это сработало применительно к отдельной ReplicatedCollapsingMergeTree, но это не очень корректно, на мой взляд, бегать по нодам и искать, где лежат данные. На 5кк данных автоматическое свёртывание строк произошло через 2-3 минуты после вставки строк с отменой состояний. А вот на 130кк это не произошло и через несколько часов, хотя судя по логам КХ что-то там с этой таблицей делал, переименовывая и объединяя партиции 🤷‍♂️🤔 Ошибок в логах нет

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

Запросов прям уйму переписывать тогда придётся 🤦‍♂️ Целый проект. Хочется как-то малой кровью обойтись.

сделать вью или промежуточную таблицу и пусть запросы ссылаются на неё?

Как компромиссное решение — очень даже неплохая идея 👍 Спасибо 🙏

рад помочь 👍🏻

И, к слову, на какой-то конкретный момент и не рассчитывали. Но интересовал предел ожидания. Например, автоматическое свёртывание строк в течение часа вполне устроило бы. А несколько часов — это прям перебор.

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

у вьюх там прямо магия какая-то под капотом происходит в отношении прокидывания параметров

не совсем понял 🤔 зачем туда какие-то параметры прокидывать? я имел в виду, что можно написать код для обычной вьюхи на ту таблицу, что используется для "уймы запросов", тогда просто в них нужно будет подменить таблицу на вьюху 🤷‍♂️

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

В последней моей цитате как раз было "никогда". Но вы видимо иначе прочитали документацию и для вас это означает "в течение часа или около того". Ну ок. Вам виднее. У меня встречались несхлопнуье строки, которые никогда не схлопывались, я прочитал документацию. Всё сошлось. При чём это поведение логично и встречается в других аггрегирующих движках. Сворачивание происходит только при слиянии кусков. Если слияния кусков не происходит, то сворачивания нет. Куски не сливаются в бесконечном цикле в один мега кусок.

Я про то что если вью это просто view as select.. from с аггрегацией, то запросы вида select.. from view where... будут хорошо оптимизированы. Если вью это view as select ... from (select...from) То запросы вида select.. from where будут работать возможно не так как ожидалось) а если там где то внутри ещё и джоин не дай бог..

понял) в целом — согласен, но проверять подход это "уже совсем другая история", конечно нужно смотреть что за запросы, пробовать варианты, сверять скорость и т.д. и т.п.)

Я вам в одном из своих ответов писал дословно следующее: «в случае, что все условия для свёртывания строк выполнены корректно — в документации не говорится про «никогда» 🤷‍♂️ Понимаете разницу? Странная дискуссия. Я говорю о том, что есть таблица с данными, куда залили строки с отменой состояний, но свёртывание не сработало, как заявлено в документации, в ответ на что вы говорите о других сценариях

>ClickHouse объединяет куски данных в неизвестный момент времени, который мы не можем предсказать. Ваша же цитата. Я читаю её как "слияние может быть моментальным или вообще никогда". Если вы читаете её как "час-день", то ок, нужно просто уточнить у разработчиков. Но проблема я так понимаю всё таки есть и решать её надо. Самый простой способ - это добавить в запрос FULL, чтобы не переписывать все запросы на аггрегацию. Или если данных всего несколько лямов, то переименовать таблицу и создать вьюху с аггрегацией со старым именем.

а вот и ответ от саппорта яндекса. https://t.me/clickhouse_ru/87554