11238
Обсуждаем ClickHouse
Clickhouse-keeper всегда был встроен в clickhouse. Это один бинарник, который запускается по разному.
Вам clickhouse-keeper = zookeeper - то есть вам так же требуется его развернуть на отдельных машинах, чтобы они не боролись за ресурсы диска.
Добрый день. Недавно сменил место работы и на новом месте требуется мигрировать кластер clickhouse на новые ВМ. Выдали инструкцию для миграции, довольно подробную на первый взгляд.
Вопрос возник почти сразу, так как мигрируем с версии clickhouse 23 на версию 25. В инструкции нужно устанавливать отдельно clickhouse keeper и отдельно для него и самого кликхауса прописывать в конфиге, в теге <logger> путь к отдельно созданной директории, но в 25 версии keeper встроен в clickhouse и насколько я понял, если прописать в <logger> путь для keeper логов в отдельную директорию ,это работать не будет, так как логи будут сохраняться в обычный путь для логов самого clickhouse-server. Если я все же пропишу путь для логов keeper в конфиге clickhouse, не нарушит ли это работу сохранения логов. Я не админ БД и коллеги, которые писали инструкцию давно уже не работают, ищу, где бы найти людей, которые могут подсказать подводные камни в этом вопросе. Спасибо заранее и извиняюсь за длинный сумбур.
То есть бахнуть пару суток (для верности) в min_age_to_force_merge_seconds и принудительно запускать optimize раз в сутки
Я правильно понял?
Выглядит похожим на решение
Про размер парта только нет информации, подозреваю, что сработает ограничение по строкам/размерам
Ну и получается как-то надо как-то отключить слияние за текущий день
слить парты в партиции командой позволяет optimize table ... partition ... final
https://clickhouse.com/docs/sql-reference/statements/optimize
но я не совсем понял всю вашу историю про нагрузку и ttl, так что может это и не то, что вы имели в виду
есть у меня подозрения что это баг, потому как проблема решается изменением пути в зукипере, который будет основан на имени шарда типа
create database test engine=Replicated('/clickhouse/database/test/{shard}','{shard}','{replica}')
Всем привет 👋
Подскажите, как-то реально переделать логику слияния, что бы слияние делать например раз в сутки (в часы наименьшей нагрузки)?
Сейчас партиционирование настроено по дням и бывает остаются не слитые парты и нагрузка может в часы наибольшей нагрузки вылететь. Инсерты делаю через буферную таблицу раз в 5 ГБ, получается примерно 210 млн строк раз в 3-10 минут (могу позволить потерять данные в случае отказа сервера)
TTL не понравился, давал много лишней нагрузки, возможно я его не правильно готовлю
Хотелось бы закрыть партицию и слить парты командой
КХ 24.8.14.39
Таблица около 15 млн строк
Столкнулся с проблемой восстановления БД из бэкапа после добавления нескольких таблиц REFRESHABLE MATERIALIZED VIEW
clickhouse-backup/main.go:823 > error="one of restoreDataRegular go-routine return error: can't attach data parts for table 'db2.lv_repository_statistics': code: 233, message: Detached part \"all_1_1_1\" not found"
параметры ядра тюнить бессмысленно в этом случае, это вообще про другое.
надо в query_log смотреть кто память жрет
>Имеется система запросов настроенная на одну ноду на которой дополнительно имеется несколько справочных таблиц.
ну так надо это исправить, реплицировать эти справочники на все ноды, делать запросы ко всем нодам, у вас финализация запроса явно память жреть
перейти на словари, вместо джойнов
Всем привет, подскажите, пожалуйста, какое решение подойдет. Есть таблица ReplacingMergeTree, туда льются данные по заказам. На основе данных этой таблицы строим небольшие аналитические отчеты, применяя настройку final=1 для точности. Сейчас появилась потребность в построении больших отчетов, за несколько лет. Важна точность, но при использовании final=1 на больших объемах CH падает. Движки вроде AggregatingMergeTree как будто бы не подходят, т.к в исходную таблицу один и тот же заказ попадает несколько раз, а затем схлопывается. Подскажите, есть какое-нибудь решение для этого?
Читать полностью…
Dagster
Airflow
https://github.com/dagster-io/dagster
https://github.com/apache/airflow
Возможно я неправильно понял вас, но я имею в виду: в текущий шардированный кластер из 3 шардов и по 3 ноды в каждой шарде, добавить еще 6 новых нод, на 2 из 3 шардов, они среплицируют все данные и станут репликами 2 из 3 шардов. После полной синхронизации из 6 новых нод сделать 2 новые шарды, там будут 50 ТБ обычных реплицированных таблиц и 50 ТБ шардированных, на шардированных подропать не нужные партиции как на новых так и на старых шардах.
Хотя наверно такой вариант непрокатит, в пути кипера же указывается номер шарды и он скорее всего может сломаться
server-configuration-parameters , не merge_tree, merge_tree уже убрали
Читать полностью…
https://clickhouse.com/docs/operations/server-configuration-parameters/settings#max_replicated_sends_network_bandwidth_for_server
https://clickhouse.com/docs/operations/server-configuration-parameters/settings#max_replicated_fetches_network_bandwidth_for_server
поставьте sends в 2гбита
Нет. Ничего по сути не изменилось. Просто deb пакет один. Кипер всегда был частью кх. Это один бинарник
Читать полностью…
Есть вариант настроить у таблицы min_age_to_force_merge_seconds
Но хорошо получится только с баш скриптом в кроне
Вы добавьте в issue сообщение с @al13n321
Читать полностью…
есть кто-то из КХ тут? как можно тикет определить в гитхабе как possible bug?
либо же это expected behavior а вот документация вводит в заблуждение
А при этом памяти сколько?
И ORDER BY какой
Это маленькая таблица.
И падает скорее не из-за самого final, а из-за его сочетания с группировками.
у таблицы есть partition by ? show create table ...
можно короче схлопнуть парты и если поставить do_not_merge_across_partitions_select_final=1 то from ...final работает практически без оверхеда по памяти и цпу
ну а версия КХ какая?
насколько большая таблица? может быть партиции за прошлые периоды можно смержить в один парт?
а без final на больших объемах тот же запрос не падает?
а то может, дело и не в нём
я бы заглянул для начала в query log и посмотрел, какие запросы помногу и подолгу выполняются, что не освобождают место в пуле
Читать полностью…
Ну да, лучше добавить как новые шарды и потом переносить данные по партициям для шардированных таблиц
Читать полностью…
возможно все сломается, потому что приложение не готово что те таблицы станут шардироваными, все не просто, я видел как после шардирования запросы на инициаторе начинали кушать в 5 раз больше памяти и работали в 10 раз дольше.
или например replacing + final, надо шардировать чтобы записи с одинаковым ключом попали на один шард, т.е. надо все переинсерчивать
Есть еще идея добавить новые ноды в текущие шарды, после того как данные на них синхронизируются, сделать их отдельными шардами и на шардированных таблицах дропнуть лишние партиции, ну и на старых шардах так же дропнуть не нужные партиции. И тогда не нужно будет переносить партиции
Читать полностью…
Это как то на стороне клика ограничивается или сервере нужно делать?
Читать полностью…