11

この RDBM テーブル ( Entity-attribute-value_model ) があるとします。

col1: entityID
col2: attributeName
col3: value

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

Hbase テーブルにアクセスする唯一の方法は、主キー (カーソル) を使用することです。特定のキーのカーソルを取得し、行を 1 つずつ反復できます。

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

  • 指定されたエンティティIDについて、そのすべての属性と値を取得したい
  • 特定の属性名と値に対して、すべてのentitiIDSが必要です...

したがって、私が持っていた1つのアイデアは、データを保持する1つのHbaseテーブル（エンティティIDをプライマリインデックスとして持つテーブルDATA）と、2つの「インデックス」テーブルを構築することです。

各インデックス テーブルは、DATA テーブルのポインター (entityID) のリストを保持します。

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

このブログで、著者は次のように述べています。

HBase では、主キーによる get 操作と行範囲のスキャン (カーソルを考えてください) が可能です。(スケールとセカンダリ インデックスの必要性の両方がある場合でも、心配する必要はありません。Lucene が助けてくれます! しかし、それは別の投稿です。)

Lucene がどのように役立つか知っていますか?

-- よなたん

4

2 に答える 2

5

セカンダリ インデックスは、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

于 2009-02-13T15:54:39.520 に答える
0

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

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

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

および表 2:

attribute1_value1 {
  entityID1;
}
attribute2_value2 {
  entityID1;
}
于 2013-06-04T15:00:40.493 に答える