max_external_before_group_by

а на первом сколько отжирал? может там есть какая координация, если один сервер переходит в спиллинг - все переходят

на первом 118

Хз) пока для меня это темный лес

118 - с установленном ограничением или без?

с установленным ограничением

а ну, скорей всего так и есть (если один сервер пробивает лимит, все начинают спиллить). это легко проверить запустив запрос с трейсом. трейс пишет со всех серверов логи

Хм, так и сделаю

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

доброго дня.
в части документации по ReplacingMergeTree
разъясните пожалуйста, "не даёт гарантии отсутствия дубликатов" - до момента очередного слияния данных запросом OPTIMIZE,
либо гарантии отсутствия дубликатов нет в принципе, даже после слияния?

и насколько у слияния неизвестный момент времени?

после успешного optimize final, при отсутствии вставок гарантия есть

то есть в схеме:
1. есть внешний источник данных, в нем есть данные, которые могут меняться, за последние 4 часа, более ранние данные неизменны.
2. есть ReplacingMergeTree, в который синхронизатор на php это записывает.
3. синхронизатор делает вставки.
4. синхронизатор запускает оптимизацию
5. синхронизатор точно один

данные будут точно правильные, если они старше 4 часов? и правильные вне времени, когда шаг 3 уже начался, а шаг 4 ещё не завершился.

обманываю, если есть партиционирование по ключам которые не входят в primarykey - то не дает гарантий совсем

Привет!
На версии 20.4.4.18 ловлю  поведение вида`max_parallel_replicas`отличное от единицы применяется даже к таблицам у которых нет Sampling key. Это ожидаемое поведение?

ENGINE = ReplacingMergeTree()
               PARTITION BY (toStartOfQuarter(date_time_utc))
               ORDER BY (station_id, date_time_utc)

ничего не понял, но
данные будут правильными если они схлопнуты optimize final-ом, и новых данных с такими же первичными ключами не прилетало

опять обманул. если будут строки из разных partition (из разных quarter) - у вас будут дубликаты
исправлено: если бы date_time_utc не был в order by

а нет, в вашем случае date_time_utc в ключе, они считатся дубликатами не будут. поэтому у вас optimize-final будет гарантировать

подводя итог дискуссии..
1. у меня есть ReplacingMergeTree
2. ORDER BY (station_id, date_time_utc)
3. у меня есть PARTITION BY (toStartOfQuarter(date_time_utc))
4. я делаю вставки, у которых повторяется station_id, date_time_utc

5. после optimize final будут последние вставленные данные по определенному набору station_id + date_time_utc?