Hbase スキーマをどのように設計するか?

Question

この RDBM テーブルがあるとします (エンティティの属性値のモデル):

col1: entityID
col2: attributeName
col3: value

スケーリングの問題のため、HBase を使用したいと考えています。

Hbase テーブルにアクセスする唯一の方法は主キー (カーソル) を使用することであることはわかっています。特定のキーのカーソルを取得し、行を 1 つずつ繰り返すことができます。

問題は、私の場合、3 つの列すべてを反復処理できるようにしたいことです。例えば ​​：

• 指定されたエンティティIDについて、そのすべての属性と値を取得したい
• Give AttributeNameとValueのために、私はすべての権利を求めています...

そこで私が考えたアイデアの 1 つは、データを保持する 1 つの Hbase テーブル (主インデックスとしてentityID を持つテーブル DATA) と、主キーとして属性名を持つ 1 つと値を持つ 2 つの「インデックス」テーブルを構築することです。

各インデックス テーブルには、DATA テーブルのポインター (エンティティ ID) のリストが保持されます。

それは合理的なアプローチでしょうか？それともHbaseの概念の「乱用」なのでしょうか？

この中で ブログ の 著者 言う：

HBaseを使用すると、プライマリキーとスキャンで操作を取得できます（考えてみてください：カーソル）上の列範囲。（スケールとセカンダリインデックスの必要性の両方がある場合は、心配しないでください - 救助へのルーセン！しかし、それは別の投稿です。）

Lucene がどのように役立つかご存知ですか?

-- ヨナタン

Answer 1

セカンダリ インデックスは、HBase の多くの潜在的なアプリケーションに確かに役立ちます。開発者は実際にセカンダリ インデックスに注目していると思います。チェックアウト http://www.mail-archive.com/hbase-dev@hadoop.apache.org/msg04801.html.

ただし、それまでの間、アプリケーションのデータ ストレージをスター スキーマとしてモデル化できるかどうか (「 http://en.wikipedia.org/wiki/Star_schema) セカンダリ インデックス タイプのニーズに対して Hypertable が提案するソリューションをチェックアウトするとよいでしょう。 http://markmail.org/message/rphm4q6cbar2ycgp

Answer 2

2 つの異なるフラット テーブルを用意することをお勧めします。1 つはエンティティ ID を指定して属性と値を検索するためのもので、もう 1 つは属性と値を指定してエンティティ ID を検索するためのものです。

表 1 は次のようになります。

entityID1 {
  attribute1: value1;
  attribute2: value2;
  ...
}

および表 2:

attribute1_value1 {
  entityID1;
}
attribute2_value2 {
  entityID1;
}