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

テーブルシャードとレプリカ


注記

このトピックは ClickHouse Cloud には適用されません。ここでは Parallel Replicas が従来の共有なしの ClickHouse クラスターにおける複数のシャードのように動作し、オブジェクトストレージが レプリカを置き換え 、高可用性とフォールトトレランスを確保します。

ClickHouse のテーブルシャードとは何ですか？​

従来の shared-nothing ClickHouse クラスターでは、シャーディングは ① データが単一のサーバーには大きすぎる場合、または ② 単一のサーバーがデータ処理に対して遅すぎる場合に使用されます。次の図は、テーブル uk_price_paid_simple の容量が単一のマシンのキャパシティを超えているケース ① を示しています：

SHARDS

このような場合、データはテーブルシャードの形で複数の ClickHouse サーバーに分割されることができます：

SHARDS

各 ^^shard^^ はデータのサブセットを保持し、独立してクエリを実行できる通常の ClickHouse テーブルとして機能します。ただし、クエリはそのサブセットのみを処理し、データ分布に応じて正当なユースケースとなる場合があります。通常、分散テーブル（通常はサーバーごとに）により、フルデータセットの統一ビューが提供されます。データ自体は保存されず、SELECT クエリがすべてのシャードに転送され、結果が集約され、INSERTS が均等にデータを分散させるようにルーティングされます。

分散テーブルの作成​

SELECT クエリの転送と INSERT ルーティングを説明するために、2つの ClickHouse サーバーに分割されたテーブル What are table parts の例を考えます。最初に、このセットアップのための対応する ^^Distributed table^^ を作成する DDL ステートメントを示します：

CREATE TABLE uk.uk_price_paid_simple_dist ON CLUSTER test_cluster
(
    date Date,
    town LowCardinality(String),
    street LowCardinality(String),
    price UInt32
)
ENGINE = Distributed('test_cluster', 'uk', 'uk_price_paid_simple', rand())

ON CLUSTER 句により、DDL ステートメントが 分散 DDL ステートメント になり、ClickHouse が test_cluster クラスター定義 にリストされたすべてのサーバーでテーブルを作成するように指示します。分散 DDL には、クラスタアーキテクチャ における追加の Keeper コンポーネントが必要です。

分散エンジンパラメータ に対して、^^cluster^^ 名 (test_cluster)、シャード対象テーブルのデータベース名 (uk)、シャード対象テーブルの名称 (uk_price_paid_simple)、および sharding key を指定します。この例では、rand 関数を使用して行をシャードにランダムに割り当てます。ただし、ユースケースに応じて、任意の式（複雑なものを含む）をシャーディングキーとして使用できます。次のセクションでは、INSERT ルーティングの仕組みを説明します。

INSERT ルーティング​

以下の図は、ClickHouse の ^^distributed table^^ への INSERT がどのように処理されるかを示しています：

SHARDS

① ^^distributed table^^ を対象とした INSERT（単一行）が、直接またはロードバランサを介してそのテーブルをホストする ClickHouse サーバーに送信されます。

② INSERT の各行（この例では1つだけ）について、ClickHouse はシャーディングキー（ここでは rand()）を評価し、その結果を ^^shard^^ サーバー数でモジュロ演算して、ターゲットサーバー ID を決定します（ID は 0 から始まり、1 ごとに増加します）。その後、行が転送され、③ 対応するサーバーのテーブル ^^shard^^ に挿入されます。

次のセクションでは、SELECT 転送の仕組みを説明します。

SELECT 転送​

この図は、ClickHouse における ^^distributed table^^ での SELECT クエリがどのように処理されるかを示しています：

SHARDS

① ^^distributed table^^ を対象とした SELECT 集約クエリが、直接またはロードバランサを介して対応する ClickHouse サーバーに送信されます。

② ^^Distributed table^^ は、ターゲットテーブルのシャードをホストするすべてのサーバーにクエリを転送し、各 ClickHouse サーバーがそのローカル集約結果を 並行 して計算します。

その後、最初にターゲットとされた ^^distributed table^^ をホストする ClickHouse サーバーが、③ すべてのローカル結果を収集し、④ 最終的なグローバル結果としてマージし、⑤ それをクエリの送信者に返します。

ClickHouse のテーブルレプリカとは何ですか？​

ClickHouse におけるレプリケーションは、複数のサーバー間で ^^shard^^ データのコピー を維持することにより、データ整合性 と フェイルオーバー を確保します。ハードウェアの故障は避けられないため、レプリケーションにより、各 ^^shard^^ が複数のレプリカを持つことでデータ損失を防ぎます。書き込みは、直接または 分散テーブル を介して任意の ^^replica^^ に指示できます。これは操作のために ^^replica^^ を選択します。変更は他のレプリカに自動的に伝播されます。障害やメンテナンスが発生した場合、データは他のレプリカで利用可能なままであり、故障したホストが回復すると、自動的に同期して最新の状態を保ちます。

レプリケーションには Keeper コンポーネントが クラスタアーキテクチャ に必要であることに注意してください。

次の図は、6つのサーバーを持つ ClickHouse ^^cluster^^ を示しています。ここで、前述のテーブルシャード Shard-1 および Shard-2 はそれぞれ 3つのレプリカを持っています。この ^^cluster^^ にクエリが送信されます：

SHARDS

クエリ処理は、レプリカのないセットアップと同様に機能し、各 ^^shard^^ からの単一の ^^replica^^ がクエリを実行します。

レプリカは、データ整合性とフェイルオーバーを確保するだけでなく、異なるレプリカ間で複数のクエリを並行して実行できるため、クエリ処理のスループットを向上させます。

① ^^distributed table^^ を対象としたクエリが、直接またはロードバランサを介して対応する ClickHouse サーバーに送信されます。

② ^^Distributed table^^ は、各 ^^shard^^ から1つの ^^replica^^ にクエリを転送し、選択された ^^replica^^ をホストする各 ClickHouse サーバーがローカルクエリ結果を並行して計算します。

残りの流れは、レプリカのないセットアップの場合と 同じ であり、上の図には示されていません。最初にターゲットとされた ^^distributed table^^ をホストする ClickHouse サーバーが、すべてのローカル結果を収集し、最終的なグローバル結果にマージし、クエリの送信者に返します。

ClickHouse では、② のクエリ転送戦略の設定が可能であることに注意してください。デフォルトでは—上の図とは異なり—^^distributed table^^ は、利用可能な場合、ローカル ^^replica^^ を 優先 しますが、他のロードバランシング 戦略 も使用できます。

さらに詳しい情報はどこで見つけることができますか？​

テーブルのシャードとレプリカについてのこの高レベルの紹介を超える詳細については、デプロイメントとスケーリングガイドをご確認ください。

ClickHouse のシャードとレプリカに関するより深い理解のために、このチュートリアルビデオを強くお勧めします：