HBase 二級索引和備用查詢路徑

感謝平臺分享-http://bjbsair.com/2020-04-10/tech-info/53319.html

你也能夠將本文的標題理解爲「若是個人表 rowkey 看起來像這樣，但我也但願個人查詢表這樣。」 dist-list 上的一個常見示例是 row-key 格式爲「user-timestamp」格式，但對於特定時間範圍內的用戶活動有報告要求。所以，用戶選擇容易，由於它處於密鑰的主導位置，但時間不是。

沒有一個最好的方法來解決這個問題的答案，由於它取決於：

• 用戶數量
• 數據大小和數據到達率
• 報告要求的靈活性（例如，徹底特定的日期選擇與預先配置的範圍）
• 指望的查詢執行速度（例如，對於臨時報告來講90秒多是合理的，而對於其餘狀況來講可能太長）

並且解決方案也受到集羣規模和解決方案所需的處理能力的影響。常見的技巧在下面的部分中介紹。這是一個全面但並不是詳盡的方法清單。

二級索引須要額外的集羣空間和處理並不使人驚訝。這正是 RDBMS 中發生的狀況，由於建立備用索引的操做須要更新空間和處理週期。RDBMS產品在這方面更加先進，能夠處理替代索引管理。可是，HBase 在更大的數據量下能夠更好地擴展，因此這是一項功能交換。

實施這些方法時請注意 Apache HBase 性能調整。

另外，請參閱在這個 dist-list 線程 HBase，mail＃user - Stargate + hbase 中的 David Butler 響應。

HBase過濾查詢

根據具體狀況，使用客戶端請求過濾器多是適當的。在這種狀況下，不會建立二級索引。可是，請不要在應用程序（如單線程客戶端）上對這樣的大表進行全面掃描。

HBase按期更新二級索引

能夠在另外一個表中建立二級索引，經過 MapReduce 做業按期更新。該做業能夠在一天內執行，但要取決於加載策略，它可能仍然可能與主數據表不一樣步。

HBase雙寫二次索引

另外一種策略是在將數據發佈到集羣時構建二級索引（例如，寫入數據表，寫入索引表）。若是這是在數據表已經存在以後採起的方法，那麼對於具備 MapReduce 做業的二級索引將須要引導。

HBase彙總表

在時間範圍很是普遍的狀況下（例如，長達一年的報告）以及數據量大的地方，彙總表是一種常見的方法。這些將經過 MapReduce 做業生成到另外一個表中。

HBase協處理器二級索引

協處理器行爲相似於 RDBMS 觸發器。這些在 0.92 增長。