hbaseで事前分割するにはどうすればよいですか?
5つのリージョンサーバーを持つhbaseにデータを保存しています。行キーとしてURLのmd5ハッシュを使用しています。現在、すべてのデータは1つのリージョンサーバーにのみ保存されています。したがって、データがすべてのリージョンサーバーに均一に送られるようにリージョンを事前に分割して、データが各リージョンサーバーに均一に送られるようにします。行キーの最初の文字としてデータを分割したい。最初の文字は0からf(16文字)まで。行キーが0から3で始まるデータと同様に、1番目のリージョンサーバー、2番目に3-6、3番目に6-9、4番目にa-d、5番目にd-fに移動します。どうすればいいですか?
テーブルの作成時にSPLITSプロパティを指定できます。
create 'tableName', 'cf1', {SPLITS => ['3','6','9','d']}
4つの分割点は5つの領域を生成します。
HBaseの DefaultLoadBalancer は、regionserver間の100%の均等な分散を保証しないことに注意してください。regionserverが同じテーブルから複数のリージョンをホストする場合があります。
それがどのように機能するかの詳細については、 this を見てください:
public List<RegionPlan> balanceCluster(Map<ServerName,List<HRegionInfo>> clusterState)
各サーバーの最も負荷の高い領域へのサーバー情報の指定されたマップに従って、グローバル負荷分散計画を生成します。負荷分散の不変条件は、すべてのサーバーがサーバーあたりの平均リージョン数の1リージョン内にあることです。平均が整数の場合、すべてのサーバーは平均に対してバランスが取られます。それ以外の場合、すべてのサーバーにはフロア(平均)またはシーリング(平均)領域があります。 HBASE-3609キューの両端からフェッチできるように、GuavaのMinMaxPriorityQueueを使用してregionsToMoveをモデル化しました。最初に、マスターによって検出されたばかりの空のリージョンサーバーがあったかどうかを確認します。その場合、regionsToMoveのヘッド/テールからそれぞれ新しい/古いリージョンを交互に選択します。この変更により、新しく検出されたリージョンサーバーで若いリージョンがクラスタリングされるのを回避できます。それ以外の場合は、regionsToMoveのヘッドから新しいリージョンを選択します。 HBASE-3609のもう1つの改善点は、regionsToMoveから負荷の少ないサーバーにラウンドロビン方式でリージョンを割り当てることです。以前は、次の過負荷サーバーに移動する前に1つの過負荷サーバーがいっぱいになり、若いリージョンのクラスタリングにつながりました。最後に、負荷が低いサーバーをランダムにシャッフルして、balanceCluster()の呼び出し全体でオフロードされた領域を比較的均等に受信するようにします。アルゴリズムは現在、次のように実装されています。
- 各サーバーが持つべき2つの有効なリージョン数、MIN = floor(average)とMAX = ceiling(average)を決定します。
- 最も負荷の高いサーバーを繰り返し処理し、各サーバーからリージョンを削除して、各サーバーが正確にMAXリージョンをホストするようにします。すでに<= MAX領域があるサーバーに到達したら停止します。リージョンを最新から最小に移動するように順序付けます。
- 負荷が最も少ないサーバーを繰り返し処理し、各サーバーが正確にMIN領域を持つように領域を割り当てます。すでにMIN領域以上のサーバーに到達したら停止します。負荷の低いサーバーに割り当てられているリージョンは、前の手順で削除されたリージョンです。過負荷の各サーバーをMINに満たすのに十分な領域が不足していない可能性があります。もしそうなら、そうするために必要な多くの地域、neededRegionsになってしまいます。また、過負荷の各サーバーを埋めることができたが、過負荷のサーバーから割り当てられていないがまだ割り当てられていないリージョンになってしまった可能性もあります。これらの条件のいずれも当てはまらない場合(過負荷のサーバーを埋めるために必要な領域がない、過負荷のサーバーから残っている領域がない)、完了して戻ります。それ以外の場合は、以下でこれらのケースを処理します。
- RequiredRegionsがゼロ以外の場合(サーバーの負荷がまだ低い場合)、最も負荷の高いサーバーを再度繰り返し、それぞれから1つのサーバーを削除します(これにより、サーバーはMAX領域からMIN領域になります)。
- これで、前の手順から、または過負荷のサーバーからの元のシェディングから、割り当てが必要なリージョンが確実に増えました。最も負荷の少ないサーバーを繰り返し、それぞれをMINまで満たします。割り当てが必要なリージョンがまだまだある場合は、負荷が最も少ないサーバーを繰り返します。今回は、サーバーがなくなるまで各サーバーを割り当てます(MAXまで埋めます)。
- これで、すべてのサーバーがMINまたはMAXリージョンをホストします。さらに、MAXリージョン以上をホストしているサーバーは、バランシングの最後にMAXリージョンになることが保証されています。これにより、可能な限り最小限の数の領域が移動されます。
TODO:最大で、特定のサーバーから離れたリージョンの数を、最も負荷が高いと報告するリージョンの数に再割り当てできます。すべての割り当てをメモリに保持する必要がありますか?異議はありますか?これは、HMasterにHeapSizeが必要であることを意味しますか?それとも注意深いモニターですか? (現在の考え方では、すべての割り当てをメモリに保持します)
すべてのデータがすでに保存されている場合は、 hbase Shell を使用して、一部のリージョンを別のリージョンサーバーに手動で移動することをお勧めします。
hbase> move ‘ENCODED_REGIONNAME’, ‘SERVER_NAME’
リージョンを移動します。オプションでターゲットリージョンサーバーを指定します。それ以外の場合はランダムに選択します。注:リージョン名ではなく、エンコードされたリージョン名を渡すため、このコマンドは他のコマンドとは少し異なります。エンコードされたリージョン名は、リージョン名のハッシュサフィックスです。リージョン名がTestTable、0094429456,1289497600452.527db22f95c8a9e0116f0cc13c680396の場合。その場合、エンコードされた領域名の部分は527db22f95c8a9e0116f0cc13c680396です。サーバー名は、そのホスト、ポート、およびスタートコードです。例:Host187.example.com、60020,1289493121758
HBaseでテーブルを作成するためにApachePhoenixを使用している場合は、CREATEステートメントでSALT_BUCKETSを指定できます。テーブルは、前述のバケットと同じ数のリージョンに分割されます。フェニックスは行キーのハッシュ(おそらく数値ハッシュ%SALT_BUCKETS)を計算し、列セルを適切な領域に割り当てます。
CREATE TABLE IF NOT EXISTS us_population (
state CHAR(2) NOT NULL,
city VARCHAR NOT NULL,
population BIGINT
CONSTRAINT my_pk PRIMARY KEY (state, city)) SALT_BUCKETS=3;
これにより、テーブルが3つのリージョンに事前に分割されます