SELECT ... FINAL используйте, но оно аггрегирует в один поток
https://github.com/ClickHouse/ClickHouse/pull/10463
скоро будет в несколько

Можно ли управлять тем, как часто будет выполняться дедупликация данных для ReplacingMergeTree?

Коллеги, кто-нибудь сталкивался с тем, что постоянно идёт ошиба Too many parts (300). Merges are processing significantly slower than inserts, но в таблице партиций немного (около 400) и пишется в неё редко?

parts != partions

Можно (дедубликация выполняется во время мержей в таблице), но нужно ли? Дефолтные настройки мержей подходят в большинстве случаев. можно делать OPTIMIZE PARTITION FINAL для партиций в которые не идут уже новые инсерты и там данные задедублицируются принудительно, но, вероятно, для партиций в которые постоянно идут инсерты - это не лучшая идея

Что можно сделать, чтобы не было дублей в партиции, в которую идут инсерты?

Этого нельзя обеспечить - т.к. 1 инсерт - 1 парт минимум 1 парт в партиции который еще ни с чем не помержен. Можно на уровне запроса к такой таблице учитывать это и доагрегировать там

это понятно, но я к тому, что такая ошибка возникает, когда много партиций или когда часто пишется, но ни того ни другого нету

ddl таблицы + описание типичного инсерта с его rps

Также можно писать select ... From table FINAL (он на уровне каждого запроса будет сам делать всё что нужно, но может сильно зааффектить производительность таких запросов)
пару сообщений выше есть pullrequest об улучшении этого поведения

Спасибо. Так и делаю, думал можно сделать это в диске тоже

Конечно, есть CollapsingMergeTree, но там не все так просто, нужно самому управлять дублями

Он тоже не мгновенно схлопывает строчки! а точно так же как и replacing

Даже так!!!

Думал как раз таки тут моментальная замена

create table queue_log
(
    callid    String,
    queuename String,
    agent     String,
    event     String,
    data1     String,
    data2     String,
    data3     String,
    data4     String,
    data5     String,
    time      DateTime,
    d         Date,
    data      String,
    ver       UInt64
)
    engine = MergeTree()
        PARTITION BY toYYYYMM(time)
        ORDER BY callid
        SETTINGS index_granularity = 8192;

Вставляем батчами где-то раз в 10 секунд.

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

Самое интересно ещё в том, что когда была версия КХ 20.1.3.7, то проблем не было, обновлились до 20.4.2.9 - начались

create table queue_log
(
    callid    String,
    queuename String,
    agent     String,
    event     String,
    data1     String,
    data2     String,
    data3     String,
    data4     String,
    data5     String,
    time      DateTime,
    d         Date,
    data      String,
    ver       UInt64
)
    engine = MergeTree()
        PARTITION BY toYYYYMM(time)
        ORDER BY callid
        SETTINGS index_granularity = 8192;

Сколько разных callid и сколько строк всего в типовом инсерте

select uniq(callid), count(*) from `10309_asteriskcdrdb`.queue_log

276278 1469584