External Disks for Storing Data
データは、ClickHouseで処理されると通常、ClickHouseサーバーと同じマシンのローカルファイルシステムに保存されます。これは大容量のディスクを必要とし、十分に高価になる可能性があります。それを避けるために、リモートにデータを保存することができます。さまざまなストレージがサポートされています:
- Amazon S3 オブジェクトストレージ。
- Azure Blob Storage。
- サポートされていない: Hadoop分散ファイルシステム (HDFS)
MergeTree
ファミリまたは Log
ファミリテーブルのストレージ構成を説明しています。Amazon S3
ディスクに保存されたデータで作業するには、S3テーブルエンジンを使用します。- Azure Blob Storageに保存されたデータで作業するには、AzureBlobStorageテーブルエンジンを使用します。
- サポートされていない: Hadoop分散ファイルシステムのデータで作業するには、HDFSテーブルエンジンを使用します。
外部ストレージの設定
MergeTreeおよびLogファミリのテーブルエンジンは、S3
、AzureBlobStorage
、HDFS
(サポートされていません)にデータを保存できます。これはそれぞれ、s3
、azure_blob_storage
、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
— S3エンドポイントURLで、path
またはvirtual hosted
スタイルです。エンドポイントURLには、バケットとデータを保存するためのルートパスが含まれている必要があります。access_key_id
— S3アクセのキーID。secret_access_key
— S3シークレットアクセスキー。
オプションのパラメータ:
region
— S3リージョン名。support_batch_delete
— バッチ削除がサポートされているかどうかを確認します。Google Cloud Storage (GCS)を使う場合はfalse
に設定してください。GCSはバッチ削除をサポートしていないため、チェックを無効にすることでログにエラーメッセージが表示されるのを防ぎます。use_environment_credentials
— 環境変数 AWS_ACCESS_KEY_ID および AWS_SECRET_ACCESS_KEY から AWS 認証情報を読み取ります。もし存在すれば、AWS_SESSION_TOKENも読み取ります。デフォルト値はfalse
です。use_insecure_imds_request
—true
に設定されている場合、S3クライアントはAmazon EC2メタデータからクレデンシャルを取得する際に、不安定なIMDSリクエストを使用します。デフォルト値はfalse
です。expiration_window_seconds
— 有効期限ベースの認証情報が期限切れかどうかを確認するための猶予期間。オプションで、デフォルト値は120
です。proxy
— S3エンドポイントのプロキシ設定。proxy
ブロック内の各uri
要素は、プロキシURLを含む必要があります。connect_timeout_ms
— ソケット接続タイムアウト(ミリ秒)。デフォルト値は10秒
です。request_timeout_ms
— リクエストタイムアウト(ミリ秒)。デフォルト値は5秒
です。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オブジェクトにアクセスするために必要なヘッダーが設定されます。空の文字列が指定された場合、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
未満であるものを、このendpoint
オプションの以前のroot path
をここに設定する必要があります。
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
からは、plain
メタデータタイプを使用して任意のオブジェクトストレージディスク(s3
、azure
、hdfs
(サポートされていません)、local
)を構成することが可能です。
構成:
S3プレーンリライト可能ストレージの使用
新しいディスクタイプs3_plain_rewritable
が24.4
で導入されました。
s3_plain
ディスクタイプと同様に、メタデータファイルのための追加のストレージは必要とせず、メタデータはS3に保存されます。
s3_plain
ディスクタイプとは異なり、s3_plain_rewritable
はマージを実行し、INSERT操作をサポートします。
変異やテーブルのレプリケーションはサポートされていません。
このディスクタイプの使用例は、レプリケートされていないMergeTree
テーブルです。s3
ディスクタイプは非レプリケートのMergeTreeテーブルに適していますが、テーブルのローカルメタデータが不要で、限られた操作セットを受け入れることができる場合には、s3_plain_rewritable
ディスクタイプを選択できます。これは、たとえばシステムテーブルに役立つかもしれません。
構成:
は次の内容に等しいです:
24.5
からは、plain_rewritable
メタデータタイプを使用して任意のオブジェクトストレージディスク(s3
、azure
、local
)を構成することが可能です。
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
が存在するか確認し、存在しない場合は作成します。
認証パラメータ(ディスクはすべての利用可能な方法 および 管理されたアイデンティティ認証情報を試みます):
connection_string
- 接続文字列を使用した認証。account_name
とaccount_key
- 共有キーを使用した認証。
制限パラメータ(主に内部使用のため):
s3_max_single_part_upload_size
- Blobストレージへの単一ブロックアップロードのサイズを制限します。min_bytes_for_seek
- シーク可能な領域のサイズを制限します。max_single_read_retries
- Blobストレージからデータチャンクを読み込むための試行回数を制限します。max_single_download_retries
- Blobストレージから可読バッファをダウンロードするための試行回数を制限します。thread_pool_size
-IDiskRemote
がインスタンス化されるスレッドの数を制限します。s3_max_inflight_parts_for_one_file
- 一つのオブジェクトに対して同時に実行できるPUTリクエストの数を制限します。
その他のパラメータ:
metadata_path
- Blobストレージ用のメタデータファイルを保存するためのローカル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バージョン22.8以降でデフォルトで無効です。この機能は、本番用途での使用を推奨しません。
HDFSストレージの使用(サポートされていません)
このサンプル構成では、
- ディスクは
hdfs
(サポートされていません)タイプです - データは
hdfs://hdfs1:9000/clickhouse/
にホストされています
HDFSはサポートされていないため、使用時に問題が発生する可能性があります。問題が発生した場合は、修正を行うためにプルリクエストを気軽に作成してください。
HDFSは、コーナーケースが存在する場合には機能しない可能性があることに注意してください。
データ暗号化の使用
オブジェクトストレージに保存されたデータを暗号化できますまたはHDFS(サポートされていません)外部ディスクまたはローカルディスクに保存されたデータを暗号化できます。暗号化モードをオンにするには、構成ファイルでタイプ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
— アルゴリズムによる暗号化。可能な値:AES_128_CTR
、AES_192_CTR
またはAES_256_CTR
。デフォルト値:AES_128_CTR
。キーの長さはアルゴリズムによります:AES_128_CTR
— 16バイト、AES_192_CTR
— 24バイト、AES_256_CTR
— 32バイト。
ディスク構成の例:
Using local cache
バージョン 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
-write-through
キャッシュをオンにすることを許可します(INSERT
クエリ、バックグラウンドマージによるすべての書き込み操作でデータをキャッシュします)。デフォルト:false
。write-through
キャッシュは、設定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
に設定すると、「write-through」キャッシュが有効になります。しかし、特定のクエリに対してこの一般的な設定を無効にする必要がある場合、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
-write-through
キャッシュをオンにします。この設定はキャッシュ構成の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
Using static Web storage (read-only)
これは読み取り専用のディスクです。そのデータは読み取られるだけで、決して変更されることはありません。このディスクに新しいテーブルは 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/
にホストされています。 - ローカルストレージにキャッシュが使用されます。
ウェブデータセットが通常使用されないと予想される場合、クエリ内で一時的にストレージを構成することもできます。詳細は 動的構成 を参照し、構成ファイルの編集をスキップしてください。
デモデータセットが GitHub にホストされています。ウェブストレージ用の独自のテーブルを準備するには、ツール clickhouse-static-files-uploader を参照してください。
この ATTACH TABLE
クエリでは、提供された UUID
がデータのディレクトリ名と一致し、エンドポイントは GitHub の生データの URL です。
準備されたテストケースです。この構成を config に追加する必要があります:
そして、このクエリを実行します:
必要なパラメータ:
type
—web
。さもなければディスクは作成されません。endpoint
—path
形式のエンドポイント URL。エンドポイント URL には、データを保存するルートパスが含まれている必要があります。アップロードされた場所です。
オプションのパラメータ:
min_bytes_for_seek
— 逐次読み取りではなく、シーク操作を使用するための最小バイト数。デフォルト値:1
Mb。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/
パスに読み込む必要がありますが、構成にはエンドポイントのみを含める必要があります。
サーバがテーブルを起動する際にディスクの読み込み時に URL にアクセスできない場合、すべてのエラーが捕捉されます。この場合にエラーが発生した場合、テーブルは再読み込み(表示されるようになります)することができます:DETACH TABLE table_name
-> ATTACH TABLE table_name
。サーバの起動時にメタデータが正常に読み込まれた場合、テーブルはすぐに利用可能になります。
http_max_single_read_retries 設定を使用して、単一の HTTP 読み込み中の最大再試行回数を制限します。
Zero-copy Replication (not ready for production)
ゼロコピー複製は可能ですが、推奨されません。S3
および HDFS
(未サポート)ディスクに関してです。ゼロコピー複製とは、データがいくつかのマシンにリモートで保存され、同期する必要がある場合、データ自体ではなくメタデータ(データパーツへのパス)が複製されることを意味します。
ゼロコピー複製は、ClickHouse バージョン 22.8 以降、デフォルトで無効になっています。この機能は本番環境での使用は推奨されていません。