11238
Обсуждаем ClickHouse
там все время улучшают, но суть в том что DateTime64 это децимал и там в общем случае нужна точка (dot) , чтобы отделить дробную часть от целой части секунд
т.е. либо 1759496469.555 либо 2025-10-03 15:01:54.555
но в разных версиях по разному, КХ пытаются научить угадывать что имелось в виду под 1759496469555 -- это наносекунды или секунды, но это типа тут работает (insert values), а вот тут не работает (insert csv).
Привет! Вставляю из другой базы в кликхаус таймстемпы
Поле в которое вставляю названо так же timestamp, тип данных выставил DateTime64(N)
При N от 3 до 8 данные вставляются, однако кастятся не верно
Дело в том, что таймстемпы даны с точностью до наносекунд (например 1642435541563013422) и для них N от 3 до 8 неверно интерпретируется.
Но при DateTime64(9) - появляется ошибка:
Decimal math overflow: while converting source column timestamp to destination column timestamp: while executing 'FUNCTION _CAST(timestamp :: 6, DateTime64(9) :: 21) -> _CAST(timestamp, DateTime64(9)) DateTime64(9)
У нас самописный, если инсталляция одна и под одним VPN то достаточно Airflow. У нас много в разных регионах под разными VPN, по этому пришлось сделать свой
Читать полностью…
https://kb.altinity.com/altinity-kb-integrations/altinity-kb-kafka/error-handling/
Читать полностью…
скип индекс у меня в файловом кеше висит in its entirety (я надеюсь; памяти с запасом и я повторяю запрос пока время выполнения не выровняется по нижней границе). остаётся только его распаковать, если он запакован
а что за кеш? query condition? я не могу найти ничего про dedicated skip index cache.
гранулярность надо попробовать.. у меня колонка почти из конца списка order by, дальше только таймстемп, интуиция говорит что станет хуже (но что-то она подводит пока :D)
та нет обычно никакой проблемы написать select так чтобы не было ошибок, для практически всего есть OrZero , OrNull
не можем распарсить, пишем Null или 0
да (скип индекс дорого загружать с диска), помогает использовать либо кеш на skip индексы, либо гранулярность побольше, я недавно поменял у minmax скип индекса гранулярность с 10 на 100, так сразу буст и во времени анализа запроса и в использованном cpu (особенно порадовал cpu, раз в 10 меньше стало использоваться) (кеша на скип индексы в той версии еще нет)
Читать полностью…
но селект с таким индексом работает медленнее, чем если его временно отключить
Читать полностью…
обычно люди не хотят терять данные. Но если вам пофиг, то почему бы и нет
Читать полностью…
Спасибо! Это вообще более-менее нормальная практика - ставить игнор ошибкам матвью?
Читать полностью…
так тоже можно. Но лучше нет.
https://kb.altinity.com/altinity-kb-integrations/altinity-kb-kafka/altinity-kb-kafka-main-parsing-loop/#disable-at-least-once-delivery
Коллеги, есть вопрос, как обойти известную проблему поломки вычитке из кафки при сбое парсинга на "конвейере дальше"?
Вкратце: Клик вычитывает топик кафки, складывает данные в Replicated-таблицу. Далее, к этой таблице присоединена матвью, которая парсит поля из Replicated-таблицы и складывает в отдельную таблицу. И вот матвью, в части парсинга, может выдавать ошибки - например, скрипт написан с ошибочной логикой, или скрипт ожидает один тип данных, а приходит другой (допустим, что проблему несоответствия данных со стороны источника мы пока решить не можем). И мы видим, что в случае ошибки работы матвью вылетает exception, при этом данные, естественно, в последнюю таблицу не перекладываются, но это полбеды. Основная проблема в том, что этот сбой парсинга интерпретируется в системе в целом как сбой всего конвейера "вычитка из топика - сохранение в таблицу - парсинг на матвью - перекладка во вторую таблицу", и коммит офсета в Кафку также завершается с ошибкой. Поскольку вычитка не закоммичена, идёт повторная вычитка из Кафки тех же данных, происходит повторная ошибка, и т.д. Вычитка тормозится, лаг растёт, всё ломается.
Так вот, вопрос: можно ли как-то в Clickhouse сделать ограничение, чтобы коммит офсета в кафку происходил уже на этапе "первичного" сохранения данных в Replicated-таблице? Т.е. вот эта фаза завершена успешно, читай следующий блок данных из топика, а что там будет с ними дальше, пусть на кафку не влияет.
Либо как вариант - можно ли настроить матвью, чтобы в результате эксепшена на матвью сбойная запись дропалась, но для Replicated таблицы и Kafka Engine это не было бы ошибкой, которая приводила бы к перевычитке. Т.е. это потеря данных, и это плохо, но даже такой результат будет лучше, чем перевычитка.
Привет! Нашли причину? У нас такая же ситуация, куда копать не знаем пока.
Читать полностью…
for future reference: в пару к index_mark_cache_size, есть метрика IndexMarkCacheBytes, чтобы понять не пора ли его бампнуть
Читать полностью…
@den_crane в чате не хватает реакций конечно. большое агрегированное спасибо за ваши рассказы!
Читать полностью…
Коллеги, подскажите пожалуйста!!. Какие действия для удаления таблицы?. Была таблица репликации. Её переименовали. Её надо грохнуть
Читать полностью…
ага, вариант со скриптом по таймеру в голову приходил - получается, тоже рабочий вариант. а кстати, раз уж пошло (это у нас отдельная тема изысканий, простите 😁) - а шедулер какой используете?
Читать полностью…
Примерно так, но я еще ставлю один MV вначале, который тупо вычитыввет топик.
Дальше в зависимости от нагрузки, либо как тут показано через два мат вью, либо вообще тупо скриптом по таймеру перекладываю и обрабатываю ошибки.
Если нагрузка небольшая, скрипт стабильнее и легче модифицировать
<!-- <index_mark_cache_size>5368709120</index_mark_cache_size> -->
а хотя он включен по дефолту
select * from system.server_settings where name like 'index_mark_cache_size';
Полностью согласен. Мы и источник, к сожалению, не до конца контролируем, и парсинг не всегда делается умелыми специалистами. Сейчас вводим код-ревью и обязательное применение ...OrZero и подобного. Но хотелось бы и вот с этой стороны подстраховаться.
Читать полностью…
подскажите, а как вы отвязали ошибки матвью от вычитки?
Читать полностью…
это ожидаемо, особенно если индекс не на лидирующее поле, из pk индекса нельзя узнать последнее значение в грануле, только первое
Читать полностью…
что-то у меня на индексы никак не отрастёт интуиция.
ожидание: если у меня есть колонка в первичном ключе, добавление minmax индекса по ней-же не будет прюнить гранулы никак,
реальность:
вот не совсем понимаю, почему нет. Вы не могли бы чуть пояснить? Разве будет плохо, если мы отвяжем этап парсинга от этапа вычитки и первичного сохранения?
Читать полностью…
Я складываю каждую строку отдельно как json, а потом через мат вью перекладываю в нормальную структуру и формирую DLQ через второй мат вью.
Читать полностью…
идете в доку, жамкаете AskAI, пишите how to ingore error from matview, получаете materialized_views_ignore_errors
Читать полностью…
треды посчитайте чем у вас clickhouse занят
Thread counts by type (using ps & clickhouse-local)
https://kb.altinity.com/altinity-kb-setup-and-maintenance/altinity-kb-threads/
Привет!) Посоветуйте, что почитать по партиционирование - интересует подробное описание механизмов/алгоритмов и настроек. Проблема такая - в какой-то момент слишком много партов образуется (льется стрим построчный и разбирается материалками).
Читать полностью…