первичный индекс отличный от order by?
Пытаюсь сделать, пишет
Primary key must be a prefix of the sorting key, but its length: 5 is greater than the sorting key length: 1 (version 20.9.2.20 (official build))
Таблица, в которую прилетают данные из MV, у вас, скорее всего, из семейства MergeTree. Правила создания таблицы такие же, как и для обычных MergeTree таблиц.
Ну да, я это читал. Там и написано, что первичный ключ может отличаться от ордер
Может, но должен быть частью order by, насколько я помню.
мда...Засада. Как тогда быть, использую AggregatingMergeTree, чтоб схлопывалась по одной колонке, т.е. эту колонку указывают в order by. Но мне необходимы еще индексы, получается не смогу создать
Схлопывается будет по первичному ключу. Сортировка по order by.
Что за сервисный ключ? В не вижу в доке https://clickhouse.tech/docs/ru/engines/table-engines/mergetree-family/aggregatingmergetree/
Это телефон шалит. Имелся ввиду первичный ключ.
Замкнутый круг получается. Хочу схлопывать по одному полю. Подразумевается, что по этому полю я делаю группировку в запросе при создании Mater.View Но! в запросе поля GROUP BY должны быть такими же, что и в ORDER BY при создании Mater.View. В моем случае группировка идет по одному полю...Как мне тогда добавить индексы...Надеюсь понятно расписал...
певичный ключ имею ввиду. Хочу ускорить выборку, поэтому хочу добавить поля. Но здесь схлопываются по этому ключу
Схлапывается по order by. Primary key это поля в которые будут в индексе
Если поля просто так добавить в первичный ключ, то ничего автоматически не ускорится
Никак не добавить. И смысла добавлять нету.
Смысл есть, чтоб ускорить выборку по этим ключам
Смысла нет. В тех полях недоагрегированные данные.
Но в MV в результате будут находится сагрегированные данные. т.е. результат схлопывания. Как на эти поля поставиьт какой нибудь индекс?
Для таблицы, которую я указал наверху, я создаю такой MV CREATE MATERIALIZED VIEW table_mv ENGINE = AggregatingMergeTree() PARTITION BY toStartOfWeek(created_ts) ORDER BY (id) PRIMARY KEY (id) POPULATE as select id, any(col1) as col1, any(col2) as col2, any(col3) as col3, any(col4) as col4 from table GROUP BY id; Но я хочу использовать индекс еще по полю col2. Как я понял, это сделать никак, если только создавать еще одну mv
Они никогда не аггрегированы до конца
Нельзя и не имеет смысла.
Спасибо. Похоже надо как то оптимизировать запросы с raw данными. Только возможностей не так уж много у clickhouse. Пытаюсь выкрутится за счет where in (Select ...) Так себе результаты
ну никак не надо оптимизировать. Если КХ слишком медленный для вас возьмите что-нибудь другое, например memsql, я бы точно попробовал, если бы у меня были такие странные требования
В чем странность требований?
Вам надо искать по метрикам. Все ищут по дименшинам
вам просто нужен дополнительный индекс? ну так добавьте дополнительный индекс. https://clickhouse.tech/docs/ru/sql-reference/statements/alter/index/ https://clickhouse.tech/docs/ru/engines/table-engines/mergetree-family/mergetree/#table_engine-mergetree-data_skipping-indexes
Стыдно, но я не понял о чем речь. Можно указать вектор?)
у вас ИД в индексе первым идет? а сколько дистинкт ИД возвращается из самого глубокого запроса?
Индекс наоборот последним поставил. Где то читал, что индексы нужно раставлять с большего фокуса на меньший, если так можно назвать. Насчет Ид, дофига возвращается, если брать глубокий, то падает по памяти
ну если в конце то пользы нет. а если попробовать prewhere col1=1 во внутреннем запросе вместо вот этого where ID ( IN ...... ) и замерить время только внутреннего запроса с Format Null?
По моему prewhere не подойдет, так мне необходимо найти все id и по ним схлопнуть, а col1 может иметь null. Вот такая таблица
Обсуждают сегодня