Добрый день. Столкнулась с вопросом, как выбрать order by для таблицы

в Clickhouse.

Допустим, есть транзакционная таблица. Как такового, primary key у нее нет.

Допустим, данные вносятся ежемесячно.

Как должно быть:

Mergetree order by <перечень ключевых полей> partition by <дата>

или

Mergetree order by tuple() partition by <дата>

или просто

Mergetree partition by <дата>

От чего зависит выбор ключа order by?

Если есть хорошие ссылки, поделитесь пожалуйста.

Наверное я бы посоветовал ещё разочек прочитать доку и понять что такое PK Order BY и Partition by

Ну и первый вариант самый нормальный, но партиции можно по месячные сделать

https://kb.altinity.com/engines/mergetree-table-engine-family/pick-keys/

Привет, вот тут написано For Summing / Aggregating  All dimensions go to ORDER BY, all metrics - outside of that. The most important for filtering columns with the lowest cardinality should be the left most. If number of dimensions is high it’s typically make sense to use a prefix of ORDER BY as a PRIMARY KEY to avoid polluting sparse index. Не могу понять, как перечисление в Primary key тех же самых полей, что и в Order by поможет avoid polluting sparse index. Что означает avoid polluting sparse index? Как изменится логика, если поля агрегации будут перечислены только в order by или же и там, и в Primary key? Поля фильтрации достаточно перечислить только в order by?

IMHO иееется ввиду разреженные значения индекса, когда у вас значения в кусках данных случайно распределены ... и поэтому сканирование замедляется потому что сжатие хуже PRIMARY KEY это основные поля ускоряющие выборку если они есть в WHERE а ORDER BY обязан содержать все из PRIMARY KEY но дополнительно может содержать еще поля, которые будут учавствоваоть в сортировке и за счет этого колонки которые не входят в PRIMARY KEY могут сжиматься лучше

Спасибо! А collapsing (второй вопрос) не подскажете?

В primary key низко кардинальные поля По возрастанию кардинальному 3-4 поля обычно достаточно остальное обычно не имеет смысла В order by Все из primary И дор поля для которых сортировка приведёт к улучшенному сжатию Не надо туда все поля писать Если primary не указан он берётся из order by в create table

Агрегирующий движок тупо делает агрегацию Для всех строк Хранит не результат агрегации а внутренние состояния чтобы потом в select доагрегировать можно было

use a prefix of ORDER BY as a PRIMARY KEY to avoid polluting sparse index имеется ввиду что полей в orderby у summingMergeTree может быть много, типа 50, а в PRIMARY KEY добавлять стоит только 3 первых (префикс), таким образом 47 полей не будут загрязнять индекс, индекс будет маленьким в размере и займет небольшое кол-во ОЗУ и места на диске, в любом случае в индексе не имеет смысла хранить больше 5 полей (из опыта).

спасибо большое! понятно :)

:) спасибо, все понятно!