Доброго времени суток, есть фундаментальный вопрос. Как может сломаться min-max

в partitione но данные быть правильными?

в какой момент это может сломаться?

таблица имеет этот clause:
PARTITION BY (operationid, toYYYYMMDDhhmmss(operationstarttimestamp))

данные и метадата парта расходяться...

select
toString((arrayDistinct(groupArray(_partition_value)) as pval).2) as part_dt,
'countIf' as "use case",
min(operationstarttimestamp) as mindt,
max(operationstarttimestamp) as maxdt,
version() chversion
from "tbl"
where "operationid" = '1a957750-bfd4-4963-b912-3aca2ad4ead4';

ответ:
Row 1:
──────
part_dt: [20220210045800]
use case: countIf
mindt: 2022-02-10 03:58:00
maxdt: 2022-02-10 03:58:00
chversion: 21.9.7.2

если сделать insert-select - все нормально, новый парт правильный...

из-за таймзоны ?

да, но непонятно как минмакс неверный а данные верные

поменяли в КХ , у нас наступил на это клиент, переливал данные

аааааааааааааааааааааааааа, а есть тикет или куда копать и где смотреть... и главное где отличить до и после )

пытаюсь вспомнить, а вы таймзону в КХ не меняли?

не, но сервер находится в ТЗ где есть summer daylight saving

для полной красоты, minmax файлы - идентичны ))) newly created part [user@host tbl]# hexdump c6835b30aa53bd4523b9ca5fc1193b36_0_0_0/minmax_operationstarttimestamp.idx 0000000 7128 6204 7128 6204 0000008 old part (broken) [user@host tbl]# hexdump 74ee8d35dfc71a4fab823c1124d089f2_0_0_0_22/minmax_operationstarttimestamp.idx 0000000 7128 6204 7128 6204 0000008

в общем проблема скорее что при вставке с клиента через http toYYYYMMDDmmss делается как то по другому (когда клиент в другой таймзоне), и получается битый partition.dat. # incorrect value [user@host tbl]# hexdump 74ee8d35dfc71a4fab823c1124d089f2_24_24_0/partition.dat 0000000 3124 3961 3735 3537 2d30 6662 3464 342d 0000010 3639 2d33 3962 3231 332d 6361 3261 6461 0000020 6534 6461 *68*34 6fe3 63e2 0012 0000 # correct value [user@host tbl]# hexdump c6835b30aa53bd4523b9ca5fc1193b36_0_0_0/partition.dat 0000000 3024 3030 3030 3030 2d30 6662 3464 342d 0000010 3639 2d33 3962 3231 332d 6361 3261 6461 0000020 6534 6461 *58*34 6fbc 63e2 0012 0000 ну и раз partition.dat учитывается в checksum - это не лечится...

короче, use-client-timezone вообще плохо работает с прунингом если в partitionkey было toYYYYMMxxxxx, и на вставке, и на селект... chserver :) select dtkey, _partition_value from default.testpartitiondat t ; SELECT dtkey, _partition_value FROM default.testpartitiondat AS t Query id: 2882d80c-020c-4e64-9c16-f72074010995 ┌───────────────dtkey─┬─_partition_value─┐ │ 2022-02-10 03:58:00 │ (20220210005800) │ └─────────────────────┴──────────────────┘ ┌───────────────dtkey─┬─_partition_value─┐ │ 2022-02-10 06:58:00 │ (20220210035800) │ └─────────────────────┴──────────────────┘ ┌───────────────dtkey─┬─_partition_value─┐ │ 2022-02-10 02:58:00 │ (20220209235800) │ └─────────────────────┴──────────────────┘ ┌───────────────dtkey─┬─_partition_value─┐ │ 2022-02-10 06:58:00 │ (20220210035800) │ └─────────────────────┴──────────────────┘ ┌───────────────dtkey─┬─_partition_value─┐ │ 2022-02-10 07:58:00 │ (20220210045800) │ └─────────────────────┴──────────────────┘ 5 rows in set. Elapsed: 0.161 sec. chserver :) select dtkey, _partition_value from default.testpartitiondat where dtkey=toDateTime('2022-02-10 02:58:00'); SELECT dtkey, _partition_value FROM default.testpartitiondat WHERE dtkey = toDateTime('2022-02-10 02:58:00') Query id: 05ca0acd-70d0-4afb-927c-4ed826dec868 Ok. 0 rows in set. Elapsed: 0.104 sec.

в общем клиент не причем, вставки все правильные. проблема при переходах в DST и назад так как partition.dat - integer. короче все эти примеры в документации с toYYYYMMHHddmmss надо бы переписать на toStartOfxxxx()

я все ещё жив, и тут вообще ещё такая проблема... почему при смене ТЗ сервера меняются данные которые считываются из таблицы если она хранит данные без ТЗ (подразумевается всегда локальная дата)?

данные хранятся в UTC, таймзона влияет на то как данные преобразуются при инсертах и селектах если у сервера или колонки задана таймзона то при инсертах datetime (строк 2022-01-01 00:00:00) они преобразуются из этой таймзоны в UTC. Т.е. у вас одни и теже значения времени из-за DST попали в разные партиции?

Я вообще только сегодня узнал что локально хранится в UTC, а не as-is (привет из других баз где по умолчанию используют 'WITHOUT TIMEZONE'). Т.е. при смене ТЗ сервера все данные будут битыми =) и что будет происходить если есть репликация между двумя таймзонами и данные падают в обе? время будет разное? о_О у нас это и произошло... вставка прошла в одну таймзону, парт создался, partition.dat записал время цифрой (toYYYYMMHHdd) парт среплицировался и запросы в другую реплику естесственно не возвращают ничего

команда КХ считает что при смене таймзоны данные не будут битыми, потому что внутри сервера как бы все UTC, это конечно не так из-за партиционирования и нигде не упомянуто что таймзону менять нельзя. >и что будет происходить если есть репликация между двумя таймзонами и данные падают в обе? время будет разное? о_О время не будет разное. Отображение в строку разное в разной таймзоне, время-то в UTC

нет, если я делаю запрос select a,b from t where dt='2021-01-01 22:00:00' в одну реплику мне вернутся данные, в другую не вернутся... потому что у серверов разные ТЗ

про partition pruning на базе toYYYYMMDDhhmmss/toHour вообще молчу

ну потому что каждая реплика '2021-01-01 22:00:00' переводит в UTC в зависимости от своей таймзоны

ну да... вот просто не с той базы копировали КХ (только mysql такой по умолчанию вроде хранящий utc). наверно надо добавить тип DateTime(unspecified). Но Алексей тут сказал что это уже так! https://github.com/ClickHouse/ClickHouse/issues/8941#issuecomment-657287867

= '2021-01-01 22:00:00' переводится из TZ сервера в UTC т.е. делаем инсерт '2021-01-01 22:00:00' -> UTC -> Таблица делаем селест where ='2021-01-01 22:00:00' -> UTC-> = время_в UTC -> для отображения конвертим в TZ сервера видим снова '2021-01-01 22:00:00'

может вам на всех репликах просто поставить TZ у КХ TGTTZ

ну да, пока так сделаем, плюс перейдем везде c toYYYYMMHH на toStartOfxxxx

но эт не решает вопроса привоза тест данных с продов с разных стран на тестбед

надо придумать как открыть FR на хранение типа DateTime(NONE) чтоб не закрыли...

все что на тех серверах где сменится ТЗ поломается ((( аксиома эскобара в действии...

А почему вы не пользуетесь UTC? Или это клиенты?

Denny, очень интересно Ваше мнение. У меня кластер 30 шардов по 2 реплики. Очень хочется иметь бекап всех данных + место для экспериментов в виде еще одного кластера, с другой конфигурацией (2 шарда по 2 реплики). Не выглядит ли выстрелом в коленку решение вида "навесим на все таблицы боевого кластера materialized view, которые будут писать в remote, смотрящий на новый кластер". Записи не так много - десятки гигабайт в сутки. Чтения на боевом кластере - несколько петабайт в сутки.

в remote не надо, у вас инсерты будут падать, если новый кластер не доступен. можно сделать distributed таблицу которая смотрит на новый кластер, и из мат.вью вставлять в нее, тогда если тестовый кластер недоступен, то проблем не будет

Большое спасибо!

данные для сенсоров по разным ТЗ разбросаны, группировать надо по локальному времени тоже обычно ну и партиционировать тоже по дням в локальном времени...