какой sql лучше на Hbase с фениксом?

Я делаю две таблицы phoenix на Hbase.

Один ORIGIN_LOG, другой ORIGIN_LOG_INDEX.

В ORIGIN_LOG ключом является info_key. В ORIGIN_LOG_INDEX ключ (log_t, зона)

И мы сохраняем log_t, zone, info_key в ORIGIN_LOG_INDEX, чтобы мы могли очень быстро искать info_key по log_t и zone в ORIGIN_LOG_INDEX. Затем, используя info_key, мы можем получить подробную информацию журнала из ORIGIN_LOG по info_key, потому что info_key является ключом для ORIGIN_LOG.

Но когда мы объясним следующий sql. мы обнаружили, что полное сканирование ORIGIN_LOG будет стоить.

explain select "log_t", "app_ver", "device_id", "mobage_uid",     "param1","param2","param3", "param4" , "param5", "user_id", "a_typ", "a_tar", "a_rst"  from "ORIGIN_LOG" where "info_key" in (select distinct "info_key" from "ORIGIN_LOG_INDEX" where  "log_t">='1423956600' and  "log_t"<'1423956601' and  "zone" ='18')



    CLIENT 4-CHUNK PARALLEL 4-WAY FULL SCAN OVER ORIGIN_LOG 
    CLIENT MERGE SORT                        |
    |     SKIP-SCAN-JOIN TABLE 0               |
    |         CLIENT 2-CHUNK PARALLEL 2-WAY SKIP SCAN ON 2 RANGES OVER         
    ORIGIN_LOG_INDEX [0,'1423956600','18'] - [1,'1423956601','18'] |
    |             SERVER FILTER BY FIRST KEY ONLY |
    |             SERVER AGGREGATE INTO DISTINCT ROWS BY [info_key] |
    |         CLIENT MERGE SORT                |
    |     DYNAMIC SERVER FILTER BY info_key IN ($5.$7) |

Если мы используем только ORIGIN_LOG с условиями log_t и zone, как показано ниже:

select "log_t", "app_ver", "device_id", "mobage_uid", "param1","param2","param3", "param4" , "param5", "user_id", "a_typ", "a_tar", "a_rst"  from "ORIGIN_LOG"  where  "log_t">='1423956600' and  "log_t"<'1423956601' and  "zone" ='18';

Мы также получаем полное сканирование.

CLIENT 4-CHUNK PARALLEL 4-WAY FULL SCAN OVER ORIGIN_LOG |
|     SERVER FILTER BY (log_t >= '1423956600' AND log_t < '1423956601' AND  zone = '18') |
| CLIENT MERGE SORT                        |

Итак, в чем разница между двумя sql. И какой sql лучше по производительности.

Спасибо.

БР


hbase phoenix
person user1954337    schedule 15.02.2015    source источник

Ответы (1)


arrow_upward
2
arrow_downward

Ваш первый запрос — это сканирование базового диапазона HBase на ORIGIN_LOG_INDEX, а затем Gets на ORIGIN_LOG. Ваш второй запрос представляет собой сканирование на основе диапазона в HBase, где вы должны указать «начальный ключ» и «конечный ключ» для сканирования. Второй запрос намного лучше, потому что вы избегаете поиска в другой таблице, а также не выполняете отдельную операцию.
Однако вполне возможно, что диапазон startKey и endkey может охватывать всю таблицу. Итак, наихудший случай сканирования — это сканирование «FULL TABLE». Следовательно, я думаю, план объяснения показывает это как полное сканирование таблицы. Может быть, вы можете запросить в списке рассылки дополнительные разъяснения.

person Anil Gupta    schedule 16.02.2015
comment
Спасибо за ваш ответ. Но дело в том, что второй sql вызовет таймаут rpc, потому что таблица ORIGIN_LOG слишком большая. Только первый sql может вернуть результаты. - person user1954337; 16.02.2015