3k достаточно. В консоли у сервера(cloudwatch) видно сколько он жрет iops, проверьте есть там полочки из 3к или нет
и партиционирование важно, меняем PARTITION BY получаем разницу в 100 раз
You should not. When you insert every 5 minutes and your inserted rows cover 1 (sometimes 2) hour and the insert creates only one part.
I was talking about another case. Partition by (toStartOfHour(), other_column). If the batch (1 mil. rows) contains many (i.e. 10) different values of other_column (covers 10 partition) the batch (insert) will be separated to 10 parts. It has negative impact on performance.
For this case it should be 10 inserts (10 batches) with 1mil. rows each with only one other_column value.
CREATE TABLE bad
( k Int64, s String)
ENGINE = ReplicatedMergeTree ('/clickhouse/{cluster}/tables/bad','{replica}')
PARTITION BY k ORDER BY s;
insert into bad select number, 'x' from numbers(110);
0 rows in set. Elapsed: 3.829 sec.
insert into bad select number, 'x' from numbers(110);
0 rows in set. Elapsed: 1.347 sec.
insert into bad select number, 'x' from numbers(110);
0 rows in set. Elapsed: 0.874 sec.
CREATE TABLE good
( k Int64, s String)
ENGINE = ReplicatedMergeTree ('/clickhouse/{cluster}/tables/good','{replica}')
PARTITION BY tuple() ORDER BY s;
insert into good select number, 'x' from numbers(110);
0 rows in set. Elapsed: 0.032 sec.
insert into good select number, 'x' from numbers(110);
0 rows in set. Elapsed: 0.013 sec.
insert into good select number, 'x' from numbers(110);
0 rows in set. Elapsed: 0.008 sec.
У меня партицирование по месяцам, проблема в том что есть параллельные вставления, они плодят парты, пока файлы мелкие получается много партов, и я вставляю через Buffer Engine что бы их было поменьше. В конце я имею не так уж много партов на месяц, штуки три, ну максимум пять. но это одна сторона медали, вторая сторона связана с моим вторым вопросом. И да, я не правильно итерпретировал твой вопрос, партиций не много, много партов.
