все деградирует, даже нвме 🙂 тут вопрос, скорее, что когда выбирают хдд - обычно думают только о нормальном режиме работы, про условный дегрейд режим и восстановление после него - не думают, а обычно запаса производительности у хдд уже не хватает. и в итоге у всех шок, что "база будет тормозить еще N дней, потому что меняется диск" 🙂
Разумный ли подход : хочу обсчитывать данные , которые лежат в кластере CH возвращать в CH. Новую порцию лить в свежую таблицу и подменивать партицию в исходной. Планирую использовать Apache Spark для расчетов . * нет никаких идей как это лучше приготовить?)
Разумный ли подход : хочу обсчитывать данные , которые лежат в кластере CH возвращать в CH. Новую порцию лить в свежую таблицу и подменивать партицию в исходной. Планирую использовать Apache Spark для расчетов . * нет никаких идей как это лучше приготовить?)
Делали так раньше. Запускали на airflow pyspark. В clickhouse можно использовать ReplacingMergeTree если подходит
df -h / Filesystem Size Used Avail Use% Mounted on /dev/md0 46T 38T 7.8T 83% /
Умрете - я не про потерю данных, а про сам синк и перформанс. У меня у самого примерно такие же цифры, достаточно интенсивный регулярный поток без пиков и поэтому замена дисков затягивается :)