TL; DR： HBase（BigTableのような）のように見え、ルックアップを行うためにB+ツリーに似た構造として使用します。したがって、行キーはプライマリインデックスです（デフォルトでは、HBase内のあらゆる種類の唯一のインデックスです）。
長い答え： HBase書き込みパスに関するこのClouderaブログ投稿から、HBaseは次のように動作するようです。
各HBaseテーブルは、次の3つのカテゴリに分類されるサーバーのセットによってホストおよび管理されます。
- 1つのアクティブなマスターサーバー
- 1つ以上のバックアップマスターサーバー
- 多くのリージョンサーバー
リージョンサーバーは、HBaseテーブルの処理に貢献します。HBaseテーブルは大きくなる可能性があるため、リージョンと呼ばれるパーティションに分割されます。各リージョンサーバーは、これらのリージョンの1つ以上を処理します。
次の段落でもう少し詳しく説明します。
行キーはソートされているため、どのリージョンサーバーがどのキーを管理しているかを簡単に判断できます。...各行キーは、リージョンサーバーによって提供される特定のリージョンに属しています。したがって、putまたはdeleteのキーに基づいて、HBaseクライアントは適切なリージョンサーバーを見つけることができます。最初に、ZooKeeperクォーラムから-ROOT-リージョンをホストしているリージョンサーバーのアドレスを見つけます。クライアントは、ルートリージョンサーバーから、-META-リージョンをホストしているリージョンサーバーの場所を見つけます。メタリージョンサーバーから、要求されたリージョンにサービスを提供する実際のリージョンサーバーを最終的に見つけます。これは3ステップのプロセスであるため、この高価な一連の操作を回避するために、リージョンの場所がキャッシュされます。
別のClouderaブログ投稿から、ファイルシステムにHBaseを保存するために使用される正確な形式は変化し続けているように見えますが、行キールックアップの上記のメカニズムは多かれ少なかれ一貫しているはずです。
このメカニズムは、3レベルの階層を使用して行キーの場所を照会するGoogle BigTableのルックアップ（詳細はPDFの4ページの終わりから始まるセクション5.1にあります）と非常によく似ています。ルートタブレット->METADATAタブレット->実際のタブレット
更新：Region Server自体の内部のルックアップに関する質問に答える：確かにはわかりませんが、行キーが並べ替えられており、HBaseが開始キーと終了キーを知っているため、バイナリ検索または補間検索を使用していると思われます、どちらも非常に高速です。それぞれlog（n）とlog（log（n））です。ソートされたキーの検索はいくつかの効率的な解決策があるよく知られた問題であるため、HBaseが開始行キーから検索する必要のある行まで行をスキャンする必要はないと思います。