我来自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实现某种二级索引。