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

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

0 голосов
/ 28 февраля 2019

У меня есть первичный ключ, состоящий из трех столбцов (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, но я не уверенесли это было выпущено или нет

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

1 Ответ

0 голосов
/ 04 марта 2019

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

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

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

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

Обновление Согласно ответу от dev@kudu.apache.org

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

...