могли бы вы помочь слепцу в поисках истинны среди всяческого индексированного добра.
Что есть: огромная реплицированная таблица с 10 млрд линий и около 100 колонок. Есть партицирование ее по дате и одному инту(назовем его комит_ид), сортировка по двум стрингам и еще одному инту. Первичный ключ не указан. Сделанно специально, чтобы оптимизировать некоторые запросы типа SELECT. Теперь появились новые запросы в соторые еще добавились сравнение на равенство по колонки типа ЮИнт64 (который некий хэш) и один Инт8 у которого 2 значения : +1 или -1. По ключу сортировки и партиции тоже сравнение на равенство.
Проблема: впечатление, что КХ сканирует все, так как запрос производится в течение 20 с. Попытался добавить минмакс индекс и блум-филтер. Переоптимизировал таблицу. Время не улучшилось, а иногда в некоторых вариантах ухудшилось.
Вопрос: у кого естль луч света в царстве индексирования данных и оптимизации? Заранее благодарен
единственный случай когда вам помогут скип индексы это когда у вас есть какая то локальность данных(те что учавствуют в скип индексе), с учетом ORDER BY таблицы
я бот, но имхо нету. если ваш хеш не привязан к сортировке (локальность выше) скип индексы в мусорку. рекомендую попробовать добавить ваш хеш в конец вашей сортировки, или перед комит-ид может помочь и проверить на саб-сете данных
ещё если у вас ожидается ответ от одной/нескольких строк по хешу попробуйте prewhere. нам помогало
еще есть вариант сделать партишны по (дата, бакет-хешей), т.е. бьёте на 20 бакетов каждую партицию по префиксу хеша, и запросы делают меньшие фулсканы
таблица ORDER BY str1,str2,int1 Но судя из описания были у вас запросы WHERE str1='' and str2='' and int1 = 3 а теперь появились WHERE str1='' and str2='' and int1 = 3 and hash = '' and int2 = 1 или WHERE hash = '' and int2 = 1
Обсуждают сегодня