Ещё вопрос: >Too many parts (300). Merges are processing significantly slower

than inserts.
это означает, что у меня много партиций и мне нужно PARTITION BY (os, toYYYYMMDD(t)) поменять на PARTITION BY (os, toYYYYMM(t)) ?
или наоборот у меня много кусков в одной партиции и мне нужно PARTITION BY (os, toYYYYMMHH(t)) ?
после того как прочёл документацию, то склонялся к первому варианту, прочитав её же на английском уже склоняюсь ко второму варианту :)

посмотреть количество кусков в одной партиции можно вот так, верно?
SELECT table, partition, count()
FROM parts
WHERE active = 1
GROUP BY table, partition
ORDER BY count() DESC

у меня тут максимум 13 активных блоков на партицию получается, а не активных 116. хз откуда 300 взялось в ошибке.

Это значит, что в одной партиции слишком много партов. Обычно это связано с тем, что добавление новых кусков происходит медленнее, чем слияние старых. Может помочь увеличение количества вставляемых за раз записей (рекомендуется до 1 млн) и увеличение числа потоков для фоновых мерджей (настройка background_pool_size).

у вас проблема с partition key, понизьте его кардинальность

получается, что если понижу кардинальность partition key, то в одной партиции будет ещё больше блоков и будет только хуже

При вставке батч бьётся на партсы, если мержить не успевает и накапливается 300+(по дефолту) партсов - вставка стопается.

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

спасибо. можно как-то глянуть, сколько сейчас ещё не смёрженых партов? насколько я понял в system.parts where active=1 - это те, которые уже были смёржены

select * from system.parts where table = <table> and active это активные парты

ну * оверхед, но да, каждая строка - 1 parts, если еще подробнее надо, есть еще parts_columns

parts_columns я тоже смотрел, мне интересно глянуть сколько на текущий момент несмёрженых партов ожидают в очереди.

Но ведь это никак не поможет с решением проблемы. Ошибка же возникает именно при превышении лимита на число партов в одной партиции. А с уменьшением числа партиций вероятность увеличения числа партов в ней (в сферическом вакууме незнания вставляемых данных) только увеличивается.

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

Я кстати сделал бы order by (os, toDate(t),...) partition by toYYYYMM(t). Это судя по всему +-классика для большинства кэйсов.

видимо так и сделаю. ожидалось, что стату будут смотреть по платформам отдельно, но в итоге как обычно смотрят всё1 скопом, так что партицирование по os избыточно

у меня вставка раз в минуту около 10к записей, поштучно вставляются только через буферную таблицу из неё только батчами раз в минуту. всего миллиард записей. нагрузка на диск и проц - околонулевая. никаких зукиперов и т.д. и тут на совершенно ровном месте такая хрень :) нету у меня миллиона записей за раз :)

Насчёт увеличения числа партов на партицию был неправ, согласен, оно должно остаться неизменным. Не понимаю почему оно должно уменьшиться. Возможно, я чего-то не понимаю. Можете на примере проиллюстрировать? Вариант 1 - ключ партиционирования (A, B), оба ключа могут принимать только значения [0, 1], т.е. есть всего 4 партиции: 00, 01, 10 и 11. Вариант 2 - ключ партиционирования (A), ключ принимает значения [0, 1], т.е. всего две партиции: 0 и 1. Если вставка идёт раз в 5 секунд пачками по 1млн равномерно размазанных по партициям данных, то в первом случае имеем по 12 партов по 250к записей на каждую партицию в минуту, всего 48 партов, во втором случае имеем по 12 партов по 500к на каждую партицию в минуту, всего 24 парта. Но если данные размазаны по партициям неравномерно с перекосом, например, в (0, 0), то в первом случае будут те же 12 партов на партицию, только где-то они будут по, скажем, 700к, а где-то - по 100к. Во втором случае тоже по 12 партов на партицию, только по 800к и по 200к. Т.е. суммарное количество партов уменьшится, но число партов на партицию не изменится. Но ошибка-то возникает именно из-за большого количества партов на одну партицию.

Думаю, некорректный пример в том смысле, что кардинальность обоих полей всего 2. Была бы 10 и 100, то за несколько вставок можно было бы вставкой опередить мержи по количеству партов

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

Ну да, они же по итогу будут лежать в разных партициях. Instert - parts - merge - partition

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

Йеп, вы правильно поняли, может я не совсем точно выразился в первый раз