Хотите больше контроля над объединением частей ReplicatedMergeTree в clickhouse

#partitioning #clickhouse

#разделение #clickhouse

Вопрос:

Допустим, мы используем эту таблицу:

 create table table1 (
  ingestion_time DateTime,
  ingestion_day Date,
  dim1 String,
  met1 double, ...
)
engine=ReplicatedMergeTree(...),
partition=(ingestion_day)
order by = (...);
  

У нас есть вариант использования, в котором нам нужно создавать новую часть каждые 15 минут, а затем для запущенного окна (назовем его окном обновления), возможно, удалять и воссоздавать определенные 15-минутные части.

Например, если окно обновления составляет 15 дней, я могу в 2020-10-20 выбрать удаление части для 2020-10-15 23:45 и повторно использовать ее.

Если я разделю на 15-минутный интервал, это быстро приведет к слишком большому количеству проблем с разделением, и поэтому я ищу способ получить точный контроль над объединением частей в MergeTree, где я могу сохранить 15-минутные части нетронутыми в окне обновления, возможно, вручную вызвать, чтобы объединить старые части в ежедневные разделы.

Есть предложения о том, как этого добиться? Я не смог найти никаких настроек, которые позволяли бы мне управлять слиянием частей, хотя есть настройки, которые я могу использовать для сохранения старых частей, которые были объединены.

Ответ №1:

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


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

 ..
PARTITION BY toStartOfFifteenMinutes(ingestion_time)
..
  

чтобы избежать ошибки «Слишком много разделов для одного блока вставки», необходимо увеличить ограничение параметра max_partitions_per_insert_block.

И удалите устаревшие разделы, вызвав DROP PARTITION .


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


Посмотрите на ReplicatedReplacingMergeTree или ReplicatedCollapsingMergeTree для дедупликации / свертывания данных с помощью CH-средств.


Политика хранения может быть определена на уровне столбца или таблицы с помощью TTL-предложения.