процедура OPTIMIZE FINAL для партиции 20210320
Висит в PROCESSLIST на всём кластере.
Вызвала правильные мерджи, которые я отслеживаю в system.merges

Это я, конечно, поторопился с такими заявлениями.
Помимо очевидного и весьма вероятного "запутался", возможно и что у меня какой-то экзотический случай, из которого никакие общие выводы не следуют.

Для той же конфигурации и той же схемы даных имеются странные симптомы в работе COLUMN TTL, - про которые я Issue заводил: https://github.com/ClickHouse/ClickHouse/issues/21827

DEFAULT now() -- TTL toDate(end_datetime) + toIntervalDay(1),

now разный на репликах (это кажется баг, должно использоваться время создания таски в ZK)

Хмм... запрос (и скриншот с результатом)  относился к локальной ReplicatedMergeTree таблице. Один шард на одном из хостов. И я проверил - время на серверах кластера плюс-минус 1-2 секунды синхронизировано

тьфу блин, я имел в виду что причина Checksums of parts don't match  -- now разный на репликах (это кажется баг, должно использоваться время создания таски в ZK)

Коллеги, не могу найти поиском ответ на следующий вопрос.

Я записываю данные по сессиям проигрывания с полем id  uuid.  UUID я генерирую сам на своем софте.


Мне кажется, что будет хорошая и полезная идея первые 4 байта uuid отвести под UTC, тогда можно будет иметь осмысленную сортировку по такому id и она будет совпадать с партиционированием по датам.

Т.е. прямой поиск по таблице в которой миллиарды строк сразу подскажет в какой партиции искать.

Прямые поиски мне нужны для джойнов, потому сессии склеиваются друг с другом по полям типа  source_id

Насколько это удачная идея или я вообще её плохо описал?

Как можно подсказать кликхаусу, в какой партиции искать запись, глядя на сам ключ (это извлекается из первых 4 байт uuid в таком формате) ?

Если так, то для меня это отличная новость - потому что я опасался что что-то уже пошло не так на более фундаментальном уровне, и с потенциально значительными последствиями:)

После ошибки с Checksums (в моём случае) в ходе merge (когда они бывают, а это происходит всё же изредка), судя по логам, происходит немедленный откат: неудачный tmp_merge парт убивают. А исходные парты, для которых такая ошибка произошла, в конечном итоге  ( eventually) всё же сливаются вместе.

А не проще время рядом положить?

вот (substring(reinterpretAsString(A), 1, 4)), но я не уверен, рекомендую тестировать

create table B (A UUID, C String ) Engine=MergeTree() 
partition by (substring(reinterpretAsString(A), 1, 4))
Order by A

insert into B select generateUUIDv4(), number from numbers(10);

select _part, * from B
where A = '2b2fc98d-7dd6-4c15-824a-a673ebf846c5' 

и тестировать что прунинг работает.
В мастере работает:

set send_logs_level='debug'　;
select _part, * from B　where A = '2b2fc98d-7dd6-4c15-824a-a673ebf846c5';
Selected 1/10 parts by partition key

и проблема не в синхронизации времени, мержи могут запускаться в разное время, реплика может быть чем-то занята и запустить мерж на 5 сек позже

Я тогда Issue насчёт недоочистки column TTL столбцов создам - там это более подходит по формату. Можно систематично изложить ситуацию в целом, и более offlinе-ово (что для данной ситуации правильно).  В моём случае ничего критического или чрезвычайного.
И с сотней за сутки ошибок про Checksums, и с тем, что частично column TTL при обычных мерджах не срабатывает (но MATERIALIZE TTL это исправляет) - вполне можно жить.

А вам огромное спасибо за помощь!

создайте пожалуйста тикет с примером. Нет времени сегодня вчитываться в том что вы тут написали.

FYI тут опубликовали, может понравится: https://habr.com/en/company/rebrainme/blog/548332/

create table B (A UUID, C String ) Engine=MergeTree() 
partition by (substring(reinterpretAsString(A), 1, 4))
Order by A

insert into B select generateUUIDv4(), number from numbers(10);

select _part, * from B
where A = '2b2fc98d-7dd6-4c15-824a-a673ebf846c5' 

Идея была в том, чтобы помочь делать быстрые прямые выборки where id=Nnnn

эмммм, в общем ничего непонятно.
Вы хотите подсказать КХ в какой партиции искать и у вас таблица уже партиционирована по дате.
Или вы на этапе проектирования?
Или вы предлагаете фичу запилить в КХ?

хм, если у вас в таблице ORDER BY id кх скорее всего сам сможет это использовать.
Если этого нет, то можно попробовать minmax skip index попробовать

Спасибо 👍

Я хочу понять, насколько возможно выбрать у таблицы uuid в качестве primary key, если я смогу подсказать кликхаусу, что первые 4 байта - это время создания и значит по ним можно партиционировать

Ну вот если сделать такой uuid, то order by как раз будет иметь смысл

нормальная идея, но лучше поделить на отдельные колонки и партиционировать по первой.