2

簡単にするために、主キーが論理的に長いテーブルがあるとしましょう。
現時点では、私が行ったプロジェクト (リレーショナル データベースを使用していた) から継承されたもので、(そのプロジェクトで) 主キーとして使用した long を返す IDMaker クラスがあります。

私が理解している限り、この ID はタイムスタンプ ベースであり、単調に増加するため、HBase 行キーの候補として適していないためです。

今、読んで、

http://ikaisays.com/2011/01/25/app-engine-datastore-tip-monotonically-increasing-values-are-bad/ http://hbase.apache.org/book/rowkey.design.html
およびLars George による「HBase: the definitive guide」の第 9 章、

「塩漬け」戦略が私のニーズに合うことがわかりました。それは基本的に私のキーにプレフィックスを追加するため、単調なシリーズを破ります。
ここで質問: このような戦略を使用して、この ID から始めます:

1
2
3
4

これらのキーが 1 つのリージョン サーバーに送られると仮定し、これらの ID を次のように変換します (もちろん、プレフィックスは一例です)。

0:1
7:2
9:3
a:4

4 つの行が同じリージョン サーバーに送信されないようにするにはどうすればよいですか? 言い換えれば、ここでうまく説明されていることを避けるために、私のプレフィックスが十分であることをどのように確認できますか-悪い/ ?

4

2 に答える 2

2

4 つの行が同じリージョン サーバーに送信されないようにするにはどうすればよいですか? 言い換えれば、ここでうまく説明されていることを回避するのに十分なプレフィックスであることをどのように確認できますか

セクション 2.5.2.7 を読みましたか。重要な構成での管理された分割は既に行われていますか?

于 2012-11-03T07:45:27.803 に答える
0

4 つの行が同じリージョン サーバーに移動しないことを確認するにはどうすればよいですか?

ハッシュ パターンに基づいてテーブルを事前に分割する必要があります。

たとえば、ソルトに 0-1-2-3-4-5-6-7-8-9-ABCDEF を使用する場合。その hbase テーブルには 16 個の分割を作成できます。各分割は、開始として 0 - 終了行として 1、開始として 1 - 終了行として 2 を持つ必要があります。これは、hbase シェルまたは Java コードから実行できます。forループを使用して多数の分割を作成できるため、Javaを好みます:)

時期尚早の最適化に関しては、分割が多すぎるとパフォーマンスに影響を与える可能性があります。

于 2015-05-27T06:32:31.000 に答える