11016
Обсуждаем ClickHouse
чем больше нод - тем больше коннектов занятых под соединение между шардами. Ну и больше затрат в оперативе под диктонарисы, как и под джоины распределённые (не по ключу шардирования)
Читать полностью…
хотя. обычно девопсы отдалены от датаинженеров, потому решение подобных комбинированных задач - не практикуется.
Читать полностью…
рекомендация та же, обоснование то же: Bigger disk are harder to replace / resync.
если вам норм больше, то не вопрос ))
это вроде логика гринплама, у которого уж очень часто ноды отваливаются. По клику - ну 1 раз такое было за 2 года, что нода упала с дисками.
Читать полностью…
можно попробовать не зукипер а кипер
X Тб на Ноду - это тот объем который вы сможете за нужное вам мремя перекинуть с ноды на ноду
Даа… или просто компрессия csv и на сервер положить копии. Просто хотелось бы чтобы если понадобится можно было быстро данные забрать, агрегации
Читать полностью…
Очень хитрая идея да, но нужно delete :(
Между ДЦ 25гб сеть, тёмное оптика тоже есть, но да… если что-то не так тогда будет очень плохо.
Но я пытаюсь создать архив базу там будем перенести раз в год, руками, пару десяток терабайтов
Ааа,
DC1:
ZK1,2
CH1,2
DC2:
ZK1,2
CH1,2
DC3:
ZK
Как-то так ?
А сколько не посоветуй, все будет не правильно, большая часть киперов будет в одном центре и если он выйдет из строя не будет кворума
Читать полностью…
Там все асинхронное, так что почему бы нет, в идеале 3 центра надо, что бы нечетность киперов поддержать
Два основных с данными и третья точка с третьим кипером
Ну, понял да что я имею в виду? 😅 четыре реплики read-write
Читать полностью…
спасибо, изменил тип поля на timestamp в постгресе
Читать полностью…
это филосовский вопрос
на мой взгляд такие задачи на клике должны делаться постоянно без ожидания переезда )
в общем, рекомендованный размер диска ноды - это больше про обслуживание и ресурсы
хех ) вот и ответ. А если есть новая машинка, то тут лучше задачку заводить на аккуратную потабличную переливку с отбрасыванием шлака накопившегося и применение оптимизаций, которые на старой было бы слишком долго применять.
Читать полностью…
ресинк в клике полный не видел, только отдельные таблицы теряли парты, А у вас прям падала вся бд на реплике и нужно было полностью ресинкать ноду?
Читать полностью…
а в 99.9% случаев падает один диск из рейда, и ничего не надо переносить на другие ноды, просто одна стопается, пока реплика работает.
Читать полностью…
Вместо zk модно clickhouse keeper, вроде как перспективне
Читать полностью…
У меня данные 45 ТБ, 45 нод развернуть? 😅
Читать полностью…
И чем вам не нравятся 20тб на нодах? Есть тесты или ещё кроме советов?
Читать полностью…
не советую больше 10Tb на ноду... ну разве что это сильно cold данные будут. но тогда легче в какой то S3 утащить...
Читать полностью…
да, IMHO норм схема, но если между ДЦ длинный пинг, то будет плохо...
есть другая схема хитрее
просто не связанные ZK в каждом ДЦ где есть репликация...
и MV в Distributed таблицу кластер которой смотрит на другие ДЦ...
но не будет работать если хотите всякие там UPDATE \ DELETE ...
Не обязательно полноценный центр, просто точка хоть просто комната с отдельной сетевой связанностью, там данные не хоанить просто кипер
Читать полностью…
Split brain да? У нас нету 3 центра чтобы распределить по три местам.
При условии два датацентра сколько нод советуешь ?
Просто настраиваете репликацию кипером или зукипером по документации.
Никаких методичек нет, но они и не требуются
Привет ребята.
У меня такая ситуация: я использую ClickHouse как архив, и план такой что создать четыре мастера, два по датацентрам.
Вопрос первый: делали такую же систему?
Вопрос второй : есть ли какая-то документация или что-нибудь чтоб облегчить задачу как задеплоить?
Спасибо ❤️
при использовании MaterializedPostgreSQL я могу самостоятельно создать нужные таблички?
Читать полностью…