которая,
PARTITION BY ((toYYYYMMDD(ConnFirstEventTimestamp) * 100) + toHour(ConnFirstEventTimestamp), shardid)
где shardid = [0...9]
Во время записи несколькими параллельными инсертами для разных часов, возникла ошибка "too many open files". Было принято решение подправить ulimit и перезапустить сервер. После service clickhouse-server restart, CH стартовал долго (около 40 минут), и в процессе запуска мы увидели в логе больше 50 тыс. сообщений типа
2020.02.06 18:07:48.361884 [ 232 ] {} <Debug> mytable: Removing part from filesystem 2020012921-9_12418_12418_0
2020.02.06 18:07:48.364380 [ 104 ] {} <Debug> mytable: Removing part from filesystem 2020012921-9_12547_12547_0
2020.02.06 18:07:48.420295 [ 141 ] {} <Debug> mytable: Removing part from filesystem 2020012921-9_12738_12738_0
...
Посоветуйте, пожалуйста, как такого избежать?
@den_crane тут https://t.me/clickhouse_ru/139874 вы также писали подобные инсерты убивает зукипер. Почему?
P.S. Нам очень нужен партишнинг именно по часам + shardid (типа subpartitioning) - т.к. в час льётся "100500" ТБ данных.
ой да, умора, вы конечно уникальные такие и трафика у вас больше чем Я и других мастодонтов которым хватает месячных партиций. Давайте посчитаем, вы уникумы льете 150ГБ в час, у вас там i/o не трещит не? 3.6TB в сутки, как вам hdd дисков на неделю-то хватает?
Обсуждают сегодня