Тоже. Очень хотелось бы понять в чем разница между нашими окружениями, почему у вас не воспроизводится. Сегодня уже не у ПК, завтра в гитхаб отпишу максимум подробностей (конфиг, лог, версия ЗК).

Доброго времени суток. Подскажите, чем можно подробно мониторить КХ?

У нас на сервере 60+ таблиц с kafka engine, которые складываются в обычные таблицы. С этих обычных таблиц мы читаем. Много. В итоге LA на сервере под 300.

Хотелось бы узнать что именно так напрягает железо (кафка, выборки, инсерты через материалки или еще что), чтобы понимать в какую сторону оптимизировать

order by как может на мержи повлиять? слияние отсортированных списков уже, там нет сортировки

ну я предположил что при слиянии надо сравнивать строки лруг с другом меж партами... ну и если ключи очень длинные, а префикс "длинного" индекса совпадает сильно, оно должно быть медленнее, нежели мердж-сортировка по 32 битам.

где то (наверно в сцилла) была оптимизация чтобы мерджились сначала парты с непересекающимися областями ключей...

ok. Я думаю там проблема в том что в один поток надо 150 ГБ распаковать , и потом запаковать

ну да, вы конечно правы, остальное спички.  но убирать компрессию волк тож не хочет  ¯\_(ツ)_/¯

ну у него собственный КХ, с бледжеком, он может и мультипоточный мерж запилить.

да, в общем случае выгода сомнительная... мерджи обычно поспевают, таблиц/партиций обычно больше 20-30 в системе... так, чтобы мерджи не поспевали именно изза однопоточности - эт надо одну большую таблицу/партицию иметь, и мерджить до немогу

Это нормальное поведение сортировки после группировки?

SELECT 
    symbol,
    partition
FROM trades_gaps
GROUP BY 
    symbol,
    partition
ORDER BY 
    symbol ASC,
    partition ASC
LIMIT 644, 15

┌─symbol─┬─partition─┐
│ VIBBTC │    201904 │
│ VIBBTC │    202006 │
│ VIBBTC │    202003 │
│ VIBBTC │    202007 │
│ VIBBTC │    201710 │
│ VIBBTC │    202005 │
│ VIBBTC │    201910 │
│ VIBBTC │    201908 │
│ VIBBTC │    201907 │
│ VIBBTC │    201905 │
│ VIBBTC │    201911 │
│ VIBBTC │    201903 │
│ VIBBTC │    202008 │
│ VIBBTC │    201909 │
│ VIBBTC │    201912 │
└────────┴───────────┘

Но, если в скобках, то:

SELECT 
    symbol,
    partition
FROM trades_gaps
GROUP BY 
    symbol,
    partition
ORDER BY (symbol, partition) ASC
LIMIT 644, 15

┌─symbol─┬─partition─┐
│ VIBBTC │    201710 │
│ VIBBTC │    201903 │
│ VIBBTC │    201904 │
│ VIBBTC │    201905 │
│ VIBBTC │    201906 │
│ VIBBTC │    201907 │
│ VIBBTC │    201908 │
│ VIBBTC │    201909 │
│ VIBBTC │    201910 │
│ VIBBTC │    201911 │
│ VIBBTC │    201912 │
│ VIBBTC │    202001 │
│ VIBBTC │    202002 │
│ VIBBTC │    202003 │
│ VIBBTC │    202004 │
└────────┴───────────┘



Наблюдается на версиях: 20.6.4.44 и 20.6.3.28-stable

пофикшено в stable 20.7.2.30

Спасибо. Завтра буду пробовать. Чтобы перенести таблицу на новый сервер, нужно выключить КХ или сделать DETACH, на новом серваке создать такую же таблицу, сделать DETACH для этой новой пустой таблицы, физически перенести каталог с файлами для таблицы /var/lib/clickhouse/data/dbname/tablename между серваками, например, используя rsync, сделать ATTACH tablename на новом серваке.  Я ничего не упускаю?

пофикшено в stable 20.7.2.30

Вы не знаете,  neighbor() и LowCardinality тоже пофиксили или нет?

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

А как иначе можно находить пропуски в монотонных последовательностях айдишников?

20 лет назад когда я видел этот вопрос я грязно ругался в ответ. Потом отпустило, стал просто игнорировать.

Ну, не знаю. Мне критично, чтобы данные автоматически восстанавливались после любых сбоев. Мне очень повезло, что в данных есть монотонные id. И это, вроде, работает.

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