私は RDBMS のバックグラウンドを持っており、最近 HBase を読み始めました。セカンダリ インデックスがないことは理解しており、次のようなことを行うべきではありません。
SELECT * FROM tbl_photo WHERE album_id = 1969
すべての情報を使用して行キー自体を作成できるかどうか疑問に思っていました。
たとえば。写真共有サービスにメール登録しているユーザーがいます。ユーザーはアルバムを作成し（複数のアルバムを作成できます）、写真をアップロードできます。別のユーザーが写真にコメントし、何人かのユーザーがコメントに賛成/反対の投票をします。
そのような投票を識別するためのキーは のようになりemail:album:ts:photo:ts:comment:ts:vote:tsます。このキーは意味がありますか? 推奨より長いですか？( ts stands timestamp)
ある意味ではこれは理にかなっていますが、すべての情報がキーに含まれている場合、列に何を保存しますか? また、クライアント アプリケーションの観点から常にそのキーを作成できますか? HBase スキーマの設計は非常に難しいトピックです。時間がある場合は、昨年の HBaseCon のビデオ(Ian Varley による HBase Schema Design ) を必ずご覧ください。
私が考える限り、HBase の行キーを設計する際に留意すべき最も重要なことは、「データをどのように取得するか」ということです。
（あなたの例のように）特定のアルバムから写真を取得したい場合は、行キーを次のようemail:albumにして、さまざまな列ファミリーに写真、コメントなどを保存させてみませんか...
そのようにして特定の写真を取得したい場合は、すべてのアルバムをスキャンする必要があります。したがって、これを防ぐために代わりに as key を使用できますemail:pictureが、これは逆に同じ問題を引き起こすだけです。を使用することもできますemail:album:pictureが、特定のアルバムからすべての写真を取得したい場合は、写真の識別子を知っている必要があります。そうしないと、キーを作成できません。
一方、ユーザーがたとえば 2000 枚の写真しか持てない場合、email:pictureorをキーとして使用し、 oremail:albumの列フィルターを指定しても問題はありません。HBase は最大 2000 行をループしますが、それほど時間はかかりません。albumpicture
そうは言っても、使用している HBase のバージョンによっては、 FuzzyRowFilterを使用してある種のセカンダリ インデックスを実装できます。