А сколько строк в день получается?
Может минутных будет достаточно остальное можно будет из них на лету считать

я бы тестировал c 2-мя hour , month , да каскадом.
4 это много , не надо умножать запись, и минутные скорее всего будут показывать тот же перфоманс что и raw

9 полей, размер таблицы 12 G,  1 818 440 840 строк

запрос на создание таблицы:

CREATE TABLE work.itz
(
   dat   DateTime CODEC(DoubleDelta, LZ4),
   magaz UInt32   CODEC(DoubleDelta, LZ4),
   tovar UInt32   CODEC(DoubleDelta, LZ4),
   kol   Int32    CODEC(DoubleDelta, LZ4),
   proc  Int8     CODEC(DoubleDelta, LZ4),
   post  UInt32   CODEC(DoubleDelta, LZ4),
   kolr  Decimal(9,2) CODEC(Gorilla, LZ4),
   srp   Decimal(9,3) CODEC(Gorilla, LZ4),
   autor LowCardinality(String),

   Дата DateTime ALIAS dat,
   Магазин UInt32 ALIAS magaz,
   Товар UInt32 ALIAS tovar,
   Количество Int32 ALIAS kol,
   ПроцентДовоза Int8 ALIAS proc,
   Поставщик UInt32 ALIAS post,
   КоличествоРасчетное Decimal(9, 2) ALIAS kolr,
   СреднедневнаяПродажа Decimal(9, 3) ALIAS srp,
   Автор LowCardinality(String) ALIAS autor,
   
 INDEX tovmag (tovar, magaz) TYPE bloom_filter() GRANULARITY 4
)
ENGINE = MergeTree()
PARTITION BY toYYYYMM(dat)
PRIMARY KEY (dat, magaz, tovar)
ORDER BY (dat, magaz, tovar)
SETTINGS index_granularity = 8192

спасибо, я попробую воспроизвести,
попробуйте в профиле default добавить output_format_parallel_formatting>0</output_format_parallel_formatting>

/report

привет
можно как-то в like передать несколько паттернов, чтобы они работали через OR?
в postgres вот так можно


name like any(array[
     'a',
     'b',
     'x%y'])

заранее спасибо

multiMatchAny

или match с regex ()|()

а там есть какие-то отличия по скорости от like, все-таки like - оператор, а multiMatchAny - функция
или без разницы?

по скорости нет разницы

спасибо

на самом деле like это тоже функция

select 'a' like 'b'
┌─like('a', 'b')─┐

и еще вопрос по поводу LowCardinality для строк

допустим, колонка с LowCardinality входит в PK, т.е. отсортирована
но уникальных значений в ней больше, чем 10_000,  может быть несколько сот тысяч
то, что колонка отсортирована, как-то помогает LowCardinality или все равно?
может быть там будет несколько словарей и за счет сортировки в них будут разные значения?

не имеет значения, в индексе хранятся сами строки

а размер и количество словарей? или то же не важно?

даже не знаю как объяснить, PK индекс вообще никак не связан с LC

есть в таблице строка : "aaaaaabbbbbbccccc"
КХ бежит по первичному ключу и находит там ключ "aaaaaabbba", этот ключ у указывает на засечку =654701
КХ идет в .mrk файл берет оттуда 8+8+8 байта по смещению 654701*24
Идет .bin и файл и читает по смещению 8, потом еще по 8, находит идентификатор словаря, и индекс в словаре
идет в словарь находит там aaaaaabbbbbbccccc, передает дальше по пайплайну.

ладно, нет PK, вопрос то не про него
вот есть просто отсортированная колонка, через order by, да, она отсортирована кусками, т.к. есть какой-то PK, но эти отсортированные куски довольно большие и содержат значительное кол-во уникальных значений, пусть это будут десятки тысяч

Т.е. данные такие  primary key (app_id), order by (app_id, low_card), или сразу primary key (app_id, low_card)
и данные там будут такие:
для app_id=1 много отсортированных строк, уникальных их пусть несклько тысяч
потом для app_id=2 много **других** отсортированных строк, других уникальных пусть тоже будет несколько тысяч
и так далее

И вопрос в том, поможет ли эта сартировка LowCardinality? Т.е. условно будет ли для каждого app_id по своему словарю?
понятно, что прямо по app_id не будет, но прмерно?

поможет.

спасибо