你也可以將本文的標題理解為“如果我的表 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 增加。
閱讀更多 會飛的魚go 的文章
