0

データが増えたため、mysql から hbase に移行しています。

効率的なアクセス パターンの行キーを設計しています。

3つの目標を達成したい。

  1. メールアドレスのすべての結果を取得
  2. メールアドレス + item_type のすべての結果を取得
  3. 特定のメール アドレス + item_id のすべての結果を取得する

4つの属性から選択できます

  1. ユーザーの電子メール
  2. 逆タイムスタンプ
  3. item_type
  4. item_id

行を効率的に取得するには、行キーはどのように見える必要がありますか?

ありがとう

4

2 に答える 2

1

メインアクセスが電子メールによるものであると仮定すると、メインテーブルキーを電子メール+リバースタイム+ item_idとして持つことができます（item_idが一意性を与えると仮定します）

最初のテーブルにマップするキーとしてemail+item_type + reverse time+item_idとemail+item_idを含む追加の「インデックス」テーブルを作成できます（したがって、これらによる取得は2段階のプロセスです）

于 2013-03-04T04:59:42.773 に答える
0

連結された行キーに関しては、すでに正しい方向に向かっている可能性があります。いずれにせよ、投稿から次のことが思い浮かびます。

パーティショニング キーは、リバース タイムスタンプと最も頻繁にクエリされる自然キーで構成されている可能性があります。それはメールですか? そうだとしましょう: 次に、2 つ (逆タイムスタンプと電子メール) のどちらがデータの最もバランスの取れた/歪まない分散を提供するかに基づいて、プレフィックスを作成することを選択します。これにより、地域のサーバーがより快適になります。

よりバランスの取れたレコードの分布に基づいて選択します: 逆タイムスタンプと最も頻繁にクエリされる自然キー (reversetimestamp-email または email-reversetimestamp など)

そうすれば、リージョン サーバーでのホット スポットを回避できます。.

追加の (セカンダリ) インデックスで良好なパフォーマンスを得るには、まだ hbase に「焼き付けられていません」: 設計ドキュメントがあります (Wiki の SecondaryIndexing を参照)。

ただし、独自の方法をいくつか構築できます。

a) コプロセッサを使用して item_type を行キーとして書き込み、元の (user_email-reverse タイムスタンプ (またはその逆) ファクト テーブル行キーを含む列でタブールを分離します)

b) ディスク容量が問題にならない場合、および/または行が小さい場合は、そのまま行全体を 2 番目 (item-id の場合は 3 番目) のテーブルに複製します。

于 2013-03-02T23:42:17.590 に答える