движком MergeTree в ней около 70 столбцов
Мне нужно различные срезы(GROUP BY) по 50ти из них, в ключ сортировки мне прописывать все 50?
И второй вопрос, знаю что наиболее часто используется 10 из них, в PRIMARY KEY указывать все 10?
Нет смысла так много колонок в ключе сортировки, обычно больше 4-5 не даёт большого эффекта, есть смысл подбирать их число по среднему количеству записей в группировке по колонкам и соотносить с index_granularity, например index_granularuty = 8192 select avg(c) from (select count() c from table group by col1) => 20000 select avg(c) from (select count() c from table group by col1, col2) => 10000 select avg(c) from (select count() c from table group by col1, col2, col3) => 5000 больше 3 колонок в данном случае большого профита не даст, так как КХ за раз читает кусками размером index_granularuty записей. Это довольно упрощённая схема подсчёта числа колонок, но суть в том чтобы добавление ещё одного столбца позволило пропускать длинные диапазоны данных. в MergeTree ключ сортировки и primary key не отличаются, это валидно для таблиц типа SummingMergeTree/AggregatingMergeTree
просто хотелось чтобы они писались упорядоченно, все таки на селект это должно влиять или все таки больше 3х не стоит?
данных читать от этого КХ меньше не будет при селектах, можно ещё пробовать уменьшить index_granularity, тогда можно увеличить число колонок. И самое главное я не говорил 3 колонки) вам надо определить это по своим данным) ну и например низкокардинальные колонки имеет смысл ставить ближе к началу, чтобы легче было пропускать блоки
благодарю такой вопрос ещё поставил таблицу buffer перед MergeTree из за частых вставок, но по кол-ву записей показывает также как и в MergeTree, так должно быть?
да, buffer под капотом сходит в mergetree и посчитает в сумме
есть какие-то подводные камни при такой схеме если буду использовать в дальнейшем Distributed и ReplicatedMergeTree?
возможно с самим буфером, если сервер упадёт, могут потеряться данные
Обсуждают сегодня