使用phoenix的Hbase上哪种sql更好?

使用phoenix的Hbase上哪种sql更好?,hbase,phoenix,Hbase,Phoenix,我在Hbase上由phoenix制作了两张桌子 一个是原点日志,另一个是原点日志索引 在ORIGIN\u LOG中,键是info\u键。 在ORIGIN\u LOG\u索引中,键是(LOG\t,zone) 我们将log\u t、zone、info\u key保存在ORIGIN\u log\u索引中,这样我们就可以通过ORIGIN\u log\u索引中的log\u t和zone快速搜索info\u key。然后使用info_键,我们可以通过info_键从ORIGIN_日志获取详细日志信息,因为in

我在Hbase上由phoenix制作了两张桌子

一个是原点日志,另一个是原点日志索引

在ORIGIN\u LOG中,键是info\u键。 在ORIGIN\u LOG\u索引中,键是(LOG\t,zone)

我们将log\u t、zone、info\u key保存在ORIGIN\u log\u索引中,这样我们就可以通过ORIGIN\u log\u索引中的log\u t和zone快速搜索info\u key。然后使用info_键,我们可以通过info_键从ORIGIN_日志获取详细日志信息,因为info_键是ORIGIN_日志的键

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) |
但是当我们解释下面的sql时。我们发现需要对原始记录进行完整扫描

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) |
explain从“信息键”所在的“源日志”中选择“日志”、“应用程序版本”、“设备id”、“移动id”、“参数1”、“参数2”、“参数3”、“参数4”、“参数5”、“用户id”、“a类型”、“a tar”、“a rst”(从“源日志索引”中选择不同的“信息键”,其中“日志”>='1423956600'和“日志”='1423956600'和“日志”='1423956600'和日志<'1423956601'和区域='18')|
|客户端合并排序|
那么两个sql之间的区别是什么呢。以及哪种sql对性能更有利

多谢各位


BRs

您的第一个查询是在ORIGIN\u LOG\u索引上对HBase进行范围基扫描,然后在ORIGIN\u LOG上进行。 您的第二个查询是HBase中基于范围的扫描,其中您将为扫描提供“开始键”和“结束键”。 第二个查询要好得多,因为您避免了对另一个表的查找,并且也没有执行不同的操作。
但是,startKey和endkey范围可能跨越整个表。所以,扫描的最坏情况是“满表”扫描。
因此,我认为解释计划将其显示为一个完整的表格扫描。也许,您可以在邮件列表中要求进一步澄清。

谢谢您的回答。但事实是,第二个sql将导致rpc超时,因为ORIGIN_LOG表太大。只有第一个sql可以返回结果。
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                        |