11238
Обсуждаем ClickHouse
никто и никогда не должен пользоваться session_timezone
https://fiddle.clickhouse.com/3f650915-3d87-4f9a-a1cb-ee0a0e989c1f
она имплементирована криво и выдает хуйню в результате запросов, чинить это не хотят.
там в посте фидл =)
а у нас сервер тх бухарест, а инсерт бы сделан в НьюЙорк тз.
только вот данные то в парте в ЮТС... откуда он знает с какой ТЗ я вставлял?
а по поводу вот этого у вас есть мысли?
(как одна и та же функция может давать разный результат на один и тот же инпут)
/channel/clickhouse_ru/429811
ну вот понадобилось... но оно в целом когда клиентская таймзона другая - не работает... (я использовал session timezone потому что проще чем менять ТЗ хоста каждый раз)
Читать полностью…
зачем вам вообще с одного бакета на другой переезжать... чем старый не угодил? не в том aws аккаунте создан или что?
Читать полностью…
игры с таймзонами - они такие
Клик по умолчанию все хранит в UTC и не нужно ему мешать
Клиент клика по умолчанию распаршивает все в/из локальной ТЗ клиента. И тут тоже не нужно ничего менять.
Если нужно отображать данные во времени другого клиента, то лучше отдельно хранить таймзону клиента, записавшего данные.
а вы реально используете session_timezone ? или это только для репро?
Читать полностью…
мы 3 года переводили всех старательно с toYYYYMMDD на toStartOfxxx, а оно сломалось...
https://github.com/ClickHouse/ClickHouse/issues/86654
@den_crane вы не встречались с такой проблемой? если да, не знаете какой experimental можно выключить или включить чтобы оно опять заработало?
Что-то подсказывает, что там еще много койчего хранится для каждой гранулы, хотя бы какая-то ссылка, как найти парт, в котором данные по этому ключу.
Читать полностью…
А парт, который мувится, доедет или нет.
Следующие ттл сработают ?
Я и сделать ничего не могу, так как мувится еще парт
Ну в индексе лежит ключ от первой строки гранулы
если ключ datetime - 4 байта и в таблице 60млрд. строк, то индекс в памяти будет 60млрд./8192*4
avgSizeof(name)+avgSizeOf(datatype)+avgSizeOf(timestamp)* 100 000 000 *50/8192
Читать полностью…
Это нормально. Это крохотные размеры для кх.
Читать полностью…
я не понял у вас проде используется session_timezone ?
есть проблема если не использовать session timezone ?
идей по сеттингам нет, возможно исправили что-то в toStartOfInterval + timezone
какая timezone у сервера?
у вас скорее всего часть кода работает с session_timezone а часть в server timezone ...
спасибо, у нас просто реалии другие
Читать полностью…
оба варианта возможны... изменение default storage policy наверное чуть проще, таблицы менять не надо...
Читать полностью…
А как вы считаете, для миграции нужно добавить в конфиг новую policy, включающую старые + новые диски, и для всех существующих таблиц прописать новую policy; или можно в старую policy просто добавить новые диски?
Читать полностью…
просто session_timezone это сплошной баг, я бы его удалил из КХ
Читать полностью…
еще вот это завезли недавно на уровень mergetree setting, при условии что в холодные данные ходят редко - самое то
https://clickhouse.com/docs/operations/settings/merge-tree-settings#use_primary_key_cache
Нет.
Там наоборот структура. Для каждого парта - все гранулы. Там оверхед скороее на выравние на размер слова. Я бы переживал только о длине name, типа если name 500 байт в среднем.
Ну и кто вам мешает взять текущий размер для 100млн и умножить на 50?
а если нет, не он продолжает висеть в system.moves
Читать полностью…
В system.replicas есть колонка last_exception
Читать полностью…
На самом деле для композитного ключа меньше, потому что современный кх, не хранит в памяти колонки следующие за грунулярной колонкой.
Читать полностью…
Не так выразился - сколько оперативной памяти потребляет одна гранула в индексе? Я так понимаю, клик весь первичный индекс держит в аамяти всегда.
Читать полностью…
Да понятно, но их через два года станет в 50 раз больше.
Сколько ожидать потребление памяти на гранулу?
https://github.com/ClickHouse/ClickHouse/issues/30236
Читать полностью…