HBase二級(jí)索引和備用查詢(xún)路徑

HBase二級(jí)索引和備用查詢(xún)路徑

你也可以將本節(jié)的標(biāo)題理解為“如果我的表 rowkey 看起來(lái)像這樣，但我也希望我的查詢(xún)表這樣?！?nbsp;dist-list 上的一個(gè)常見(jiàn)示例是 row-key 格式為“user-timestamp”格式，但對(duì)于特定時(shí)間范圍內(nèi)的用戶(hù)活動(dòng)有報(bào)告要求。因此，用戶(hù)選擇容易，因?yàn)樗幱诿荑€的主導(dǎo)位置，但時(shí)間不是。

沒(méi)有一個(gè)最好的方法來(lái)解決這個(gè)問(wèn)題的答案，因?yàn)樗Q于：

• 用戶(hù)數(shù)量
• 數(shù)據(jù)大小和數(shù)據(jù)到達(dá)率
• 報(bào)告要求的靈活性（例如，完全特定的日期選擇與預(yù)先配置的范圍）
• 期望的查詢(xún)執(zhí)行速度（例如，對(duì)于臨時(shí)報(bào)告來(lái)說(shuō)90秒可能是合理的，而對(duì)于其他情況來(lái)說(shuō)可能太長(zhǎng)）

而且解決方案也受到集群規(guī)模和解決方案所需的處理能力的影響。常見(jiàn)的技巧在下面的部分中介紹。這是一個(gè)全面但并非詳盡的方法清單。

二級(jí)索引需要額外的集群空間和處理并不令人驚訝。這正是 RDBMS 中發(fā)生的情況，因?yàn)閯?chuàng)建備用索引的操作需要更新空間和處理周期。RDBMS產(chǎn)品在這方面更加先進(jìn)，可以處理替代索引管理。但是，HBase 在更大的數(shù)據(jù)量下可以更好地?cái)U(kuò)展，所以這是一項(xiàng)功能交換。

實(shí)施這些方法時(shí)請(qǐng)注意 Apache HBase 性能調(diào)整。

另外，請(qǐng)參閱在這個(gè) dist-list 線(xiàn)程 HBase，mail＃user - Stargate + hbase 中的 David Butler 響應(yīng)。

HBase過(guò)濾查詢(xún)

根據(jù)具體情況，使用客戶(hù)端請(qǐng)求過(guò)濾器可能是適當(dāng)?shù)摹Ｔ谶@種情況下，不會(huì)創(chuàng)建二級(jí)索引。但是，請(qǐng)不要在應(yīng)用程序（如單線(xiàn)程客戶(hù)端）上對(duì)這樣的大表進(jìn)行全面掃描。

HBase定期更新二級(jí)索引

可以在另一個(gè)表中創(chuàng)建二級(jí)索引，通過(guò) MapReduce 作業(yè)定期更新。該作業(yè)可以在一天內(nèi)執(zhí)行，但要取決于加載策略，它可能仍然可能與主數(shù)據(jù)表不同步。

HBase雙寫(xiě)二次索引

另一種策略是在將數(shù)據(jù)發(fā)布到集群時(shí)構(gòu)建二級(jí)索引（例如，寫(xiě)入數(shù)據(jù)表，寫(xiě)入索引表）。如果這是在數(shù)據(jù)表已經(jīng)存在之后采取的方法，那么對(duì)于具有 MapReduce 作業(yè)的二級(jí)索引將需要引導(dǎo)。

HBase匯總表

在時(shí)間范圍非常廣泛的情況下（例如，長(zhǎng)達(dá)一年的報(bào)告）以及數(shù)據(jù)量大的地方，匯總表是一種常見(jiàn)的方法。這些將通過(guò) MapReduce 作業(yè)生成到另一個(gè)表中。

HBase協(xié)處理器二級(jí)索引

協(xié)處理器行為類(lèi)似于 RDBMS 觸發(fā)器。這些在 0.92 增加。