+1 млрд записей в таблицу. ORDER BY достаточно большой, поэтому задал PRIMARY KEY по первым двум полям (типы DateTime и IPv4), т.к. выборка по ним идёт больше всего.
Знаю, что можно добавить индексов в таблицу, но не особо помогают. Может, я их неправильно готовлю, не пойму.
В среднем, запросы выполняются от 4-5 секунд, в зависимости от выбранного интервала времени. Почему грешу на индекс - вижу в SELECT count(), что вытаскивается 150 тысяч строк, а в запросе Processed 5.21 million rows, т.е. индекс явно не используется.
нужны детали, например ДДЛ таблицы и запрос
Около 10 колонок, ORDER BY включает 8 колонок, кроме двух, по которым собирается аггрегация. PRIMARY KEY строю по DateTime и IPv4 (тип колонки). Исходные данные забираю из "большой" таблицы на 35 колонок, которая MergeTree.
т.е. вы выстрелили себе в ногу положив DateTime первым в индекс?
А можете уточнить, чем это плохо?
Тем, что у вас идёт фулл скан таблицы при любом запросе
либо явно указывать рамки, чтобы сканил только одну партицию?
Я ошибся, фулл скан партиций в которые попадает WHERE dateTime
а это будет в свежих версиях КХ поправлено? 😱
А там DateTime с 10-минутными интервалами, то есть в одно такое значение DateTime мы получаем несколько млн строк, поэтому он и в индексе. Я не пойму, почему кликхаус в выборку берёт слишком много строк, индекс по DateTime-то есть.
там все очень тупо и надежно работает и там все очевидно. но всплепую, без конкретики это не объяснить
А где можно почитать про работу индексов подробнее?
Обсуждают сегодня