Не соглашусь в части того что нарушено. Нарушения полиморфизма здесь нет, инкапсуляцию нарушает сам Котлин давая такую возможность.
А что нарушено так это принцип подстановки Лисков, которые говорит что поведение функции должно оставаться стабильным при передаче любого из наследников класса. Что очевидно нарушается в этом коде, сколько поведение зависит от того, какой именно наследник передан.
Очень подробно описаны внесенные изменения, но к сожалению практически не объясняется конкретная проблема, которую решали и как изменилось поведение системы.
Было бы очень здорово добавить существенно более подробные метрики системы до изменений и после. Например, из системных - загрузка CPU/диска, потребление памяти. Или из самого Clickhouse метрики вроде latency и availability (в идеале с графиками зависимости от throughput). Без этого непонятно зачем что-то меняли и как оценивали изменения, кроме “вот есть такая штука и она противоречит рекомендациям Clickhouse”.
Плюс неплохо было бы добавить сравнение (если оно делалось) между Kafka sink и асинхронными вставками (из документации Clickhouse).
Это бы существенно повысило ценность статьи, поскольку дало бы возможность оценить смысл изменений на своих системах.
Спасибо за статьи! Очень интересно читать, но эта статья существенно сложнее предыдущих 😅 Обилие формул как бы сразу намекает
Но ведь в формуле обобщенного F-score (Fβ) не получается F1 при β = 1.
Если β = 1, то множитель перед дробью становится (1+1)^2 = 4.
upd: спросил ChatGPT, квадрат должен браться от беты, а не от выражения в скобках. Видимо опечатка
Не соглашусь в части того что нарушено. Нарушения полиморфизма здесь нет, инкапсуляцию нарушает сам Котлин давая такую возможность.
А что нарушено так это принцип подстановки Лисков, которые говорит что поведение функции должно оставаться стабильным при передаче любого из наследников класса. Что очевидно нарушается в этом коде, сколько поведение зависит от того, какой именно наследник передан.
Спасибо за статью!
Очень подробно описаны внесенные изменения, но к сожалению практически не объясняется конкретная проблема, которую решали и как изменилось поведение системы.
Было бы очень здорово добавить существенно более подробные метрики системы до изменений и после. Например, из системных - загрузка CPU/диска, потребление памяти. Или из самого Clickhouse метрики вроде latency и availability (в идеале с графиками зависимости от throughput). Без этого непонятно зачем что-то меняли и как оценивали изменения, кроме “вот есть такая штука и она противоречит рекомендациям Clickhouse”.
Плюс неплохо было бы добавить сравнение (если оно делалось) между Kafka sink и асинхронными вставками (из документации Clickhouse).
Это бы существенно повысило ценность статьи, поскольку дало бы возможность оценить смысл изменений на своих системах.