データ保存用の外部ディスク
ClickHouseで処理されたデータは、通常、ローカルファイルシステムに保存されます — ClickHouseサーバーと同じマシン上です。これには大容量のディスクが必要であり、コストがかかる可能性があります。それを避けるために、データをリモートに保存することができます。さまざまなストレージがサポートされています：
- Amazon S3 オブジェクトストレージ。
- Azure Blob Storage。
- サポートされていない: Hadoop Distributed File System (HDFS)
MergeTree ファミリーまたは Log ファミリーのテーブルに対するストレージ構成を説明しています。Amazon S3ディスクに保存されたデータを操作するには、 S3 テーブルエンジンを使用します。- Azure Blob Storage に保存されたデータを操作するには、 AzureBlobStorage テーブルエンジンを使用します。
- サポートされていない: Hadoop Distributed File System のデータを操作するには — HDFS テーブルエンジンを使用します。
外部ストレージの構成
MergeTree および Log ファミリーのテーブルエンジンは、ディスクの種類としてそれぞれ s3、azure_blob_storage、hdfs（未サポート）を使用して、データを S3、AzureBlobStorage、HDFS（未サポート）に保存できます。
ディスク構成には以下が必要です：
typeセクション、s3、azure_blob_storage、hdfs（未サポート）、local_blob_storage、webのいずれかに等しい。- 特定の外部ストレージタイプの構成。
24.1のClickHouseバージョン以降、新しい構成オプションを使用することが可能です。 指定する必要があるのは次のとおりです：
typeがobject_storageに等しいobject_storage_type、s3、azure_blob_storage（または、24.3からは単にazure）、hdfs（未サポート）、local_blob_storage（または、24.3からは単にlocal）、webのいずれかに等しい。 オプションとして、metadata_typeを指定できます（これはデフォルトでlocalに等しい）、ただしplain、web、及び24.4以降はplain_rewritableに設定することも可能です。plainメタデータタイプの使用は plain storage section で説明されています。webメタデータタイプはwebオブジェクトストレージタイプのみで使用できます。localメタデータタイプは、メタデータファイルをローカルに保存します（各メタデータファイルにはオブジェクトストレージ内のファイルに対するマッピングと、その追加のメタ情報が含まれています）。
例えば、構成オプション
は、以下の構成（24.1から）と等しいです：
構成
は以下と等しいです：
完全なストレージ構成の例は次のようになります：
24.1のClickHouseバージョン以降、次のようになります：
特定の種類のストレージをすべての MergeTree テーブルのデフォルトオプションにするには、構成ファイルに以下のセクションを追加します：
特定のテーブルにのみ特定のストレージポリシーを構成したい場合は、テーブル作成時に設定で定義できます：
storage_policy の代わりに disk を使用することもできます。この場合、構成ファイルに storage_policy セクションを持つ必要はなく、disk セクションだけで十分です。
動的構成
事前に定義されたディスクではなく、構成ファイル内でストレージ構成を指定することも可能ですが、CREATE / ATTACH クエリの設定で構成を行うことができます。
以下のクエリは上記の動的ディスク構成を基にしており、URLに保存されたテーブルからデータをキャッシュするためにローカルディスクを使用する方法を示しています。
以下の例では、外部ストレージにキャッシュを追加しています。
以下に強調された設定に注意してください。このtype=web のディスクが、type=cache のディスク内にネストされています。
この例では type=web を使用していますが、任意のディスクタイプを動的に構成することができます。ローカルディスクも同様です。ローカルディスクには、サーバー設定パラメータ custom_local_disks_base_directory 内のパス引数が必要であり、デフォルトがないため、ローカルディスクを使用する際はそれも設定してください。
構成ベースの設定とSQL定義の構成の組み合わせも可能です：
ここで、web はサーバー構成ファイルからのものです：
S3ストレージの使用
必要なパラメーター：
endpoint—pathまたはvirtual hostedスタイルの S3 エンドポイント URL (styles)。エンドポイントURLには、バケットとデータを保存するためのルートパスが含まれている必要があります。access_key_id— S3 アクセスキーID。secret_access_key— S3 シークレットアクセスキー。
オプションのパラメーター：
region— S3 のリージョン名。support_batch_delete— バッチ削除がサポートされているかどうかを確認するための制御を行います。Google Cloud Storage (GCS) を使用する場合は、GCS がバッチ削除をサポートしていないため、falseに設定してください。これによりログ内のエラーメッセージが防止されます。use_environment_credentials— 環境変数 AWS_ACCESS_KEY_ID、AWS_SECRET_ACCESS_KEY、および AWS_SESSION_TOKEN から AWS 認証情報を読み込みます。デフォルト値はfalseです。use_insecure_imds_request—trueに設定すると、S3 クライアントが Amazon EC2 メタデータから認証情報を取得する際に、安全でない IMDS リクエストを使用します。デフォルト値はfalseです。expiration_window_seconds— 有効期限ベースの資格情報が失効しているかを確認するための猶予期間。オプションで、デフォルト値は120です。proxy— S3 エンドポイントのプロキシ構成。proxyブロック内の各uri要素はプロキシURLを含まなければなりません。connect_timeout_ms— ミリ秒単位のソケット接続タイムアウト。デフォルト値は10 secondsです。request_timeout_ms— ミリ秒単位のリクエストタイムアウト。デフォルト値は5 secondsです。retry_attempts— リクエスト失敗時の再試行回数。デフォルト値は10です。single_read_retries— 読み取り中に接続が切断された場合の再試行回数。デフォルト値は4です。min_bytes_for_seek— シーケンシャルリードの代わりにシーク操作を使用するための最小バイト数。デフォルト値は1 Mbです。metadata_path— S3 のメタデータファイルを保存するためのローカルFS上のパス。デフォルト値は/var/lib/clickhouse/disks/<disk_name>/です。skip_access_check—trueの場合、ディスク起動時にディスクアクセスチェックは実行されません。デフォルト値はfalseです。header— 指定されたHTTPヘッダーをリクエストに追加します。オプションとして、複数回指定できます。server_side_encryption_customer_key_base64— 指定された場合、SSE-C 暗号化された S3 オブジェクトにアクセスするために必要なヘッダーが設定されます。server_side_encryption_kms_key_id- 指定された場合、SSE-KMS 暗号化された S3 オブジェクトにアクセスするために必要なヘッダーが設定されます (UsingKMSEncryption)。空の文字列が指定されると、AWS 管理の S3 キーが使用されます。オプションです。server_side_encryption_kms_encryption_context-server_side_encryption_kms_key_idと一緒に指定された場合、SSE-KMS 用の暗号化コンテキストヘッダーが設定されます。オプションです。server_side_encryption_kms_bucket_key_enabled-server_side_encryption_kms_key_idと一緒に指定された場合、SSE-KMS のための S3 バケットキーを有効にするヘッダーが設定されます。オプションで、trueまたはfalseにできます。デフォルトは何も指定されず（バケットレベルの設定に一致します）。s3_max_put_rps— スロットルがかかる前の最大PUTリクエスト毎秒速度。デフォルト値は0（制限なし）です。s3_max_put_burst— リクエスト毎秒制限に達する前に同時に発行できる最大リクエスト数。デフォルト値（0値）はs3_max_put_rpsと等しいです。s3_max_get_rps— スロットルがかかる前の最大GETリクエスト毎秒速度。デフォルト値は0（制限なし）です。s3_max_get_burst— リクエスト毎秒制限に達する前に同時に発行できる最大リクエスト数。デフォルト値（0値）はs3_max_get_rpsと等しいです。read_resource— このディスクへの読み取りリクエストの スケジューリング に使用されるリソース名。デフォルト値は空の文字列（このディスクに対してIOスケジューリングは有効になっていません）。write_resource— このディスクへの書き込みリクエストの スケジューリング に使用されるリソース名。デフォルト値は空の文字列（このディスクに対してIOスケジューリングは有効になっていません）。key_template— オブジェクトキーが生成される形式を定義します。デフォルトでは、ClickHouseはendpointのroot pathを取り、それにランダム生成されたサフィックスを追加します。そのサフィックスは3つのランダムシンボルを持つディレクトリと29のランダムシンボルを持つファイル名です。このオプションにより、オブジェクトキーの生成方法に関する完全な制御が可能になります。一部の使用シナリオでは、プレフィックスやオブジェクトキーの真ん中にランダムシンボルが必要です。例えば:[a-z]{3}-prefix-random/constant-part/random-middle-[a-z]{3}/random-suffix-[a-z]{29}。値はre2で解析されます。構文の一部のみがサポートされています。このオプションを使用する前に、希望する形式がサポートされているか確認してください。ClickHouseがkey_templateの値に基づいてキーを生成できない場合、ディスクは初期化されません。これは、storage_metadata_write_full_object_key機能フラグを有効にする必要があります。この機能は、endpointオプションにおけるroot pathの宣言を禁止します。key_compatibility_prefixオプションの定義が必要です。key_compatibility_prefix—key_templateオプションが使用されている場合、これは必要なオプションです。このオプションは、VERSION_FULL_OBJECT_KEY未満のメタデータバージョンでメタデータファイルに保存されたオブジェクトキーを読み取るために必要です。以前のroot pathはここでendpointオプションから設定する必要があります。
Google Cloud Storage (GCS) も、タイプ s3 を使用してサポートされています。 GCS backed MergeTree を参照してください。
プレインストレージの使用
22.10 では、s3_plain という新しいディスクタイプが導入され、書き込み専用のストレージが提供されます。構成パラメータは s3 ディスクタイプと同じです。
s3 ディスクタイプとは異なり、データをそのまま保存します。つまり、ランダム生成されたブロブ名の代わりに通常のファイル名を使用し（ClickHouseがローカルディスクにファイルを保存するのと同様）、ローカルにメタデータを保存しません。すなわち、S3のデータから派生します。
このディスクタイプを使用すると、既存のデータに対してマージを実行できず、 新しいデータの挿入もできないため、テーブルの静的バージョンを維持できます。
このディスクタイプの使用例は、バックアップを作成することです。バックアップは BACKUP TABLE data TO Disk('plain_disk_name', 'backup_name') を通じて実行できます。その後、RESTORE TABLE data AS data_restored FROM Disk('plain_disk_name', 'backup_name')を実行するか、ATTACH TABLE data (...) ENGINE = MergeTree() SETTINGS disk = 'plain_disk_name'を使用します。
構成：
24.1から、任意のオブジェクトストレージディスク（s3、azure、hdfs（未サポート）、local）を plain メタデータタイプを使って構成することができます。
構成：
S3プレイン書き換え可能ストレージの使用
24.4 にて新しいディスクタイプ s3_plain_rewritable が導入されました。
s3_plain ディスクタイプと同様に、メタデータファイルに追加のストレージを必要とせず、メタデータはS3に保存されます。
s3_plain ディスクタイプとは異なり、s3_plain_rewritable ではマージを実行でき、INSERT 操作もサポートしています。
Mutations および テーブルの複製はサポートされていません。
このディスクタイプの使用例は、複製されていない MergeTree テーブルです。s3 ディスクタイプは複製されていない MergeTree テーブルに適していますが、テーブルにローカルメタデータが不要で、限られた操作セットを受け入れることができるのであれば、s3_plain_rewritable ディスクタイプを選択できます。これは、システムテーブルに対して役立ちます。
構成：
これは以下に等しいです：
24.5から、任意のオブジェクトストレージディスク（s3、azure、local）を plain_rewritable メタデータタイプで構成することができます。
Azure Blob Storageの使用
MergeTree ファミリーのテーブルエンジンは、azure_blob_storage タイプのディスクを使用して Azure Blob Storage にデータを保存できます。
構成マークアップ：
接続パラメータ：
storage_account_url- 必須、Azure Blob Storage アカウント URL、http://account.blob.core.windows.netまたはhttp://azurite1:10000/devstoreaccount1のように。container_name- 対象コンテナ名、デフォルトはdefault-container。container_already_exists-falseに設定された場合、新しいコンテナcontainer_nameがストレージアカウントに作成されます。trueに設定された場合、ディスクはコンテナに直接接続し、設定されていない場合、ディスクはアカウントに接続し、container_nameが存在するかどうかを確認し、存在しない場合は作成します。
認証パラメータ（ディスクはすべての利用可能な方法 と 管理された ID 資格情報を試みます）：
connection_string- 接続文字列を使用して認証する際に使用します。account_nameおよびaccount_key- 共有キーを使用して認証する際に使用します。
制限パラメーター（主に内部使用）：
s3_max_single_part_upload_size- Blob Storageへの単一ブロックアップロードのサイズを制限します。min_bytes_for_seek- シーク可能な領域のサイズを制限します。max_single_read_retries- Blob Storageからデータのチャンクを読み取る試行回数を制限します。max_single_download_retries- Blob Storageから読み取り可能なバッファをダウンロードする試行回数を制限します。thread_pool_size-IDiskRemoteが初期化される際のスレッド数を制限します。s3_max_inflight_parts_for_one_file- 1つのオブジェクトに対して同時に実行できるPUTリクエストの数を制限します。
その他のパラメーター：
metadata_path- Blob Storageのメタデータファイルを保存するためのローカルFS上のパス。デフォルト値は/var/lib/clickhouse/disks/<disk_name>/です。skip_access_check-trueの場合、ディスク起動時のディスクアクセスチェックは実行されません。デフォルト値はfalseです。read_resource— このディスクへの読み取りリクエストの スケジューリング に使用されるリソース名。デフォルト値は空の文字列（このディスクに対してIOスケジューリングは有効になっていません）。write_resource— このディスクへの書き込みリクエストの スケジューリング に使用されるリソース名。デフォルト値は空の文字列（このディスクに対してIOスケジューリングは有効になっていません）。metadata_keep_free_space_bytes- メタデータディスクのために予約すべき空きスペースの量。
動作する構成の例は統合テストディレクトリにあります（例: test_merge_tree_azure_blob_storage や test_azure_blob_storage_zero_copy_replication を参照してください）。
ゼロコピー複製は、ClickHouse version 22.8以降、デフォルトで無効になっています。この機能は、本番環境での使用は推奨されていません。
HDFSストレージの使用（未サポート）
このサンプル構成では：
- ディスクは
hdfs（未サポート）タイプです。 - データは
hdfs://hdfs1:9000/clickhouse/にホストされています。
なお、HDFSは未サポートであるため、使用時に問題が発生する可能性があります。何か問題が発生した場合は、修正のためのプルリクエストを自由に作成してください。
HDFSは、コーナーケースでは動作しない可能性があることを考慮してください。
データ暗号化の使用
保存されたデータを暗号化することができます S3 、または、 HDFS（未サポート）、またはローカルディスクです。暗号化モードを有効にするには、構成ファイルに encrypted タイプのディスクを定義し、データが保存されるディスクを選択する必要があります。encrypted ディスクは、書き込まれたすべてのファイルをオンザフライで暗号化し、encrypted ディスクからファイルを読み取るときにそれらを自動的に復号化します。したがって、encrypted ディスクを通常のディスクのように操作できます。
ディスク構成の例：
例えば、ClickHouseがテーブルからファイル store/all_1_1_0/data.bin にデータを書き込むと、実際にはこのファイルは物理ディスク /path1/store/all_1_1_0/data.bin に書き込まれます。
同じファイルを disk2 に書き込む場合、これは実際には物理ディスクのパス /path1/path2/store/all_1_1_0/data.bin に暗号化モードで書き込まれます。
必要なパラメーター：
type—encrypted。そうでなければ暗号化ディスクは作成されません。disk— データ保存用のディスクのタイプ。key— 暗号化と復号化のためのキー。型: Uint64。16進数形式でキーをエンコードするためにkey_hexパラメーターを使用できます。 複数のキーを使用する場合は、id属性を使用して指定できます（以下の例を参照）。
オプションのパラメーター：
path— データが保存されるディスク上の場所へのパス。指定しない場合、データはルートディレクトリに保存されます。current_key_id— 暗号化に使用するキー。指定されたすべてのキーは復号化に使用でき、以前の暗号化データへのアクセスを保持しながら、他のキーに切り替えることができます。algorithm— 暗号化のための Algorithm 。可能な値:AES_128_CTR、AES_192_CTRまたはAES_256_CTR。デフォルト値:AES_128_CTR。キーの長さはアルゴリズムによって異なります:AES_128_CTR— 16バイト,AES_192_CTR— 24バイト、AES_256_CTR— 32バイト。
ディスク構成の例：
ローカルキャッシュの使用
バージョン22.3以降、ストレージ設定でディスク上にローカルキャッシュを構成することが可能です。
バージョン22.3 - 22.7では、キャッシュはs3ディスクタイプのみでサポートされています。バージョン>= 22.8では、キャッシュはすべてのディスクタイプに対してサポートされます：S3、Azure、ローカル、暗号化など。
バージョン>= 23.5では、キャッシュはリモートディスクタイプにのみサポートされています：S3、Azure、HDFS（サポート外）。
キャッシュはLRUキャッシュポリシーを使用します。
バージョン22.8以降の構成例：
バージョン22.8以前の構成例：
ファイルキャッシュ ディスク設定：
これらの設定はディスク設定セクションで定義する必要があります。
-
path- キャッシュディレクトリのパス。デフォルト：なし。この設定は必須です。 -
max_size- キャッシュの最大サイズ（バイトまたは可読形式、例：ki、Mi、Giなど）、例10Gi（この形式は22.10バージョン以降で機能します）。制限に達すると、キャッシュファイルはキャッシュ追放ポリシーに従って排除されます。デフォルト：なし、この設定は必須です。 -
cache_on_write_operations-書き込みスルーキャッシュをオンにすることを許可します（あらゆる書き込み操作におけるデータのキャッシュ：INSERTクエリ、バックグラウンドマージ）。デフォルト：false。書き込みスルーキャッシュは、設定enable_filesystem_cache_on_write_operationsを使用してクエリごとに無効にできます（キャッシュは、キャッシュ設定と対応するクエリ設定の両方が有効になっている場合にのみキャッシュされます）。 -
enable_filesystem_query_cache_limit- 各クエリ内でダウンロードされるキャッシュのサイズを制限できるようにします（ユーザー設定max_query_cache_sizeに依存します）。デフォルト：false。 -
enable_cache_hits_threshold- キャッシュされる前にデータが何回読み込まれる必要があるかを定義する数値。デフォルト：false。このしきい値はcache_hits_thresholdによって定義できます。デフォルト：0、例：データは最初の読み込み試行でキャッシュされます。 -
enable_bypass_cache_with_threshold- 要求された読み取り範囲がしきい値を超えた場合にキャッシュを完全にスキップできるようにします。デフォルト：false。このしきい値はbypass_cache_threasholdによって定義できます。デフォルト：268435456（256Mi）。 -
max_file_segment_size- 単一のキャッシュファイルの最大サイズ（バイトまたは可読形式：ki、Mi、Giなど、例10Gi）。デフォルト：8388608（8Mi）。 -
max_elements- キャッシュファイルの数の制限。デフォルト：10000000。 -
load_metadata_threads- 起動時にキャッシュメタデータを読み込むために使用されるスレッドの数。デフォルト：16。
ファイルキャッシュ クエリ/プロファイル設定：
これらの設定の一部は、デフォルトまたはディスク構成設定で有効になっているキャッシュ機能をクエリ/プロファイル単位で無効にします。たとえば、ディスク構成でキャッシュを有効にし、クエリ/プロファイル設定enable_filesystem_cacheをfalseにすることで無効にできます。また、ディスク構成でcache_on_write_operationsをtrueに設定すると、「書き込みスルー」キャッシュが有効になります。しかし、特定のクエリに対してこの一般設定を無効にする必要がある場合は、設定enable_filesystem_cache_on_write_operationsをfalseに設定すると、特定のクエリ/プロファイルに対する書き込み操作のキャッシュが無効になります。
-
enable_filesystem_cache- ストレージポリシーがcacheディスクタイプで構成されていても、クエリごとにキャッシュを無効にすることを許可します。デフォルト：true。 -
read_from_filesystem_cache_if_exists_otherwise_bypass_cache- クエリでキャッシュが既に存在する場合にのみキャッシュを使用することを許可します。そうでない場合、クエリデータはローカルキャッシュストレージに書き込まれません。デフォルト：false。 -
enable_filesystem_cache_on_write_operations-書き込みスルーキャッシュをオンにします。この設定は、キャッシュ設定のcache_on_write_operationsがオンになっている場合にのみ機能します。デフォルト：false。クラウドデフォルト値：true。 -
enable_filesystem_cache_log-system.filesystem_cache_logテーブルへのログ記録をオンにします。クエリごとのキャッシュ使用の詳細を表示します。特定のクエリのためにオンにすることも、プロファイルで有効にすることもできます。デフォルト：false。 -
max_query_cache_size- ローカルキャッシュストレージに書き込むことができるキャッシュサイズの制限。キャッシュ設定でenable_filesystem_query_cache_limitが有効になっている必要があります。デフォルト：false。 -
skip_download_if_exceeds_query_cache- 設定max_query_cache_sizeの動作を変更することを許可します。デフォルト：true。この設定がオンになっている場合、クエリ中にキャッシュダウンロード制限に達した際には、これ以上キャッシュがキャッシュストレージにダウンロードされません。この設定がオフになっている場合、クエリ中にダウンロード制限に達しても、以前にダウンロードしたデータ（現在のクエリ内で）を排除することでキャッシュが引き続き書き込まれます。例：この二次の動作は、クエリキャッシュ制限を保持しながら「最近使用した」動作を維持することを許可します。
警告 キャッシュ設定とキャッシュクエリ設定は最新のClickHouseバージョンに対応しています。以前のバージョンではサポートされていない機能があるかもしれません。
キャッシュ システムテーブル：
-
system.filesystem_cache- 現在のキャッシュ状態を示すシステムテーブル。 -
system.filesystem_cache_log- クエリごとのキャッシュ使用状況の詳細を示すシステムテーブル。enable_filesystem_cache_log設定がtrueでなければなりません。
キャッシュ コマンド：
-
SYSTEM DROP FILESYSTEM CACHE (<cache_name>) (ON CLUSTER)--<cache_name>が提供されていない場合のみON CLUSTERがサポートされます。 -
SHOW FILESYSTEM CACHES-- サーバーで構成されたファイルシステムキャッシュのリストを表示します。（バージョン<=22.8の場合、このコマンドはSHOW CACHESと呼ばれます）
結果：
DESCRIBE FILESYSTEM CACHE '<cache_name>'- 特定のキャッシュの設定と一般的な統計を表示します。キャッシュ名はSHOW FILESYSTEM CACHESコマンドから取得できます。（バージョン<=22.8の場合、このコマンドはDESCRIBE CACHEと呼ばれます）
キャッシュの現在のメトリック：
-
FilesystemCacheSize -
FilesystemCacheElements
キャッシュの非同期メトリック：
-
FilesystemCacheBytes -
FilesystemCacheFiles
キャッシュプロファイルイベント：
-
CachedReadBufferReadFromSourceBytes,CachedReadBufferReadFromCacheBytes, -
CachedReadBufferReadFromSourceMicroseconds,CachedReadBufferReadFromCacheMicroseconds -
CachedReadBufferCacheWriteBytes,CachedReadBufferCacheWriteMicroseconds -
CachedWriteBufferCacheWriteBytes,CachedWriteBufferCacheWriteMicroseconds
静的Webストレージの使用（読み取り専用）
これは読み取り専用のディスクです。そのデータは読み取られるだけで、決して修正されることはありません。このディスクに新しいテーブルがATTACH TABLEクエリを介して読み込まれます（以下の例参照）。ローカルディスクは実際には使用されず、各SELECTクエリは必要なデータを取得するためのhttpリクエストとなります。テーブルデータのすべての変更は例外を引き起こし、次のタイプのクエリは許可されません：CREATE TABLE, ALTER TABLE, RENAME TABLE, DETACH TABLEおよびTRUNCATE TABLE。
Webストレージは読み取り専用の目的で使用できます。例としては、サンプルデータをホストする場合や、データを移行する場合です。
clickhouse-static-files-uploaderというツールがあり、特定のテーブルのためのデータディレクトリを準備します（SELECT data_paths FROM system.tables WHERE name = 'table_name'）。必要な各テーブルについて、ファイルのディレクトリを取得します。これらのファイルは、たとえば、静的ファイルを持つWebサーバーにアップロードできます。この準備が完了したら、DiskWebを介してこのテーブルを任意のClickHouseサーバーに読み込むことができます。
このサンプル構成では：
- ディスクは
webタイプです。 - データは
http://nginx:80/test1/にホストされています。 - ローカルストレージでキャッシュが使用されます。
Webデータセットが定期的に使用されない場合、クエリ内でストレージを一時的に構成することもできます。 動的設定を参照し、設定ファイルの編集をスキップします。
デモデータセットがGitHubにホストされています。Webストレージ用に自分のテーブルを準備するには、ツールclickhouse-static-files-uploaderを参照してください。
このATTACH TABLEクエリでは、提供されたUUIDがデータのディレクトリ名と一致し、エンドポイントが生のGitHubコンテンツのURLです。
準備が整ったテストケースです。これを設定ファイルに追加する必要があります：
次に、このクエリを実行します：
必要なパラメータ：
type—web。そうでなければ、ディスクは作成されません。endpoint— パス形式のエンドポイントURL。エンドポイントURLは、データが保存されているルートパスを含める必要があります。
オプションのパラメータ：
min_bytes_for_seek— シーク操作を使用するための最小バイト数。デフォルト値：1Mb。remote_fs_read_backoff_threashold— リモートディスクのデータを読み込む際の最大待機時間。デフォルト値：10000秒。remote_fs_read_backoff_max_tries— バックオフでの読み取り試行の最大回数。デフォルト値：5。
クエリがDB:Exception Unreachable URLという例外で失敗した場合、設定を調整してみてください：http_connection_timeout、http_receive_timeout、keep_alive_timeout。
アップロード用のファイルを取得するには、次のコマンドを実行します：
clickhouse static-files-disk-uploader --metadata-path <path> --output-dir <dir>（--metadata-pathはクエリSELECT data_paths FROM system.tables WHERE name = 'table_name'で見つけられます）。
endpointによってファイルを読み込む際、<endpoint>/store/パスに読み込む必要がありますが、設定にはendpointのみを含める必要があります。
サーバーがテーブルを開始する際にディスクの読み込み中にURLに到達できない場合、すべてのエラーがキャッチされます。この場合、エラーが発生した場合は、テーブルを再読み込み（表示されるようになる）するためにDETACH TABLE table_name -> ATTACH TABLE table_nameを実行できます。サーバー起動時にメタデータが正常に読み込まれた場合、テーブルはすぐに利用可能になります。
単一のHTTP読み取り中の最大試行回数を制限するためにhttp_max_single_read_retries設定を使用してください。
ゼロコピー複製（運用準備完了前）
ゼロコピー複製は可能ですが、推奨されないS3およびHDFS（サポート外）のディスクで行うことができます。ゼロコピー複製とは、データが複数の機械にリモートで保存され、同期する必要がある場合、データ本体ではなく、メタデータ（データパーツへのパス）のみが複製されることを意味します。
ゼロコピー複製は、ClickHouseバージョン22.8以上ではデフォルトで無効です。この機能は運用環境での使用は推奨されていません。