今日の投稿では、HBaseアーキテクチャについて説明しましょう。 HBaseアーキテクチャについて深く掘り下げる前に、HBaseの基本をブラッシュアップしましょう。
doubleをintに変換します
HBase –基本：
HBaseは、HDFS上で実行されるGoogle BigTableをモデルにした、オープンソースのNoSQL、分散型、非リレーショナル、バージョン管理済み、多次元、列指向のストアです。 「NoSQL」は、データベースがプライマリアクセス言語としてSQLをサポートするRDBMSではないことを意味する広義の用語ですが、NoSQLデータベースには多くの種類があり、Berkeley DBはローカルNoSQLデータベースの良い例ですが、HBaseは非常に分散したデータベース。
HBaseは、GoogleBigTableのすべての機能を提供します。これは、自然言語検索のために大量のデータを処理するPowersetによるプロジェクトとして始まりました。これは、ApacheのHadoopプロジェクトの一部として開発され、HDFS（Hadoop分散ファイルシステム）上で実行されます。大量のスパースデータを格納するフォールトトレラントな方法を提供します。 HBaseは、型付き列、セカンダリインデックス、トリガー、高度なクエリ言語など、RDBMSで利用できる機能の多くが欠けているため、実際には「データベース」というよりも「データストア」です。
列指向データベースでは、データテーブルはデータの行としてではなく、データの列のセクションとして格納されます。列指向データベースのデータモデルは、テーブル名、行キー、列ファミリー、列、タイムスタンプで構成されます。 HBaseでテーブルを作成する際、行は行キーとタイムスタンプを使用して一意に識別されます。このデータモデルでは、列ファミリーは静的ですが、列は動的です。それでは、HBaseアーキテクチャを見てみましょう。
いつHBaseに行くのですか？
HBaseは、数億または数十億の行がある場合にのみ適切なオプションです。 HBaseは、ポートではなく完全な再設計としてRDBMSからHBaseへの移行を検討している場合にも使用できます。つまり、HBaseは、従来のトランザクションアプリケーションやリレーショナル分析にも最適化されていません。また、大規模なバッチMapReduceを実行する場合、HDFSの完全な代替ではありません。 では、なぜHBaseを選択する必要があるのでしょうか。アプリケーションに、各行がわずかに異なる可変スキーマがある場合は、HBaseを確認する必要があります。
HBaseアーキテクチャ：
次の図は、HBaseアーキテクチャを明確に説明しています。
HBaseには、次の3つの主要コンポーネントがあります。 マスター、リージョンサーバー、動物園の飼育係 。 他のコンポーネントは Memstore、HFile、WAL。
HBaseはHDFS上で実行されるため、HMasterがマスターノードになり、リージョンサーバーがスレーブノードになるマスタースレーブアーキテクチャを利用します。クライアントが書き込み要求を送信すると、HMasterはその要求を取得し、それぞれのリージョンサーバーに転送します。
例を含むmysqlのデータ型
リージョンサーバー：
これは、データノードと同様に機能するシステムです。リージョンサーバー（RS）は書き込み要求を受信すると、その要求を特定のリージョンに送信します。各リージョンには、行のセットが格納されます。行データは、複数の列ファミリー（CF）に分けることができます。特定のCFのデータは、Memstoreと一連のHFileで構成されるHStoreに保存されます。
Memstoreは何をしますか？
Memstoreは、その特定のリージョンサーバー内で実行された読み取りおよび書き込み操作のすべてのログを追跡します。このことから、これはHadoopの名前ノードと同様に機能していると言えます。 Memstoreはメモリ内ストレージであるため、Memstoreは各データノードのメモリ内ストレージを利用してログを保存します。特定のしきい値に達すると、MemstoreデータがHFileにフラッシュされます。
Memstoreを使用する主な目的は、行キー順に並べられたDFSにデータを格納する必要があることです。 HDFSはシーケンシャルな読み取り/書き込み用に設計されており、ファイルの変更は許可されていないため、HBaseは受信時にデータをディスクに効率的に書き込むことができません。書き込まれたデータは並べ替えられません（入力が並べ替えられていない場合）。つまり、将来に向けて最適化されません。検索。この問題を解決するために、HBaseは最後に受信したデータを（Memstore内の）メモリにバッファリングし、フラッシュする前にデータを「ソート」してから、高速シーケンシャル書き込みを使用してHDFSに書き込みます。したがって、HFileにはソートされた行のリストが含まれています。
Memstoreのフラッシュが発生するたびに、CFごとに1つのHFileが作成され、頻繁にフラッシュすると大量のHFileが作成される可能性があります。読み取り中にHBaseは多くのHFileを確認する必要があるため、読み取り速度が低下する可能性があります。開きすぎるHFileを防ぎ、読み取りパフォーマンスの低下を防ぐために、HFile圧縮プロセスが使用されます。 HBaseは、定期的に（特定の構成可能なしきい値が満たされたときに）、複数の小さなHFileを大きなHFileに圧縮します。明らかに、Memstoreフラッシュによって作成されるファイルが多いほど、システムの作業（余分な負荷）が多くなります。さらに、圧縮プロセスは通常、他のリクエストの処理と並行して実行され、HBaseがHFileの圧縮に対応できない場合（はい、そのためのしきい値も構成されています）、RSへの書き込みを再度ブロックします。上で説明したように、これは非常に望ましくありません。
Memstore全体でデータが永続的であるかどうかはわかりません。特定のデータノードがダウンしていると想定します。そうすると、そのデータノードのメモリにあるデータは失われます。
この問題を克服するために、要求がマスターから来ると、WALにも書き込まれます。 WALは他に何もありません ログ先行書き込み これは、永続ストレージであるHDFSに常駐します。これで、データノードがダウンしている場合でも、データが失われないようにすることができます。 WALで実行することになっているすべてのアクションのコピーがあります。データノードが起動すると、すべてのアクティビティが再度実行されます。操作が完了すると、メモリが不足していないことを確認するために、すべてがMemstoreとWALからフラッシュされ、HFileに書き込まれます。
行10を追加したいという簡単な例を見てみましょう。書き込み要求が届くと、すべてのメタデータがMemstoreとWALに渡されます。その特定の行がHFileに書き込まれると、MemstoreとWALのすべてがフラッシュされます。
動物園の飼育係：
HBaseはZookeeperと統合されています。 HBaseを起動すると、Zookeeperインスタンスも起動します。その理由は、Zooキーパーが、HBase用に存在するすべてのリージョンサーバーを追跡するのに役立つためです。動物園の飼育係は、そこにあるリージョンサーバーの数、どのリージョンサーバーがどのデータノードからどのデータノードに保持しているかを追跡します。 Hadoopが欠落している小さなデータセットを追跡します。これにより、ほとんどのメタデータを追跡するHadoop上のオーバーヘッドが減少します。したがって、HMasterは、実際にZooキーパーに連絡することにより、リージョンサーバーの詳細を取得します。
質問がありますか？コメントセクションでそれらに言及してください。折り返しご連絡いたします。
c ++配列をソートする方法
関連記事：