11238
Обсуждаем 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гбита
так а в чем проблема скопировать 50ТБ по сети? сеть 10гбит? боитесь что диск будет нагружен? Можно зарезать поток, например сделать 2 гбита
Читать полностью…
а если для another_table2 написать limit 3000 , то быстро работает?
Читать полностью…
Есть вариант настроить у таблицы 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, надо шардировать чтобы записи с одинаковым ключом попали на один шард, т.е. надо все переинсерчивать
Есть еще идея добавить новые ноды в текущие шарды, после того как данные на них синхронизируются, сделать их отдельными шардами и на шардированных таблицах дропнуть лишние партиции, ну и на старых шардах так же дропнуть не нужные партиции. И тогда не нужно будет переносить партиции
Читать полностью…
Это как то на стороне клика ограничивается или сервере нужно делать?
Читать полностью…
Добрый вечер!
Поделитесь опытом, если кто делал такое.
Есть кликхаус кластер состоящий из 3 шардов, кластер весит 100 ТБ из них 50 ТБ это шардированные таблицы, а остальные 50 ТБ это таблицы не шардированные и они имеют одинаковый набор данных на всех нодах этих 3 шардов. Нужно к текущему кластеру добавить еще две шарды. Как правильно их добавить? чтобы не было высокой нагрузки на кипера и данные быстро среплицировались, тут скорее вопрос про 50 ТБ данных, которые будут иметь одинаковый набор данных на всех нодах кластера. Шардированные таблицы инженера скорее всего будут переносить по партициям.
Знаю только вариант с добавлением новых шардов и созданием на них реплицированных таблиц, но смущает большой объем данных передаваемый по сети
min логично ставить
https://kb.altinity.com/altinity-kb-queries-and-syntax/ttl/ttl-group-by-examples/
но для toStartOfDay не принципиально