> ## Documentation Index > Fetch the complete documentation index at: https://private-7c7dfe99-parallel-read-in-order-multi-part.mintlify.site/llms.txt > Use this file to discover all available pages before exploring further. # SharedMergeTree テーブルエンジン > SharedMergeTree テーブルエンジンについて説明します export const Image = ({img, alt, size = "lg", background}) => { const normalizedSize = ["sm", "md", "lg"].includes(size) ? size : "lg"; const backgroundColor = background === "white" ? "white" : background === "black" ? "rgb(31 31 28)" : undefined; return
{alt}
; }; SharedMergeTree テーブルエンジンファミリーは、共有ストレージ (例: Amazon S3、Google Cloud Storage、MinIO、Azure Blob Storage) 上で動作するよう最適化された、ReplicatedMergeTree エンジンのクラウドネイティブな代替です。各 MergeTree エンジンタイプには対応する SharedMergeTree があり、たとえば SharedReplacingMergeTree は ReplicatedReplacingMergeTree に対応します。 SharedMergeTree テーブルエンジンファミリーは ClickHouse Cloud を支えています。エンドユーザーは、ReplicatedMergeTree ベースのエンジンから SharedMergeTree エンジンファミリーへ移行するために、特に変更を加える必要はありません。さらに、次のような利点があります。 * insert スループットの向上 * バックグラウンドマージのスループット向上 * mutation のスループット向上 * scale-up および scale-down の高速化 * SELECT クエリに対する、より軽量な強整合性 SharedMergeTree の大きな改善点の 1 つは、ReplicatedMergeTree と比べて、コンピュートとストレージの分離がより進んでいることです。以下は、ReplicatedMergeTree におけるコンピュートとストレージの分離方法を示したものです。 ReplicatedMergeTree の図 ご覧のとおり、ReplicatedMergeTree ではデータ自体はオブジェクトストレージに保存されますが、メタデータは引き続き各 clickhouse-server 上に保持されます。つまり、レプリケーションを伴うあらゆる操作で、メタデータもすべてのレプリカに複製する必要があります。 メタデータ付き ReplicatedMergeTree の図 ReplicatedMergeTree とは異なり、SharedMergeTree ではレプリカ同士が通信する必要はありません。代わりに、すべての通信は共有ストレージと clickhouse-keeper を介して行われます。SharedMergeTree は非同期のリーダーレス レプリケーションを実装しており、協調とメタデータストレージのために clickhouse-keeper を使用します。つまり、サービスの scale-up や scale-down に合わせてメタデータを複製する必要がありません。その結果、レプリケーション、mutation、マージ、scale-up が高速化されます。SharedMergeTree では各テーブルで数百のレプリカを持てるため、分片なしで動的にスケールできます。ClickHouse Cloud では、1 つのクエリにより多くのコンピュートリソースを活用するために、分散クエリ実行のアプローチが採用されています。

内部情報の確認

ReplicatedMergeTree の内部情報の確認に使われるシステムテーブルのほとんどは SharedMergeTree にもありますが、データやメタデータのレプリケーションは行われないため、`system.replication_queue` と `system.replicated_fetches` は存在しません。ただし、SharedMergeTree にはこれら 2 つのテーブルに対応する代替手段があります。 **system.virtual\_parts** このテーブルは、SharedMergeTree における `system.replication_queue` の代替です。現在の最新のパーツ集合に関する情報に加えて、マージ、mutation、削除されたパーティションなどによって今後生成される進行中のパーツに関する情報も格納します。 **system.shared\_merge\_tree\_fetches** このテーブルは、SharedMergeTree における `system.replicated_fetches` の代替です。主キーとチェックサムをメモリに取り込む、現在進行中のフェッチに関する情報を含みます。

SharedMergeTree の有効化

`SharedMergeTree` はデフォルトで有効になっています。 SharedMergeTree テーブルエンジンをサポートするサービスでは、手動で有効化する必要はありません。これまでと同じ方法でテーブルを作成するだけで、CREATE TABLE クエリで指定したエンジンに対応する SharedMergeTree ベースのテーブルエンジンが自動的に使用されます。 ```sql theme={null} CREATE TABLE my_table( key UInt64, value String ) ENGINE = MergeTree ORDER BY key ``` これにより、SharedMergeTree テーブルエンジンを使用してテーブル `my_table` が作成されます。 ClickHouse Cloud では `default_table_engine=MergeTree` が設定されているため、`ENGINE=MergeTree` を指定する必要はありません。次のクエリは上記のクエリと同じです。 ```sql theme={null} CREATE TABLE my_table( key UInt64, value String ) ORDER BY key ``` Replacing、Collapsing、Aggregating、Summing、VersionedCollapsing、または Graphite MergeTree のテーブルを使用している場合は、対応する SharedMergeTree ベースのテーブルエンジンに自動的に変換されます。 ```sql theme={null} CREATE TABLE myFirstReplacingMT ( `key` Int64, `someCol` String, `eventTime` DateTime ) ENGINE = ReplacingMergeTree ORDER BY key; ``` 特定のテーブルでどのテーブルエンジンが使用されているかは、`SHOW CREATE TABLE` で `CREATE TABLE` ステートメントを表示すると確認できます: ```sql theme={null} SHOW CREATE TABLE myFirstReplacingMT; ``` ```sql theme={null} CREATE TABLE default.myFirstReplacingMT ( `key` Int64, `someCol` String, `eventTime` DateTime ) ENGINE = SharedReplacingMergeTree('/clickhouse/tables/{uuid}/{shard}', '{replica}') ORDER BY key ```

設定

一部の設定では挙動が大きく変わっています: * `insert_quorum` -- SharedMergeTree へのすべての insert はクォーラムインサート (共有ストレージに書き込まれる) であるため、SharedMergeTree テーブルエンジンを使用する場合、この設定は不要です。 * `insert_quorum_parallel` -- SharedMergeTree へのすべての insert はクォーラムインサート (共有ストレージに書き込まれる) であるため、SharedMergeTree テーブルエンジンを使用する場合、この設定は不要です。 * `select_sequential_consistency` -- クォーラムインサートは不要ですが、`SELECT` クエリで clickhouse-keeper に追加の負荷がかかります

整合性

SharedMergeTree は、ReplicatedMergeTree よりも優れた軽量な整合性を提供します。SharedMergeTree に insert する際、`insert_quorum` や `insert_quorum_parallel` などの設定を指定する必要はありません。insert はクォーラムインサートであるため、メタデータは ClickHouse-Keeper に保存され、少なくとも ClickHouse-Keeper のクォーラムにレプリケートされます。クラスター内の各レプリカは、ClickHouse-Keeper から新しい情報を非同期に fetch します。 ほとんどの場合、`select_sequential_consistency` や `SYSTEM SYNC REPLICA LIGHTWEIGHT` を使う必要はありません。非同期レプリケーションでほとんどのケースをカバーでき、レイテンシも非常に低く抑えられます。どうしても古い読み取りを防ぐ必要があるまれなケースでは、優先順位の高い順に次の推奨事項に従ってください。 1. 読み取りと書き込みのクエリを同じ session または同じノードで実行している場合、レプリカはすでに最新のメタデータを保持しているため、`select_sequential_consistency` は不要です。 2. 1 つのレプリカに書き込み、別のレプリカから読み取る場合は、`SYSTEM SYNC REPLICA LIGHTWEIGHT` を使用して、そのレプリカに ClickHouse-Keeper からメタデータを fetch させることができます。 3. クエリ設定の一部として `select_sequential_consistency` を使用します。

`ALTER` とミューテーションの可視性

`SharedMergeTree` は、ClickHouse Keeper を介してメタデータの変更を調整します。各レプリカは変更されたメタデータを非同期でフェッチするため、メタデータの変更がすべてのレプリカですぐに反映されるとは限りません。なお、同じノード上の同じ session 内での読み取りには、すでに最新のメタデータが使用されます。メタデータの変更直後に別のレプリカで読み取りを実行する必要がある場合は、`SYSTEM SYNC REPLICA LIGHTWEIGHT` を使用して、そのレプリカに ClickHouse Keeper からメタデータをフェッチさせてください。 ミューテーションを伴う `ALTER` 操作では、バックグラウンド処理によって共有ストレージ上に新しいパーツが作成され、その可視性は ClickHouse Keeper を介して調整されます。`ReplicatedMergeTree` のように、レプリカごとに書き換えやデータ転送を行う処理ではありません。 ClickHouse Cloud では、[`alter_sync`](/ja/reference/settings/session-settings/alter#alter_sync) のデフォルト値は `0` です。クライアントがメタデータ操作、またはメタデータ以外の `MODIFY COLUMN` による書き換えの完了を待機する必要がある場合は、この設定を指定してください。`UPDATE`、`DELETE`、`MATERIALIZE ...` 操作では、[`mutations_sync`](/ja/reference/settings/session-settings/mutations#mutations_sync) で待機を制御し、[`system.mutations`](/ja/reference/system-tables/mutations) で進捗を監視してください。