メインコンテンツまでスキップ
メインコンテンツまでスキップ

クラスターの展開

このチュートリアルでは、ローカル ClickHouse サーバーが既にセットアップされている前提です。

このチュートリアルを通じて、シンプルな ClickHouse クラスターのセットアップ方法を学びます。小規模ですが、フォールトトレラントでスケーラブルです。その後、サンプルデータセットの1つを使用してデータを埋め込み、いくつかのデモクエリを実行します。

クラスター展開​

この ClickHouse クラスターは均質なクラスターになります。手順は以下の通りです：

  1. クラスター内のすべてのマシンに ClickHouse サーバーをインストールします
  2. 設定ファイル内でクラスターの設定を行います
  3. 各インスタンスにローカルテーブルを作成します
  4. 分散テーブルを作成します

分散テーブルは、ClickHouse クラスター内のローカルテーブルへの「ビュー」の一種です。分散テーブルからの SELECT クエリは、クラスター内のすべてのシャードのリソースを使用して実行されます。複数のクラスターに対して設定を指定し、異なるクラスターのビューを提供するために複数の分散テーブルを作成することができます。

以下は、1つのレプリカを持つ3つのシャードからなるクラスターの設定例です：

さらにデモを行うために、シングルノード展開チュートリアルで使用したCREATE TABLEクエリと同じクエリで、異なるテーブル名で新しいローカルテーブルを作成します：

分散テーブルを作成することで、クラスターのローカルテーブルへのビューを提供します：

クラスター内のすべてのマシンに同様の分散テーブルを作成するのは一般的な手法です。これにより、クラスターの任意のマシン上で分散クエリを実行できます。また、特定の SELECT クエリのためにremoteテーブル関数を使用して一時的な分散テーブルを作成する代替オプションもあります。

分散テーブルにデータを広めるために、INSERT SELECTを実行しましょう。

予想通り、計算的に重いクエリは1台のサーバーの代わりに3台のサーバーを利用する場合、N倍速く実行されます。

この場合、3つのシャードを持つクラスターを使用しており、各シャードには単一のレプリカが含まれています。

本番環境での耐障害性を提供するために、各シャードには2〜3のレプリカを持たせることを推奨します。これらのレプリカは、複数のアベイラビリティゾーンまたはデータセンター（あるいは少なくともラック）に分散させるべきです。ClickHouseは無制限の数のレプリカをサポートしていることに注意してください。

以下は、3つのレプリカを持つ1つのシャードからなるクラスターの設定例です：

ネイティブレプリケーションを有効にするには、ZooKeeperが必要です。ClickHouseはすべてのレプリカでデータの整合性を確保し、障害後に自動的に復元手順を実行します。ZooKeeper クラスターは、他のプロセス（ClickHouseを含む）が稼働していない専用サーバーに展開することを推奨します。

注

ZooKeeperは厳密な要件ではありません：単純な場合には、アプリケーションコードからすべてのレプリカにデータを書き込むことでデータを複製することができます。このアプローチは推奨されません。なぜなら、この場合 ClickHouse はすべてのレプリカでデータの整合性を保証できず、したがってアプリケーションの責任となるからです。

ZooKeeperの位置は、設定ファイル内で指定します：

また、シャードとレプリカを識別するためのマクロを設定する必要があります。これらはテーブルの作成時に使用されます：

レプリケーションテーブル作成時にレプリカが存在しない場合、新しい最初のレプリカがインスタンス化されます。すでにライブレプリカがある場合は、新しいレプリカが既存のものからデータをクローンします。すべてのレプリケーションテーブルを先に作成し、その後でデータを挿入することができます。また、いくつかのレプリカを作成し、他をデータ挿入中またはその後に追加するオプションもあります。

ここでは、ReplicatedMergeTreeテーブルエンジンを使用しています。パラメータには、シャードおよびレプリカ識別子を含むZooKeeperパスを指定します。

レプリケーションはマルチマスターモードで行われます。データは任意のレプリカにロードでき、システムは自動的に他のインスタンスと同期します。レプリケーションは非同期であるため、特定の時点で全てのレプリカが最近挿入されたデータを含まない場合があります。データインジェクションを行うためには、少なくとも1つのレプリカが稼働している必要があります。他のレプリカは、再びアクティブになった際にデータを同期し、整合性を修復します。このアプローチは、最近挿入されたデータの損失の可能性を低く保つことができます。