Два самых частых случая: 1. В таблице очень много очень узких строк. Например в таблице 10 триллионов строк и три поля 64 бит. Размер первичного индекса 100гб, он хранится в памяти, 100гб ОЗУ жалко. Он такой большой потому что много строк и гранулы 8192, увеличиваем размер гранулы в 4 раза до 32768, получаем индекс в четыре раза меньше 25гб. 2. В таблице есть aggregate functions uniq uniqmerge, т.е. ячейки таблицы очень жирные это не 64 бита а напротив 20кб. Адаптивная гранулярность в этом случае не срабатывает. Т.е. размер гранул в байтах огромен и запросы которым надо прочитать из гранулы мало строк очень тормозят потому что читают соседние строки, и запрос таким образом поднимает с диска несколько гигабайт. В этом случае надо уменьшить 8192 например до 256.
Denny, подскажи, правильно ли я понял: Если в таблице не более 300-500 млн. строк и в 99% случаев требуется отбирать практически все значения (uniqExact), то размер гранул вообще не будет играть роли?
Кайф спс, догадывался но чёткого понимания не было
Обсуждают сегодня