и как правильно его выбрать?
Сколько обычных гранул (8192 строки по дефолту) приходится на одну засечку индекса
например если я делаю индекс на visitor_id (уникальный для каждого юзера) и ~ 20млн юзеров, то сколько GRANULARITY я должен выставить?
Имейте в виду, что уменьшение гранулярности ведёт к увеличению размера индекса (который во время запроса целиком считывается в оперативку) и увеличению времени выполнения запроса. Я на выходных пробовал подбирать оптимальный index_granularity для похожей таблицы (по степени двойки перебрал значения от 8 до 16384) и ни один из вариантов не был быстрее дефолтного 8192.
index_granularity это чуть другое
А, пардон. Я всё о своей боли)
Ваша конкретная боль заключается в том, что есть блок компрессии который составляет 65к строк, и кх с диска должен прочитать именно его
Об этом не знал, пойду почитаю. Спасибо.
https://altinity.com/blog/clickhouse-in-the-storm-part-2
я сравнивал не по времени выполнения запроса Elapsed, а по количеству срок Processed — index_granularity=256. Elapsed: 0.527 sec. Processed 1.01 million rows, 58.99 MB (1.92 million rows/s., 111.95 MB/s.) index_granularity=1024. Elapsed: 0.550 sec. Processed 1.77 million rows, 72.48 MB (3.22 million rows/s., 131.87 MB/s.) index_granularity=4096. Elapsed: 0.637 sec. Processed 4.39 million rows, 116.25 MB (6.89 million rows/s., 182.42 MB/s.) index_granularity=8192. Elapsed: 0.591 sec. Processed 6.42 million rows, 147.89 MB (10.85 million rows/s., 250.06 MB/s.) получилось что у index_granularity=256 меньше всего Elapsed я так понимаю, что запрос оптимальнее использует индекс при 256
Обсуждают сегодня