Привет! Экспериментирую тут с кастомным PARTITION BY ключом в обычном MergeTree. Хочу

Question

Привет! Экспериментирую тут с кастомным PARTITION BY ключом в обычном MergeTree. Хочу

партишнинг по (дата, группа), где группа - это 1000 числовых значений (можно считать, что это client_id mod 1000).
Задача в том, чтобы эффективно использовать 1ТБ диск, удаляя слишком большие группы чаще, чем маленькие. То есть если в группе записей на 1МБ, она может жить и год (365 партиций для неё), а если 300ГБ, то, скажем, один или два дня только.
Данные поступают из 10-15 источников, почти отсортироваными по группам и времени, но в кажом источнике есть почти все группы. Каждый источник вствляет по 50-100МБ за раз раз в 20-30 секунд. Раз в несколько минут бывают маленькие вставки в несколько мегабайт или даже меньше.
Проблема на дефолтном конфиге - Too many parts. Если увеличить max_replicated_merges_in_queue, то всё какое-то время работает, но старые неактивные партиции не успевают удалятся и на файловой системе через какое-то время кончаются inodes. Если взять ФС без inodes, всё равно всё будет плохо ибо новые parts всё равно появляются быстрее, чем удаляются старые (пробовал также разные разные значения *_lifteme). А уж если перезагрузить сервер, кликхаус не запустится примено никогда (Loading parts...).
Буферные таблицы не помогают, хотя сильно с ними не экспериментировал.
Такое ощущение, что нужно разрешить кликхаусу не мёржить parts как можно дольше - типа делать это только раз в час или около того.
Решение, которое сейчас приодит в голову - сделать две таблицы, одну с партицированием только по времени (типа каждый час, без группы), а другую - по дате и группе. Ну, и рукаи брать всё, что из предыдущего часа и раньше, INSERT ... SELECT * FROM partitioned_by_time ORDER BY time, mod_group и предыдущие партиции из такой псевдо-буферной таблицы удалять. Но выглядит как страшный костыль и могу представить слишком много мест, где это может поломаться.
Может есть какие-то ещё параметры, которые стоит попробовать подкрутить под этот юзкейс?

#backend #clickhouse #database #devops #programming #russian

0

21.08.2018

2 ответов

8 просмотров

Kirill Shvakov

Вы тут себе в ногу прострелить хотите, попробуйте просто сделать партиции по дате, причем не по дню, а, например, неделе или как дефолт месяцу, и, возможно, просто сжатие все порешает за вас, если очень сильно хочется то и дефолтное lz4 поменяйте на zstd (https://clickhouse.yandex/docs/ru/single/#compression). Если как советовали ниже использовать движок Merge то при наличии "меленьких" и "больших" таблиц под ней будут неэффективно расходоваться ресурсы (по дефолту N потоков на запрос и часть завершиться быстро, а часть будет разгребать ваши "большие" таблицы). Еще сделайте буфер перед вставкой и, возможно, все взлетит и так;)

0

22.08.2018

Дмитрий Бережнов · Accepted Answer

Дмитрий Бережнов

А опишите ваши вставки не в Мб, а в кол-ве строк

0

21.08.2018

184 похожих чатов

Привет! Экспериментирую тут с кастомным PARTITION BY ключом в обычном MergeTree. Хочу

2 ответов

Похожие вопросы