11238
Обсуждаем ClickHouse
скорее всего какая то вставка идет ибо у вас цифра только увеличивается в system.query_log смотрели, точно ли нет новых записей по данной таблице?
Читать полностью…
есть только
dictionaries_lazy_load
wait_dictionaries_load_at_startup
>но нет ли способа пропустить лукап в словарь, пока он не подгружен?
это кажется только в cached словарях
Подскажите пожалуйста по поводу подгрузки словарей, после запуска clickhouse к нему сразу будут поступать запросы на вставку данных в таблицу1, на которую навешен mat view с обогащением данных через словарь в таблицу2. Так вот если словарь большой, то запрос на вставку будет заблокирован, пока не будет полностью подгружен словарь. Можно конечно заставить clickhouse загружать словари при старте и только после этого он будет принимать соединения, но нет ли способа пропустить лукап в словарь, пока он не подгружен?
Читать полностью…
странно что у вас order by pk сломался, у нас он не ломался
Читать полностью…
вы правы, похоже какой-то баг действительно добавили в прунинге
https://fiddle.clickhouse.com/0a7c14e1-6ecb-4452-9984-5bef214b7807
дописал в issue
Не пытайтесь понять, у нас всякие миграции на целевые решения 🤡 Спасибо за ваши ответы, буду пробовать
Читать полностью…
Есть. собственно session timezone стали пробовать уже после проблемы. просто фиддл сложно сделать без него, попробую с разными ТЗ с клиентов
Читать полностью…
никто и никогда не должен пользоваться session_timezone
https://fiddle.clickhouse.com/3f650915-3d87-4f9a-a1cb-ee0a0e989c1f
она имплементирована криво и выдает хуйню в результате запросов, чинить это не хотят.
там в посте фидл =)
а у нас сервер тх бухарест, а инсерт бы сделан в НьюЙорк тз.
только вот данные то в парте в ЮТС... откуда он знает с какой ТЗ я вставлял?
а по поводу вот этого у вас есть мысли?
(как одна и та же функция может давать разный результат на один и тот же инпут)
/channel/clickhouse_ru/429811
ну вот понадобилось... но оно в целом когда клиентская таймзона другая - не работает... (я использовал session timezone потому что проще чем менять ТЗ хоста каждый раз)
Читать полностью…
зачем вам вообще с одного бакета на другой переезжать... чем старый не угодил? не в том aws аккаунте создан или что?
Читать полностью…
игры с таймзонами - они такие
Клик по умолчанию все хранит в UTC и не нужно ему мешать
Клиент клика по умолчанию распаршивает все в/из локальной ТЗ клиента. И тут тоже не нужно ничего менять.
Если нужно отображать данные во времени другого клиента, то лучше отдельно хранить таймзону клиента, записавшего данные.
Вроде уменьшается наоборот. TTL работает или дедупликаця
Читать полностью…
в данном случае таблица на одном хосте, без шардов
Читать полностью…
Добрый день!
Подскажите, мб кто сталкивался с таким поведением
Есть kafka engine: kafka_num_consumers = 6, shards = 3 (18 консьюмеров)
В какой-то момент один consumer начинает накапливать в разы больше сообщений, чем другие (например, 2 млн, в то время как на остальных 17 консьюмерах 100-200 тыс)
Ресурсы в порядке, mem, cpu, merges, ...
Ошибок в логах не обнаружено, ноды и консьюмеры всегда разные
Помогает пересоздание kafka engine - очередь накопленных сообщений расходится за 20-30 мин, хотя до этого накапливалась часами
С чем может быть связано, что можно проверить?
На других kafka engine'ах такого нет, но и нагрузка там меньше.
ClickHouse server version 24.4.2
кмк только с магией на уровне приложения, сделать 2 словаря (один директ, второй хешед или какой там у вас), и перед вставкой проверять статус хешед словаря...
Читать полностью…
еще странно что в моих последних примерах у меня ломается только toStartOfDay
т.е. toStartOfHour, ... toStartOfInterval ( , interval 1 day) не ломаются
да, собственно все эксперименты с session_timezone как я сказал начались после того как поняли что есть проблемы
если клиентская тз не совпадает с тем клиентом который вставлял при использовании use_client_time_zone true - оно ломается.
ну вы только сначала на котиках где то отдельно потренируйтесь, а не продакшене
Читать полностью…
так тоже пробовали, но explain с ним плохо дружил, сложно было понять
Читать полностью…
session_timezone влияет на CREATE TABLE (attach table), т.е. session_timezone нельзя устанавливать в сессии и в профиле, можно только в SELECT через settings
Читать полностью…
я не понял у вас проде используется session_timezone ?
есть проблема если не использовать session timezone ?
идей по сеттингам нет, возможно исправили что-то в toStartOfInterval + timezone
какая timezone у сервера?
у вас скорее всего часть кода работает с session_timezone а часть в server timezone ...
спасибо, у нас просто реалии другие
Читать полностью…
оба варианта возможны... изменение default storage policy наверное чуть проще, таблицы менять не надо...
Читать полностью…
А как вы считаете, для миграции нужно добавить в конфиг новую policy, включающую старые + новые диски, и для всех существующих таблиц прописать новую policy; или можно в старую policy просто добавить новые диски?
Читать полностью…
просто session_timezone это сплошной баг, я бы его удалил из КХ
Читать полностью…