我來自RDBMS背景，最近已經開始閱讀HBase。據我所知，沒有二級指標，我們不應該做這樣的事情：HBase：行密鑰大小
SELECT * FROM tbl_photo WHERE album_id = 1969
我在想，如果所有的信息都可以用來創建一個行密鑰本身。
例如，有一位用戶將他/她的電子郵件註冊到照片共享服務提供商。用戶可以創建一個相冊（可以創建多個相冊）並上傳照片。另一位用戶對照片進行評論，一些用戶對評論進行投票。
識別這種投票的關鍵可能看起來像email:album:ts:photo:ts:comment:ts:vote:ts。 這個鍵有意義嗎？它是否比推薦的更長？ （ts stands timestamp）
從某種意義上說，這樣做有道理，但如果您的所有信息都在您的密鑰中，您將如何存儲在列中？你會永遠能夠從客戶端應用程序的角度來形成這個關鍵嗎？ HBase架構設計是一個相當困難的話題，如果您有空閒時間，您絕對應該看看去年HBaseCon上的視頻：HBase Schema Design by Ian Varley。
就我而言，設計HBase行鍵時要記住的最重要的事情是「我將如何檢索我的數據？」。
如果（像在您的示例）想要從一個特定的相冊中的照片，爲什麼不把行鍵像email:album和讓不同列族存儲圖片，評論，...
現在，當你這樣做，你想要檢索一個特定的圖片，你必須掃描所有的相冊。所以爲了防止這種情況發生，您可以使用email:picture作爲關鍵字，但這隻會導致相同的問題。你也可以使用email:album:picture，但是如果你想從一個特定的相冊中獲得所有圖片，你應該知道圖片的標識符，否則你將無法形成你的密鑰。
在另一方面，如果用戶可以例如僅具有2000倍的照片，然後使用email:picture或email:album如鍵和指定列濾波器album或picture將不會是一個問題存在的HBase就通過一最大的2000列環這並不需要那麼長時間。
也就是說，根據您使用的HBase版本，您可以使用FuzzyRowFilter實現某種二級索引。