HBase の機能原理、設計思想、アーキテクチャ設計、ソース コード分析

著者: 禅とコンピュータープログラミングの芸術

1 はじめに

1.1 HBase とは何ですか?
HBase は、Apache Foundation の下にあるオープン ソースの NoSQL データ ストレージ システムです。Hadoop 環境で実行でき、高信頼性、高性能のデータ読み取りおよび書き込みサービスを提供します。HBase は列ファミリーの柔軟な構造を持ち、大量のデータのランダム クエリをサポートし、さまざまな非リレーショナル データ分析シナリオに適しています。
2007 年の Apache のトップ プロジェクトの 1 つである Hadoop の開発から、近年の衰退、そして現在は Apache インキュベーターに参入するまで、HBase は商業的利益とユーザー ニーズの点でユニークなオープン ソース製品になりました。
1.2 なぜ HBase ソース コードを学ぶ必要があるのですか?
HBase の基本知識を学んだ後は、その設計思想、アーキテクチャ設計、ソース コードをさらに理解する必要があります。HBase のソース コードを学習すると、HBase の動作メカニズムをより深く理解できるようになり、開発への理解も深まります。たとえば、Java 言語には精通しているが、Hadoop、Zookeeper、HDFS には精通していない初心者の場合、HBase のソース コードを読むと、HBase の基本アーキテクチャと原則をすぐに理解できます。さらに、HBase は Java で開発されており、HBase コードを理解するには Java 言語の知識が不可欠であるため、HBase のソース コードを読むことが一部の開発者にとって役立つ場合があります。
1.3 この一連のチュートリアルの学習目標
この一連のチュートリアルは、主に HBase のソース コードの学習に焦点を当てており、HBase の機能原理、設計思想、アーキテクチャ設計、およびソース コードの分析を通じて、読者が HBase と HBase についてより深く理解するのに役立ちます。学んだ知識を応用し、実際の問題を解決できるようになります。具体的な学習目標は次のとおりです。

  • HBase の機能概要と特徴を理解します。
  • クラスター アーキテクチャ、データ モデル、テーブル設計、シャーディング戦略など、HBase の動作原理をマスターします。
  • HBase の Java API とその実装原則について学びます。
  • ロード バランシング、RegionServer の分割とマージ、データ整合性プロトコル、トランザクション処理など、HBase の内部メカニズムについての深い理解。
  • ソースコードを読んで練習することで、プログラミングのスキルを高めます。

2. 中心となる概念と用語

2.1 基本概念

2.1.1 NoSQL

NoSQL (Not Only SQL) とは「SQL だけではない」という意味で、非リレーショナル データベースを指します。従来のリレーショナル データベースとは異なり、NoSQL はデータの保存と計算を分離し、データをより柔軟に拡張しやすくします。NoSQL はデータをキーと値のペアの形式で保存し、対応する値は単純なキーを通じて取得できます。NoSQL は、キーと値の形式により、事前定義されたスキーマを必要とせずに、さまざまな種類のデータを多数保存できます。一般に、NoSQL は、Apache Cassandra、MongoDB、Redis などの分散キー値データベースを構築するために使用されます。

2.1.2 ハドゥープ

Hadoop は、基盤となるハードウェア リソースを統合し、シンプルで統一された一連の操作を提供するフレームワークです。Hadoop を通じて、大規模なデータ セットの分散コンピューティングとストレージを実現できます。Hadoop には、HDFS、MapReduce、YARN という 3 つの柱があります。HDFS (Hadoop Distributed File System) は、大容量のファイルを保存するために使用される分散ファイル システムです。MapReduce (Hadoop Map Reduce) は、ユーザーが Map および Reduce ベースのジョブを同時または順次に作成できるようにする分散コンピューティング フレームワークです。YARN (Yet Another Resource Negotiator) は、クラスター リソースを割り当てるために使用されるリソース管理フレームワークです。

2.1.3 HBase

HBase は、Apache Foundation の下で Hadoop によって開発されたオープン ソースの NoSQL データ ストレージ システムです。HBase は、分散型、スケーラブル、低遅延、高スループットのストレージとアクセス機能を提供し、分散環境での大規模なデータ ストレージとクエリに適しています。HBase は、カラム ファミリー ストレージ、バッチ書き込み、リアルタイム クエリなどの機能をサポートしており、基盤となるストレージとして Hadoop の HDFS ファイル システムを使用しており、Hadoop 上の既存のサーバー クラスターを直接利用できます。

2.1.4 ビッグテーブル

Google の Bigtable は NoSQL データベースであり、構造化データ、半構造化データ、非構造化データの保存に使用される分散構造化データ ストレージです。Bigtable の設計コンセプトは、行、列、タイムスタンプに従ってデータを分割し、高可用性と高パフォーマンスを確保することです。そのストレージ アーキテクチャは Hadoop の HDFS に似ています。Bigtable には、リレーショナル データベースのように特定の列を検索できないなど、いくつかの制限がありますが、その利点は効率性、スケーラビリティ、信頼性です。

2.1.5 カサンドラ

Apache Cassandra は Facebook が提案するオープンソースの分散型 NoSQL データベースであり、代表的な NoSQL データベースの 1 つです。Cassandra は、高可用性、分散、柔軟なスケーリング、および強力な整合性をサポートします。これはレプリケーションに基づくマルチマスター モデル (つまり、各ノードが読み取りおよび書き込みリクエストを受信できる) であり、高スループットと低遅延を実現します。Cassandra は Java 言語で開発されており、非常に柔軟で使いやすいです。これは現在、Apache Foundation のトップレベルのプロジェクトとなっています。

2.1.6 ハイパーテーブル

Hypertable は、Pinterest によって開発された分散型インメモリ コンピューティング NoSQL データベースです。Hypertable はデータをメモリに保存し、SSD を介して高い読み取りおよび書き込み速度を提供します。高可用性、データ セキュリティ、ACID トランザクション、スプリット ホライズン、レプリケーションをサポートします。そのストレージ アーキテクチャは Hadoop の HDFS に似ています。Hypertable は、Google の F1 論文の設計概念を活用し、そのアーキテクチャに独自の B+Tree インデックス方式を採用しています。

2.1.7 Memcached

Memcached は、高性能の分散メモリ オブジェクト キャッシング システムです。Danga Interactive によって最初に開発された Memcached は、キャッシュまたはセッション ストレージに使用される高性能メモリ キー/値ストレージ システムです。その高いパフォーマンスはメモリに格納される memcached によって実現されるため、高速であり、マルチスレッド アプリケーションに適しています。libevent ベースのイベント駆動型モデルをサポートします。Memcached は BSD プロトコルを利用し、シンプルで軽量のメッセージ受け渡しメカニズムを使用します。現在は Linux オペレーティング システムのサービスとなっています。

2.1.8 Redis

Redis は、オープンソースの高性能キー/値データベースです。データ永続性、マスター/スレーブ同期、HA およびその他の機能をサポートします。これは、文字列、ハッシュ、リスト、セット、順序付きセットなどのデータ型をサポートするメモリベースの高性能キー/値データベースであり、キャッシュ、メッセージ キュー、カウンター、ランキングなどのシナリオで使用できます。C言語で開発されており、非常に高性能です。Redis は本質的に大規模なデータを指向しており、1 秒あたり 100,000 を超えるリクエストを処理できます。現在、Redis は最も人気のある NoSQL データベースになりつつあります。

2.2 データモデルとテーブルの設計

HBase データ モデルは、テーブルの概念を持つ従来のリレーショナル データベースに似ています。各テーブルは複数の列で構成され、各列は列ファミリー (列ファミリー) に対応します。各行はロウキー(Row Key)に対応しており、その行のデータを一意に決定します。HBase には 2 種類の列ファミリーがあります。

  • 主列ファミリー: 主キー列ファミリーは 1 つだけ存在でき、通常は「cf」という名前が付けられます。この列ファミリーの目的は並べ替えと範囲スキャンであるため、すべてのテーブルには主キー列ファミリーが必要です。
  • その他の列ファミリー (非主列ファミリー): 主キー以外のデータを格納するために使用される他の列ファミリーが複数存在する場合があります。
    各列ファミリーには、NULL 値を含む任意の量のデータを格納できます。各行のすべての列ファミリーのデータが一緒に保存されます。行キー、列ファミリー、列修飾子を使用してデータを検索します。

2.3 HDFS アーキテクチャ

HDFS (Hadoop Distributed File System) は、高い耐障害性と高スループットのファイル ストレージ サービスを提供する分散ファイル システムです。HDFS は、Hadoop プロジェクトのサブプロジェクトです。HDFS は、NameNode と DataNode という 2 つの主要コンポーネントで構成されます。NameNode はファイル システムの名前空間の管理を担当し、単一障害点となります。DataNode はファイル データ ブロックを保存します。HDFS はファイルのランダムな読み取りと書き込みをサポートします。HDFS は大量のファイルを保存するように設計されていますが、ファイルのランダムな変更はサポートされていません。すべてのデータはブロックに保存され、ファイル システムはストリームの形式でデータにアクセスします。HDFS は、高いフォールト トレランス、高い信頼性、自動ラック認識機能を備えています。
HDFS には次の重要な機能があります。

  • 高いフォールト トレランス: HDFS はマスター/スレーブ アーキテクチャを使用して高いフォールト トレランスを提供し、データノードに障害が発生すると、他のデータノードがその作業を引き継ぎ、サービスを提供し続けます。
  • 高スループット: HDFS は、高スループットで大量の読み取りおよび書き込みリクエストを処理できます。
  • 信頼性の高いデータ送信: HDFS は独自に展開された TCP/IP 接続を使用し、データは CRC 検証を通じて送信されます。
  • バッチ処理に適しています: HDFS は、変更されない多数の小さなファイルを保存するように設計されており、バッチ処理に適しています。

2.4 ズーキーパー

Apache Zookeeper は、Apache Hadoop プロジェクトのサブプロジェクトであり、分散型共同サービスです。分散アプリケーションに一貫性サービスを提供します。Zookeeper は、分散プロセスの正確性を保証するために使用されます。これは、構成保守、ドメイン名サービス、ソフト ルーティング、フェイルオーバー、通知などを含む、分散アプリケーション向けのさまざまな機能を提供するオープンソースの分散調整ツールです。Zookeeper の役割は、分散システムで構成ファイルを維持し、ノードが生きているかどうかを検出し、クラスター情報の一貫性を維持するために他のサーバーに通知することです。Zookeeper の動作モードは、Zookeeper サービスと呼ばれるサーバーのグループに依存します。Zookeeper サービスは通常、マスター サーバーと複数のスレーブ サーバーで構成されます。マスター サーバーに障害が発生すると、Zookeeper は新しいマスター サーバーを選択します。システム全体は結果整合性を保証します。これは、すべてのサーバーのステータスが最終的に一貫した状態に達することを意味します。

3. 設計原則

3.1 分散設計

HBase は分散データベースです。これはスタンドアロンのデータベースではなく、複数のサーバーで構成される分散システムです。可用性の高い分散サービスを提供します。HBase は水平方向に拡張できるため、ノードを追加することでサービスのパフォーマンスを向上させることができます。HBase にはマスター ノードがあり、RegionServer のステータスの監視とリージョンの割り当てを担当します。また、RegionServer 上で実行される一連のサーバー ノードもあり、データの保存を担当します。

3.1.1 マスター

HBase の Master ノードには主に以下の機能があります。

  • メタデータ ストレージ: マスター ノードは、データ配布に関するメタデータを保存します。データがどのリージョンサーバーに存在するか、またどのリージョンがどのサーバーに分散されているかを保存します。
  • ネームスペース管理: マスター ノードは、HBase 内のすべてのテーブルの最新ステータスを追跡します。新しいテーブルの作成、既存のテーブルの削除、テーブルのプロパティの更新を行うことができます。
  • クエリルーティング: マスターノードは、ユーザーのクエリリクエストに従って、対応するリージョンサーバーにルーティングします。
  • 負荷分散: クラスターのリソースが不足している場合、マスター ノードはリクエストを別のリージョンサーバーに分散します。

3.1.2 リージョンサーバー

HBase の RegionServer ノードは、HBase にデータを保存します。主に次のタスクを担当します。

  • データ ストレージ:RegionServer はデータを HBase に保存します。リージョンサーバーは、ストレージスペースをより効率的に利用するために、リージョンに応じてデータを分割します。RegionalServer は、データをローカル ディスクに保存することも、Amazon S3 などのリモート データ ストレージ システムを使用することもできます。
  • データの切断と分割:RegionServer はデータを動的に分割して、クラスターのストレージ リソースを最大限に活用できます。RegionServer 上のリージョンが過密になると、そのリージョンが 2 つの新しいリージョンに分割され、データが分割されて 2 つの新しいリージョンに均等に分配されます。
  • コピー管理: HBase 内のデータは各リージョンサーバーに保存され、データの冗長性と信頼性を確保するために、データを複数のサーバーにコピーします。
  • リクエストルーティング:RegionServer はクライアントリクエストを受信すると、クエリリクエストに基づいて応答する対応するリージョンを見つけます。
  • フェイルオーバー:RegionServer に障害が発生すると、HBase はリクエストを別の RegionServer に再ルーティングします。

3.1.3 通信プロトコル

クライアントが HBase にリクエストを送信すると、リクエストは最初にマスター ノードにルーティングされ、マスター ノードは RegionServer ノードを選択してから、指定された RegionServer にリクエストをルーティングします。RegionServer ノードは、リクエストを処理し、結果をクライアントに返す役割を果たします。リージョンサーバーは、高性能の言語間ネットワーク通信プロトコルである Thrift プロトコルを使用して相互に通信します。Thrift は、複雑な構造をバイナリ エンコーディングにマッピングして、ネットワーク帯域幅の消費を削減できます。

3.2 シャーディングのメカニズム

HBase のデータは、クラスター リソースをより効率的に使用するために、さまざまなリージョン サーバーに分散されます。データはRegionServer上の複数のリージョンに分割され、リージョンは異なるRegionServerに分散されます。リージョンは、StoreFile と呼ばれる固定サイズのチャンクに分割されます。StoreFile は HBase の最小の物理ユニットであり、ディスク上のデータのストレージ ユニットでもあります。通常、リージョンは複数の StoreFile で構成されます。StoreFile は、ローカル ディスクまたは Amazon S3 などのリモート データ ストレージ システムに配置できます。
レコードが HBase に挿入されると、まず対応するリージョンにルーティングされます。リージョンはレコードを複数の StoreFile に分割し、対応するディスクまたはリモート データ ストレージ システムに StoreFile を書き込みます。レコードを更新する必要がある場合、HBase は対応するリージョンと対応する StoreFile を見つけて、変更されたデータを StoreFile に書き込む必要があります。レコードを削除する必要がある場合は、対応する StoreFile から削除してください。これにより、データの整合性と高可用性が保証されます。

3.3 一貫性プロトコル

分散システムでは、各ノードのステータスが不一致になる可能性があります。各ノードでデータの一貫性を保つために、HBase は 2 フェーズ コミット プロトコルを採用してデータの一貫性を確保します。HBase で使用される整合性プロトコルは Paxos プロトコルです。Paxos プロトコルは、複数のノード間のデータの一貫性を保証します。
Paxos プロトコルを実行する前に、HBase は、HBase クラスター内の唯一のマスター ノードであるスーパー マスターを決定する必要があります。スーパー マスターは、HBase 操作リクエストの調整、RegionServer の参加と終了の管理、およびテーブルに対する関連する設定変更を担当します。RegionServer ノードが起動するたびに、スーパー マスターに登録されます。RegionServer ノードに障害が発生すると、スーパー マスターからログオフします。
クライアント リクエストが HBase に送信されるたびに、クライアントがリクエストを開始したときのタイムスタンプであるトランザクション ID が生成されます。クライアントはリクエストを終了すると、クライアントのリクエスト、トランザクション ID、およびクライアントが予期する最大送信時間を含む Prepare メッセージを RegionServer に送信します。Prepare メッセージはリージョンサーバーによって収集され、その後コミットメッセージがプライマリリージョンサーバーに送信されます。コミット メッセージは、すべての参加者 (プライマリ リージョン サーバーとセカンダリ リージョン サーバーを含む) の準備メッセージが確認された後にのみ送信されます。いずれかの参加者が正常に応答しない場合、クライアントはリクエストを再試行します。
すべての参加者が正常に応答すると、RegionServer はクライアントのリクエスト、トランザクション ID、送信時刻、その他の情報を含む Accept メッセージをすべての参加者に送信します。参加者のいずれかが Accept メッセージを受け入れると、RegionServer はデータをディスクに保存します。参加者のいずれかが Accept メッセージを拒否した場合、クライアントはリクエストを再試行します。

3.4 スキャンコマンド

Scan コマンドは、HBase で複数のテーブルからデータを取得するために使用されます。Scan コマンドでは、テーブル名、スキャン条件、結果のフィルタリング条件、結果を返す列、ソート条件などを指定します。クライアントが Scan コマンドを開始すると、指定されたリージョン サーバーに RPC リクエストが送信され、リージョン サーバーはリクエストを処理してクエリ結果を返します。返された結果を受信したクライアントは、結果のフィルタリング条件、列、およびソート条件に基づいて、データのフィルタリング、集計、およびソートを実行します。最後に、クライアントは結果をユーザーに返します。

4. ソースコード分析

このセクションでは、HBase のソース コードを詳細に分析します。まず、HBase のいくつかの重要なモジュールである HMaster、HRegionServer、HLog、WAL、および Client を紹介します。次に、HBase のストレージ アーキテクチャについて詳細に説明し、HBase のストレージ プロセスと HBase の書き込みプロセスを紹介します。最後に、HBase の読み取り/書き込みプロセスとそれに関連するロック メカニズムについて説明します。

4.1 モジュールの紹介

4.1.1 Hマスター

HMaster は HBase のマスター プロセスであり、HBase クラスター全体の中央コントローラーです。その主な責任は次のとおりです。

  • テーブルの場所、テーブルのステータス、RegionServer のステータスなど、HBase クラスターのメタデータ情報を維持します。
  • クライアントの読み取りおよび書き込みリクエストを処理し、リクエストを対応するリージョンサーバーにルーティングします。
  • リージョンの分割とマージについて決定を下します。
  • HBase 関連の構成変更を実行します。
  • HBase サービスを管理します。

4.1.2 HRegionServer

HRegionServerは、HBaseのRegionServerプロセスです。その主な責任は次のとおりです。

  • データを HBase テーブルに保存します。
  • クライアントの読み取りおよび書き込みリクエストに応答します。
  • 地域を管理します。
  • フェイルオーバーを実行します。

4.1.3 Hログ

HLog は、HBase によって WAL (Write Ahead Log) に使用されるログ ファイルです。HBaseのデータ更新時の事前ログです。HLog には 2 つの主な機能があります。

  • データの永続性:RegionServer がダウンした場合、WAL ログを通じてデータを回復できます。
  • 障害回復:RegionServer に障害が発生した場合、WAL ログを通じてメタデータを回復できます。

4.1.4 ウォール

WAL(Write Ahead Log)は、HBaseのデータ更新時の事前ログです。WAL は、最初にログを書き込み、次にディスクをフラッシュすることでデータの永続性を確保するメカニズムです。RegionServer がデータ更新リクエストを受信すると、ディスクをフラッシュする前に更新内容を WAL ファイルに書き込みます。RegionServer がクラッシュした場合、WAL ファイル内のデータを通じてデータを回復できます。

4.1.5 クライアント

Client は HBase のクライアント ライブラリです。クライアントは、Java バージョンと Python バージョンのインターフェイスを提供します。その主な責任は次のとおりです。

  • HBase クライアント インターフェイスをカプセル化します。
  • データ操作を実行します。

4.2 HBase ストレージ アーキテクチャ

HBase のデータは RowKey および ColumnFamily:Qualifier の形式で保存されます。このうち、RowKey は行を検索するために使用され、ColumnFamily はデータを編成するための論理単位であり、Qualifier は ColumnFamily 内の要素です。HBase データは、テーブルの形式で RegionServer に保存されます。テーブルは複数のリージョンで構成されます。領域は、行のセットを格納する連続バイト配列であり、各行は複数のセルで構成されます。セルは、値とタイムスタンプの 2 つの部分で構成されます。Value は Cell の値、Timestamp は Cell 更新のタイムスタンプです。各セルには対応するバージョン番号があります。HBase は BlockCache を使用して、最近アクセスされたブロック (データ ブロック) の内容をキャッシュします。BlockCache は HDFS アクセスの数を減らし、パフォーマンスを向上させます。
HBase ストレージ アーキテクチャ図:

  • テーブル (Table) には複数のリージョンを含めることができます。
  • リージョンは複数の StoreFile で構成され、各 StoreFile は HBase の物理ストレージ ユニットです。
  • 各 StoreFile は、ローカル ディスクまたはリモート データ ストレージ システム上に置くことができます。
  • StoreFile には 1 つ以上の列ファミリー (ColumnFamily) が含まれています。
  • 各列ファミリーは複数の列 (Column) で構成されます。
  • 各セルには対応するバージョン番号があります。

4.3 保管プロセス

クライアントがデータの読み取りまたは書き込みリクエストを開始すると、まずマスターが正常かどうかを確認します。マスターはリクエストを対応するリージョンサーバーに転送します。RegionServer は、要求された読み取りおよび書き込みタイプ (読み取り、書き込み、スキャン) に基づいて対応する TableRegion を検索し、そのリージョンが存在するか閉じられているかを判断します。リージョンが存在しないか閉じられている場合、RegionServer はエラー メッセージを返します。それ以外の場合、RegionServer はデータの読み取りおよび書き込み操作を実行します。書き込み操作の場合、RegionServer はデータを WAL に書き込み、WAL を永続化します。
書き込み操作の処理フローは次のとおりです。

1.客户端将数据写入 WAL。
2.RegionServer 检查 WAL 文件是否写满。
3.如果 WAL 文件写满,RegionServer 将 WAL 文件滚动并生成一个新的 HLog 文件。
4.RegionServer 将数据写入 HDFS 的一个 StoreFile 中。
5.如果数据没有损坏,RegionServer 会更新内存中的数据,同时向 MemStore 写入一个 MemStoreSize。
6.如果 MemStoreSize 达到了阀值,RegionServer 会将 MemStore 中的数据写入 HDFS 的一个 MemStore 文件中。
7.RegionServer 会将 MemStore 文件滚动并生成一个新的 HFile 文件。
8.如果 MemStore 文件满了,RegionServer 会将 MemStore 文件滚动并生成一个新的 MemStore 文件。
9.RegionServer 返回客户端操作成功。

読み取り操作の処理フローは次のとおりです。

1.客户端发送请求到 RegionServer。
2.RegionServer 查找 MemStore 和 HFile 文件中是否有符合条件的数据。
3.如果 MemStore 和 HFile 文件中都没有数据,RegionServer 会向邻居节点请求数据。
4.如果邻居节点有数据,RegionServer 会将数据合并后返回给客户端。
5.客户端获取数据并返回。

Scan オペレーションの処理フローは次のとおりです。

1.客户端发送 Scan 请求到 RegionServer。
2.RegionServer 获取 MemStore 和 HFile 文件中的数据。
3.RegionServer 对数据进行过滤、排序等操作。
4.RegionServer 返回过滤、排序后的结果给客户端。

4.4 書き込みプロセス

書き込みフローチャート:
書き込み操作の詳細な手順:

  • クライアントはマスターに Put リクエストを送信します。
  • マスターは、対応するリージョンサーバーにリクエストを送信します。
  • RegionServer は、MemStore ファイルがいっぱいかどうかを確認します。
  • MemStore ファイルがいっぱいの場合、RegionServer は MemStore ファイルをロールし、新しい MemStore ファイルを生成します。
  • RegionServer はデータを MemStore に書き込みます。
  • RegionServer は、現在の MemStore ファイルがいっぱいかどうかを判断します。
  • MemStore ファイルがいっぱいの場合、RegionServer は MemStore ファイルをロールし、新しい MemStore ファイルを生成します。
  • RegionalServer は新しい Hlog ファイルを生成し、データを Hlog ファイルに書き込みます。
  • RegionServer は、Hlog ファイルをディスクに永続化します。
  • 書き込み操作が成功すると、RegionServer はデータを HDFS に書き込みます。

4.5 読み取りおよび書き込みプロセス

読み取りおよび書き込みのフローチャート:
読み取りおよび書き込み操作の詳細な手順:

  • クライアントは、Get/Put リクエストをマスターに送信します。
  • マスターは、対応するリージョンサーバーにリクエストを送信します。
  • RegionServer は、MemStore ファイルにデータがあるかどうかを確認し、データがある場合はデータを直接返します。
  • MemStore ファイルにデータがない場合、RegionServer は HDFS 内の StoreFile ファイルをチェックし、データをマージしてクライアントに返します。
  • 一致するデータがない場合、RegionServer はクライアントに Not Found 例外を返します。
  • クライアントは応答結果を返します。

4.6 ロック機構

複数のクライアントが同じデータを同時に更新することによって発生する競合を防ぐために、HBase は楽観的ロックと悲観的ロックを使用します。

  • 悲観的ロック: 悲観的ロックでは、一度に 1 つのクライアントだけがデータを更新できると考えられ、ロックが取得されるたびに、現在のデータが他のクライアントによって変更されているかどうかが確認されます。
  • オプティミスティック ロック: オプティミスティック ロックは、クライアントが競合しないと信じて、データを更新しようとするたびにデータのバージョン番号を比較します。
    HBase で使用されるロック メカニズムは次のとおりです。
  • グローバル ロック: グローバル ロックは特別な種類の悲観的ロックであり、その機能は HBase クラスター全体の同時アクセスを制御することです。クライアントがグローバル ロックを取得すると、現在のクライアントがロックを解放するまで、他のクライアントはロックを取得できません。
  • 行レベルのロック: 行レベルのロックは悲観的ロックであり、その機能は指定された行への同時アクセスを制御することです。
  • 列ファミリー レベルのロック: 列ファミリー レベルのロックは悲観的ロックであり、その機能は指定された列ファミリーへの同時アクセスを制御することです。
  • カスタム ロック: カスタム ロックは、クライアントがロックの粒度を自分で指定できるようにし、複数のクライアントが異なる粒度のロックを同時に保持できるようにする悲観的ロックです。

要約する

この記事では、HBase の機能、重要な用語、ストレージ アーキテクチャの概要を説明します。HBaseのソースコードを分析することで、HBaseの機能原理、設計思想、アーキテクチャ設計、ストレージプロセス、書き込みプロセス、読み書きプロセス、ロック機構などを深く理解しました。誰もが学習プロセスからインスピレーションを得て、学んだ知識を使って日常業務で実践的な問題を解決できるようになることを願っています。

おすすめ

転載: blog.csdn.net/universsky2015/article/details/132158164