занимает место 6TiB и содержит 30 миллиардов строк, очень неудобно их обслуживать, хочу переделать партиционирование на YYYYMMDD. Срок хранения данных 5 лет.
Могут ли возникнуть какие-либо проблемы с партициями YYYYMMDD при таких объемах данных?
1 месяц 6tb? Это 360тб за пять лет. Это не очень удобно на одном сервере. Новая реплика будет недели наливаться если сломается сервант. 1500 партиций тоже не сахар. И местами очень больно. В алтинити я бы посоветовал клиенту минимум 20 шардов.
у нас было много партиций, есть некоторые боли и надо быть очень осторожными, а то КХ стреляет всем чем можно по много-партиционным таблицам (время загрузки, ТТЛ, ДДЛ). если запросы/перезаливания только на свежих данных, можно делать гибридно (две таблицы, последний месяц дневная, дальше месячные) которые заалиасены под общей таблицей на Merge-Engine. а ещё можно лайкнуть это и в один прекрасный день это могут и сделать https://github.com/ClickHouse/ClickHouse/issues/16565
Я спрашивал только про 1 партицию YYYYMM на 6Tb для простоты, в реальности там уже есть шардирование на 4 сервера. Если Вы советуете перешардировать 1 партицию на 20 шардов, то с учетом того, что уже есть 4 шарда, получается надо перешардировать на 80 серверов. Я правильно понял, увеличивать кол-во шардов для того, чтобы использовать партиции YYYYMMDD?
Лайк поставил!) Интересная идея с Merge-Engine! А устаревающие данные из таблиц с партиционированием YYYYMMDD переливать в таблицы с YYYYMM, верно? Если верно, пробовали ли так делать? Возникли ли какие-нибудь трудности?
В смысле 24tb всего в месяц? Серьезно?
Да, а что смущает, много?
Много. В реальности я с трудом представляю как такой объем засервать на 4х шардах. Или только писать и никогда не кверять. Тут нужен большой кластер если это кликстрим. Ну и обычно настолько сырые данные не нужны на такой период.
Советую вам сразу забыть про yymmdd. Или надо очень хорошо понимать что вы делаете.
Да, все так, селектят их редко, обычно только последний месяц или последний год и стирать старые данные запрещают
Похоже мне придется воспользоваться вашим советом и не думать в сторону YYYYMMDD, - у меня не так много опыта с ClickHouse еще пока
Можете в алтинити обратится. У нас есть бесплатный час консультаций. Мы за час все обсудим и возможно расскажем вам как сократить кол-во данных в разы без потери качества.
Можно, руками. Трудности с переливанием зависят от рук. В зависимости от объемов одного запроса, скорости дисков, процессоров, параллельности запросов объем шардов лучше выбирать. У нас есть условно системы с шардами по 4-5 ТБ, есть 20 шардов по 30тб. Но у нас нет заметного qps/запросов.
А как именно обращаться? Я вот на сайте заполнил запрос, а мне назначили zoom-встречу с продажником из Австрии. На 45 мин. Я не в том месте запрос сделал?
Обсуждают сегодня