HBase の長所、短所、パフォーマンスのボトルネック
デビッドカーター
⚡ スマートサマリー
HBaseは、分散型で列指向のNoSQLデータベースです。 Hadoop HDFSまた、数十億行のデータに対してリアルタイムのランダムな読み書きアクセスを提供する一方で、クエリ、インデックス作成、ハードウェアコストにおいて明確なトレードオフが存在する。
HBaseとは？
HBaseは、Hadoop分散ファイルシステム（HDFS）上で動作するオープンソースの分散型列指向NoSQLデータベースです。 Google Bigtableは、行と列のファミリーで構成されるテーブルにデータを格納し、数十億行、数百万列にまで拡大する可能性のある疎なデータセット向けに設計されています。
リレーショナルデータベースとは異なり、HBaseは固定スキーマを使用せず、クエリ最適化機能も提供しません。代わりに、各値は行キー、カラムファミリー、カラム修飾子、およびタイムスタンプによって指定されるため、大規模なデータであっても、ランダムなリアルタイムの読み書きが高速に行えます。
HBaseクラスタはいくつかのコアコンポーネントに依存しています。HMasterはクラスタを調整し、リージョンを割り当て、リージョンサーバーは実際のデータを保存および提供し、Apacheは 飼育係 tracどのサーバーが稼働しているかをksし、フェイルオーバーに役立ちます。Hadoopエコシステム内に存在するため、HBaseは次のようなツールと連携します。 MapReduce, ハイブバッチ分析には Pig を使用します。内部の詳細については、以下を参照してください。 HBaseアーキテクチャ.
HBase の利点
HBaseを使用する主なメリットは以下のとおりです。
- HDFS上に非常に大規模なデータセットを保存し、HBaseテーブルに格納されている数十億行のデータを集約・分析することができます。
- このデータベースは、分散環境において複数のクライアント間で共有できます。
- データの読み取りと処理にかかる時間は、従来の関係モデルと比較して短縮されます。
- 高速なランダム読み書き操作をサポートします。
- HBaseは、オンライン分析業務に広く利用されている。
- ATMのリアルタイム残高更新など、銀行業務アプリケーションにおいて、HBaseは大量の読み書きを確実に処理します。
HBase の欠点
HBaseの重要な制限事項は以下のとおりです。
- HBaseは従来のリレーショナルモデルを完全に置き換えるものではありません。一部のリレーショナル機能はサポートされていません。
- HBase は次のような機能を実行できません SQLSQL構造をサポートしていないため、クエリ最適化機能がありません。
- HBaseは、大規模なシーケンシャル入出力アクセスを伴うため、CPUとメモリを大量に消費します。一方、MapReduceジョブは、主にI/Oバウンドで、メモリ使用量は固定されています。HBaseとMapReduceジョブを統合すると、予測不可能なレイテンシが発生する可能性があります。
- HBaseをPigやHiveのジョブと統合すると、クラスター上でメモリの問題が発生する場合があります。
- 共有クラスタ環境では、HBaseのCPU要件を満たすために、ノードあたりに割り当てるタスクスロットの数が少なくて済む。
HBase のパフォーマンスのボトルネック
HBaseは拡張性を提供するが、いくつかのアーキテクチャ上の選択肢によってパフォーマンスのボトルネックが生じるため、チームはそれらを考慮して計画を立てる必要がある。
大規模な本番環境では、HBaseクラスタは数千ものノードにまたがって稼働しますが、すべてのスレーブリージョンサーバーのマスターとして機能するのはHMasterのみです。HMasterがダウンした場合、クライアントがリージョンサーバーに接続できたとしても、復旧には長い時間がかかる可能性があります。スタンバイマスターを稼働させることは可能ですが、同時にアクティブになるHMasterは1つだけであり、障害発生後に2つ目のHMasterを昇格させるのも容易ではありません。そのため、HMasterはパフォーマンス上のボトルネックとして認識されています。
HBaseは、テーブル間結合操作を直接サポートしていません。MapReduceを使用すれば結合を実装できますが、設計と開発にかなりの時間がかかり、HBaseでは一部のテーブル結合は事実上不可能です。
外部RDBMSからHBaseへのデータ移行には通常、新しいスキーマ設計が必要となり、その移行プロセスには長い時間がかかる場合があります。クエリも難しいため、多くのチームはHBaseの上にApache PhoenixなどのSQLレイヤーを追加して、クエリを実行できるようにしています。 データの読み書き おなじみの質問とともに。
HBaseは単一のインデックスしかサポートしておらず、行キーが主キーとして機能するため、他のフィールドでの検索は遅くなります。この問題を回避するために、チームはMapReduceコードを記述するか、Apacheを統合します。 ソル セカンダリインデックス作成にはApache Phoenixを使用します。
- 複数ユーザーによるデータアクセスに関するセキュリティ対策は、ごくゆっくりとしか改善されていない。
- HBaseは部分キーを完全にはサポートしていません。
- テーブルごとに設定できるデフォルトのソート順は1つのみです。
- HBaseに大きなバイナリファイルを保存するのは難しい。
- HBaseストレージは、リアルタイムクエリとソートに制限があります。
- テーブルの内容に対するキー検索や範囲検索は、リアルタイムで実行する必要のあるクエリを制約することができます。
- デフォルトではインデックス機能は備わっていないため、プログラマーはインデックス機能を追加するために追加のコードまたはスクリプトを作成する必要があります。
- ハードウェア要件とメモリブロックの割り当てにより、HBaseの運用コストは高額になる。
- 分散クラスタには多数のサーバーが必要であり、NameNode、DataNode、ZooKeeper、およびリージョンサーバーそれぞれに個別のノードが必要となる。
- 良好なパフォーマンスを得るには、大容量メモリを搭載したマシンが必要です。
- 全体的なコストとメンテナンス費用は、よりシンプルな代替案よりも高くなる。
HBaseとRDBMSの比較
この記事では、HBaseと従来のリレーショナルデータベースを繰り返し比較しています。以下の表は、主な違いをまとめたもので、ワークロードに最適なモデルを選択する際の参考にしてください。
| 機能 | HBase | RDBMS |
|---|---|---|
| データモデル | 列指向でスキーマ柔軟性に優れたNoSQLストア | 固定スキーマを持つ行指向テーブル |
| クエリ言語 | ネイティブSQLは使用せず、APIまたはApache Phoenixのようなアドオンレイヤーを使用する。 | クエリ最適化機能を備えた完全なSQL |
| スケーリング | 水平方向、商品ノード（ペタバイト）全体にわたって | ほとんどが垂直方向。スケールアウトが難しい。 |
| 取引 | 行レベルのアトミック性のみ。複数行のACIDは適用されない。 | 完全なACIDトランザクション |
| 結合とインデックス | ネイティブ結合なし。単一行キーインデックス | ネイティブ結合と複数のセカンダリインデックス |
| 最適 | 疎で非常に大規模、書き込み頻度の高いリアルタイムデータ | 複雑なクエリを必要とする構造化データ |
要するに、HBaseはスケーラビリティとリアルタイムアクセスを重視し、RDBMSは高度なクエリ機能と高い一貫性を重視します。データ量と書き込みスループットがリレーショナルデータベースの許容範囲を超えた場合に、HBaseを選択するのが良いでしょう。
