Почему Select Count (*) медленнее, чем Select * в улье

Когда я выполняю запросы в VirtualBox Sandbox с улей. Я чувствую, что Select count(*) слишком медленнее, чем Select *.

Кто-нибудь может объяснить, что происходит?

И почему эта задержка происходит?

Ответы

Ответ 1

select * from table

Это может быть только работа с картой Но

Select Count(*) from table

Это может быть работа с картой и сокращением

Надеюсь, что это поможет.

Ответ 2

Существует три типа операций, которые может выполнять запрос куста.

В порядке дешевле и быстрее, чем дороже и медленнее здесь.

Запрос на куст может быть запросом только для метаданных.

Показать таблицы, описать таблицу, являются примерами. В этих запросах процесс улья выполняет поиск на сервере метаданных. Сервер метаданных представляет собой базу данных SQL, возможно, MySQL, но фактическая БД настраивается.

Запрос hive может быть запросом hdfs get. Выберите * из таблицы, будет примером. В этом случае куст может возвращать результаты, выполняя операцию hdfs. hasoop fs -get, более или менее.

Запрос на улей может быть заданием сокращения карты.

Куст должен отправить банку в hdfs, jobtracker ставит в очередь задачи, tasktracker выполняет задачи, конечные данные помещаются в hdf или отправляются клиенту.

Работа по сокращению карты также имеет разные возможности.

Это может быть только работа с картой. Выберите * из таблицы, где id > 100, например, вся эта логика может быть применена к преобразователю.

Это может быть работа с картой и сокращением, Выберите min (id) из таблицы; Выберите * из порядка таблицы по id;

Это также может привести к нескольким картам Уменьшить проходы, но я думаю, что приведенное выше суммирует некоторые варианты поведения.

Ответ 3

Это связано с тем, что БД использует кластерные первичные ключи, поэтому запрос ищет каждую строку для ключа отдельно, строка из агонизирующей строки, а не из индекса.

  • Запустите optimize table. Это гарантирует, что страницы данных физически хранятся в отсортированном порядке. Это может привести к ускорению сканирование по кластерному первичному ключу.

  • создайте дополнительный не первичный индекс только для change_event_id столбец. Это сохранит копию этого столбца на индексных страницах, которые будут гораздо быстрее сканировать. После его создания проверьте план объяснения на убедитесь, что он использует новый индекс