3

HBaseで行IDを設計する際に、矛盾する2つのアドバイスを見てきました（具体的には、Cassandraにも当てはまると思います）。

  1. データの局所性を利用するために頻繁に集約するキーをグループ化します。（White、Hadoop：The Definitive Guideと私はHBaseサイトでそれを見たことを思い出しますが、見つけることができません...）
  2. キーを分散して、作業を複数のマシンに分散できるようにします（Twitter、Pig、およびHBase（Twitterスライド14））

どちらが最適かはユースケースによって異なると思いますが、どちらの戦略の経験もありますか？

4

1 に答える 1

2

HBaseでは、辞書式順序で並べ替えられたキースペースを分割することにより、テーブルがリージョンに分割されます。テーブルの各リージョンは単一のリージョンサーバーに属しているため、すべての読み取りと書き込みはそのサーバーによって処理されます（これにより、強力な整合性が保証されます）。これは、すべての読み取りまたは書き込みがキースペースの狭い範囲に集中している場合、単一のリージョンサーバーが処理できる範囲にしか拡張できないことを意味します。たとえば、データが時系列であり、タイムスタンプでキー設定されている場合、すべての書き込みはテーブルの最後の領域に送信され、単一のサーバーが処理できる速度での書き込みに制限されます。

一方、特定のクエリが狭い範囲の行をスキャンするだけでよく、読み取りと書き込みのセット全体がキースペース全体に分散されるようにキーを選択できる場合は、合計負荷が分散されてスケーリングされますうまくいきますが、それでもクエリのローカリティの利点を享受できます。

于 2010-07-12T23:13:21.977 に答える