том, что количество партиций не должно быть большим, желательно до сотен. В чем проблема если партиций все же много? Скажем, если разбить таблицу с историческими данными по дням? Мы всегда пишем данные за сегодня, т.е. запись идет только в одну партицию. Читаем как правило за послед несколько дней, т.к. 99% запросов читают всего из нескольких партиций. Скоростью остальных 1% запросом можем пренебречь. Это все равно является антипаттерном? Если да, то почему?
если запросы по большому кол-ву дней то больше будет операций с ФС, что негативно сказывается на производительности запросов. Так же с большим кол-вом партиций увеличивается время старта сервера. При правильном индексе партиции по месяцу не просто так рекомендуют, мы в свое время выбрали партиции по дням и теперь сервер поднимается минут 40-60, что очень неудобно( Из плюсов партиций по дням в нашем случае - удобные операции с данными: у нас данные заливаются дневными интервалами, и в случае чего можно быстро партицию заменить атомарно. alter modify/delete так же быстрее на меньшей партиции(если указывать именно партицию) - но такое не часто бывает.
во многих местах КХ не рассчитан на большое кол-во партиций и не тестировался. Например оптимизация partition pruning которая обычно работает наносекунды (внутри она просто перебирает все парты таблицы), если партов (НЕ ПАРТИЦИЙ!!!!!!!!!) 100 тыс, начинает работать пол-секунды, дольше чем выполнение запроса. Например ломаются мутации если партов >7-10 тыс., потому что все мутации (читай почти все alter table) создают в ZK запись, и не могут создать потому что запись и 7 тыс. имен партов, больше 1МБ (ограничение по дефолту в ZK). В некоторых ситуациях репликация скачивает с ZK список всех партов, у некоторых пользователей с большим кол-вом партов, трафик между КХ и ЗК под гигабит, и они внезапно удивляются тормозам на инсерт и счетам из AWS за трафик. Список этот бесконечный, поищите тут в чате, я раз десять уже описывал.
Обсуждают сегодня