ClickHouse architecture ======================= ClickHouseのEDB Postgres AIは、スタンドアロンインスタンスまたは分散クラスターとして実行され、シャーディング、レプリケーション、またはその両方をサポートしています。 ClickHouseサーバーは、データを保存および処理するデータベースエンジンです。 ClickHouseクライアントは、サーバーに接続し、クエリを実行するためのコマンドラインインターフェイスです。 デプロイメントトポロジ ---------------------- トポロジは、データがどのように保存、複製、および提供される方法と、どの程度の操作の複雑性を引き受けるかを決定します。 - **シングルノード** ClickHouseは、単一のホストでスタンドアロンインスタンスとして実行されます。クラスター調整は必要ありません。開発、テスト、およびシングルテナントの分析ワークロードに適しています。 - **マルチノードクラスター** データは水平スケールのためにシャード全体に分散され、高可用性のために複製されます。マルチノードクラスターは、シャーディングのみ、レプリケーションのみ、または両方を一緒に使用できます。レプリケーションにはClickHouse Keeperが必要です。 テーブルエンジン ---------------- ClickHouseでは、すべてのテーブルに、データを保存、インデックス付け、およびレプリケートする方法を決定するエンジンがあります。プライマリファミリーは\ ``MergeTree`` で、高スループット分析ワークロード用に設計されています。 ``ReplicatedMergeTree`` は、ノード間のビルトインレプリケーションでそれを拡張します。分散クエリの場合、\ ``Distributed`` エンジンは、クエリを基になるシャードにルーティングし、結果をマージする仮想テーブルとして機能します。完全なリファレンスについては、ClickHouseドキュメントの `Table engines `_ を参照してください。 シャーディング -------------- ClickHouseは、シェアードナッシングアーキテクチャを使用します。各ノードは独自のストレージを持ち、独立して動作します。シャーディングは、各ノードが異なる行のサブセットを保持する複数のノードにデータを水平に分割することにより、これを利用します。クエリーはシャード間で並列実行され、その結果はクライアントに返される前にマージされます。このアプローチでは、書き込みスループットとストレージを単一のノードで処理できる量を超えてスケールしますが、高可用性は提供されません。シャードがダウンすると、そのデータは利用できなくなります。 シャーディングには、クラスターコーディネーションは必要ありません。クエリルーティングは、 ``Distributed`` テーブルエンジンによって処理され、すべてのシャードにクエリーを並列送信し、結果を透過的にマージします。詳細は、 :ref:`ClickHouseがクエリをルーティングする方法 ` を参照してください。 .. container:: レプリケーション ---------------- レプリケーションは、マルチプルのノードで同じデータの同一のコピーを保持します。 1つのノードがダウンすると、別のレプリカがクエリーを提供できます。レプリケーションは高可用性を提供しますが、自分自身でストレージ容量や書き込みスループットを向上させることはありません。 ClickHouseでレプリケーションを有効にするには、テーブルエンジンとして\ ``ReplicatedMergeTree`` を選択し、ClickHouse Keeperを展開します。 Keeperは、どのデータ部分が存在するかを追跡し、コピーの同期を保つことにより、レプリカを調整します。 .. container:: ClickHouse Keeper ----------------- ClickHouse Keeperは、ClickHouseのビルトイン調整サービスであり、Apache ZooKeeperと同等の役割を持ち、プロトコルレベルでそれと互換性があります。以下を処理します。 - レプリカ全体に存在するデータ部分の追跡 - レプリカの同期を維持するためのインサートの調整 - 分散DDLの実行 すべてのノードに適用されるスキーマの変更 - レプリケート操作のリーダーの選出 KeeperはRaftコンセンサスアルゴリズムを使用し、機能するにはノードのクォーラムが必要です。最小は3つのキーパーノードであり、これにより、クラスターは1つのノードの障害を許容できます。 5つのKeeperノードを使用すると、2つの障害を許容できます。 Keeperは2つの方法で実行できます。コロケーション展開では、Keeperは同じノードでClickHouseサーバーと並行して実行されます。コロケーションは管理が簡単で、小規模なクラスターに適しています。専用展開では、Keeperはサーバーワークロードのない別のノードで実行されます。これにより、分離が向上し、大規模なクラスタまたは実稼働クラスタに推奨されます。 シャーディングとレプリケーションの組み合わせ -------------------------------------------- シャーディングとレプリケーションを組み合わせて、ホリゾンタル スケールと高可用性の両方を実現します。一般的な運用トポロジは、それぞれ2つのレプリカを持つ2つのシャードであり、合計4つのサーバーノードになります。 - 2つのシャードは、2つの独立したデータセットにわたる水平スケールを提供します。 - シャードごとに2つのレプリカが高可用性を提供します。各シャードにはスタンバイコピーがあります。 Keeperは、少なくとも3つのノードで実行され、サーバーノード上のコロケーションまたは別の専用ノードで実行されます。 2つのKeeper展開アプローチに関するガイダンスについては、 :ref:`展開オプション <展開オプション>` を参照してください。 .. container:: .. rubric:: ClickHouseがクエリをルーティングする方法 :name: clickhouseがクエリをルーティングする方法 データが複数のノードにまたがってシャード化されている場合、クエリーはすべてのシャードに到達し、その結果を組み合わせる必要があります。 ClickHouseは、\ ``Distributed`` テーブルエンジンでこのルーティングを処理します。 ``Distributed`` テーブルは、各シャードの基になる\ ``MergeTree`` または\ ``ReplicatedMergeTree`` テーブルの上部にある仮想テーブルです。任意のノードで\ ``Distributed`` テーブルを照会すると、そのノードはクエリをすべてのシャードにパラレルにファンアウトし、結果を収集し、マージされた結果を返します。 アプリケーションは、シャーディングトポロジを知る必要がなく、サーバーノードに接続し、\ ``Distributed`` テーブルを照会します。書き込みの場合、 ``Distributed`` テーブルに挿入すると、定義したシャーディングキー通常は列のハッシュを使用して、各行が正しいシャードにルーティングされます。 シャーディング、レプリケーション、およびKeeperトポロジはすべてClickHouseサーバー構成ファイルで定義されます。詳細については、 ClickHouseドキュメントの `Configuration files `_ を参照してください。