Использование частей первичного ключа для улучшения поиска в KUDU

У меня есть первичный ключ, состоящий из трех столбцов (id_grandparent, id_parent, id_row), который находится в KUDU.

Я хочу, чтобы мой поиск был быстрым (как в hbase) при поиске по id_grandparent. Я использую Impala и Spark для поиска, давайте предположим, что они оба выполняют выталкивание предиката на равенство.

У меня есть вопросы, в которых я не могу ответить на 100%, читая документацию

SELECT * FROM my_table where id_grandparent = 55

Сможет ли этот запрос использовать индексный порядок, даже если я не предоставлю весь первичный ключ? (он же мега-быстрый возврат). Я предполагаю, что да, потому что я предполагаю, что первичный ключ отсортирован по первому столбцу, и это своего рода префиксное сканирование

SELECT * FROM my_table where id_parent = 55

Будет ли в этом запросе использоваться какая-либо оптимизация? Или любой столбец, отличный от первого (если первый столбец не указан), приведет к полному сканированию всех планшетов.

Я читал об этом здесь: https://kudu.apache.org/2018/09/26/index-skip-scan-optimization-in-kudu.html, но я не уверен, выпущено это или нет

Заранее спасибо!


apache-kudu
person BiS    schedule 28.02.2019    source источник

Ответы (1)


arrow_upward
1
arrow_downward

Согласно этот билет JIRA, он все еще находится на рассмотрении.

Согласно этой документации (последняя версия на момент этого ответа)

При сканировании многоуровневых секционированных таблиц можно использовать сокращение секций на любом из уровней независимо.

Однако я сомневаюсь, что сканирование с пропуском индекса еще не реализовано, учитывая сообщение в блоге было написано всего несколько месяцев назад.

Обновление Согласно ответу от [email protected]

К сожалению, стажировка первоначального автора закончилась прошлым летом, и никто не нашел времени на завершение работы. Это определенно ускорит некоторые типы запросов. Однако есть некоторые опасения, что в текущем состоянии это может вызвать снижение производительности для некоторых запросов. Вероятно, он может выиграть от улучшений эвристики, которую он использует, чтобы решить, когда включать оптимизацию пропуска сканирования.

person shanmuga    schedule 04.03.2019