- Amazon S3 オブジェクトストレージ
- Azure Blob Storage
- 非サポート: Hadoop Distributed File System (HDFS)
ClickHouse は external テーブルエンジン もサポートしていますが、これは
このページで説明している外部ストレージオプションとは異なります。external テーブルエンジン では、
Parquet などの一般的なファイルフォーマットで保存されたデータを読み取れます。このページでは、
ClickHouse の
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のいずれかです。- 対応する外部ストレージタイプの設定。
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 セクション で説明されています。web メタデータタイプは、web オブジェクトストレージタイプでのみ使用できます。local メタデータタイプはメタデータファイルをローカルに保存します (各メタデータファイルには、オブジェクトストレージ内のファイルへの対応関係と、それらに関する追加のメタ情報が含まれます) 。
例:
24.1 以降) :
MergeTreeテーブルのデフォルトにするには、
設定ファイルに次のセクションを追加します。
storage_policy の代わりに disk を使用することもできます。この場合、
設定ファイルに storage_policy セクションを用意する必要はなく、disk
セクションだけで十分です。
refresh_parts_interval と table_disk
refresh_parts_interval は、基盤ストレージからデータパーツの一覧を定期的にリフレッシュできるようにします (たとえば、外部から書き込まれたパーツを取り込むため) 。重要なのは、レプリカ間で共有されるメタデータ と レプリカローカルなメタデータ (たとえば、レプリカごとにローカルメタデータを持つ S3) を区別することです。新しいパーツがすべてのレプリカから見えるのは、メタデータが共有されている場合に限られます。オブジェクトストレージを使っているだけでは、メタデータが共有されていることにはなりません。
-
オブジェクトストレージ (たとえば
disk = 's3') は、メタデータ共有を意味しません。 メタデータがレプリカごとにローカルに保存されている場合 (デフォルト) 、各レプリカはオブジェクトストレージ内のブロブへのポインタを独立して管理します。あるレプリカで加えた変更は、ほかのレプリカからは見えません。その場合、各レプリカが読むメタデータはレプリカローカルであるため、refresh_parts_intervalを使っても新しいパーツはレプリカ間で見えるようになりません。 -
パーツの自動リフレッシュには、ファイルシステムのメタデータが共有されている必要があります (または、テーブルがテーブル所有の読み取り専用メタデータを使用しており、リフレッシュを適用できる必要があります) 。
table_disk = trueをテーブルローカルディスクと組み合わせて設定すること (たとえばSETTINGS disk = disk(type=object_storage, ...), table_disk = true) は、正しい動作を実現する方法の 1 つです。この場合、テーブルがメタデータのライフサイクルを管理し、ストレージは読み取り専用として扱われるため、refresh_parts_intervalが実行され、外部から追加されたパーツを検出できます。 -
グローバルに定義されたディスク (たとえば
storage_configuration内のdisk = 's3') とデフォルトのローカルメタデータを使う場合、各レプリカはそれぞれ独自のメタデータ状態を持ちます。ブロブが S3 にあっても、refresh_parts_intervalの観点ではそのストレージは共有とは見なされず、ClickHouse の外部または別のレプリカで作成された新しいパーツは検出されません。
table_disk = true を指定したテーブルレベルのディスクを使用してください。レプリカローカルなメタデータ環境で refresh_parts_interval だけに頼っても、期待どおりにパーツはリフレッシュされません。
refresh_parts_interval は ReplicatedMergeTree テーブルでは使用されません。
レプリケートテーブルでは、パーツはすでにレプリケーションの仕組みによって同期されます。
この設定が適用されるのは、パーツが外部から書き込まれ、メタデータのリフレッシュが必要な非レプリケートの MergeTree テーブルだけです。動的構成
CREATE/ATTACH クエリの設定で構成します。
次のクエリ例は、上記の動的ディスク構成を基に、
ローカルディスクを使用して URL に保存されたテーブルのデータを cache する方法を示しています。
type=web のディスクが
type=cache のディスクの内側にネストされていることに注意してください。
この例では
type=web を使用していますが、ローカルディスクを含め、どのディスクタイプでも動的に構成できます。
ローカルディスクでは、path 引数を
server 設定パラメータ custom_local_disks_base_directory の配下にする必要があります。これには
デフォルト値がないため、ローカルディスクを使用する場合はこれも設定してください。web はサーバー設定ファイル内の値です:
S3ストレージの利用
必須パラメータ
オプションパラメータ
Google Cloud Storage (GCS) も、
s3 タイプを使用してサポートされています。詳しくは GCS バックエンドの MergeTree を参照してください。Plain Storage の使用
22.10 では、新しいディスクタイプ s3_plain が導入され、追記不可のストレージを提供します。
この設定パラメータは、s3 ディスクタイプと同じです。
s3 ディスクタイプとは異なり、このタイプはデータをそのまま保存します。つまり、
ランダムに生成されたブロブ名ではなく通常のファイル名を使用し、
(ClickHouse がローカルディスクにファイルを保存するのと同じように) 、ローカルには
メタデータを保存しません。たとえば、これは s3 上のデータから導出されます。
このディスクタイプでは、既存データに対するマージを実行できず、新しいデータの挿入も
できないため、テーブルの静的なバージョンを保持できます。
このディスクタイプのユースケースの 1 つは、その上にバックアップを作成することです。これは
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 Plain Rewritable Storage の使用
s3_plain_rewritable は 24.4 で導入されました。
s3_plain ディスクタイプと同様に、メタデータファイル用の追加ストレージは必要ありません。代わりに、メタデータは S3 に保存されます。
s3_plain ディスクタイプとは異なり、s3_plain_rewritable ではマージを実行でき、INSERT 操作もサポートされます。
Mutations とテーブルのレプリケーションはサポートされていません。
このディスクタイプのユースケースの 1 つは、非レプリケートの MergeTree テーブルです。s3 ディスクタイプも非レプリケートの MergeTree テーブルに適していますが、テーブルのローカルメタデータが不要で、利用できる操作が限られていても問題ない場合は、s3_plain_rewritable ディスクタイプを選択できます。たとえば、システムテーブルで有用です。
設定:
24.5 以降では、plain_rewritable メタデータタイプを使用して任意のオブジェクトストレージディスク
(s3、azure、local) を設定できます。
Azure Blob Storage の使用
MergeTree ファミリーのテーブルエンジンでは、azure_blob_storage タイプのディスクを使用して
データを Azure Blob Storage に保存できます。
設定の記述:
接続パラメーター
認証パラメーター (ディスクは利用可能なすべての方法 および Managed Identity Credential を試行します) :
制限パラメータ
その他のパラメータ
動作する構成例は結合テストディレクトリにあります (例: test_merge_tree_azure_blob_storage または test_azure_blob_storage_zero_copy_replication を参照してください) 。
ゼロコピーレプリケーションは本番環境には未対応ですゼロコピーレプリケーションは、ClickHouse バージョン 22.8 以降ではデフォルトで無効化されています。この機能は本番環境での使用は推奨されません。
HDFS ストレージの使用 (未サポート)
- ディスクタイプは
hdfsです (未サポート) - データは
hdfs://hdfs1:9000/clickhouse/に配置されています
データ暗号化を使用する
encrypted 型のディスクを定義し、データの保存先となるディスクを指定する必要があります。encrypted ディスクは、書き込まれるすべてのファイルをリアルタイムで暗号化し、encrypted ディスク上のファイルを読み取る際には自動的に復号します。そのため、encrypted ディスクは通常のディスクと同じように扱えます。
ディスク設定の例:
disk1 にあるファイル store/all_1_1_0/data.bin に書き込む場合、実際にはこのファイルは物理ディスク上の /path1/store/all_1_1_0/data.bin というpathに書き込まれます。
同じファイルを disk2 に書き込む場合、実際には物理ディスク上の /path1/path2/store/all_1_1_0/data.bin というpathに暗号化された状態で書き込まれます。
必須パラメータ
任意のパラメータ
ディスク設定の例:
ローカル cache の使用
s3 ディスク type でのみサポートされます。バージョン >= 22.8 では、cache は S3、Azure、Local、Encrypted など、あらゆるディスク type でサポートされます。
バージョン >= 23.5 では、cache は S3、Azure、HDFS (非サポート) などのリモートディスク type でのみサポートされます。
cache には LRU cache ポリシーが使用されます。
バージョン 22.8 以降の構成例:
注: サイズ値はki、Mi、Giなどの単位をサポートします (例:10Gi) 。
ファイルcacheのクエリ/プロファイル設定
cache関連のシステムテーブル
cacheコマンド
SYSTEM CLEAR|DROP FILESYSTEM CACHE (<cache_name>) (ON CLUSTER) — ON CLUSTER
<cache_name> が指定されていない場合にのみ使用できます
SHOW FILESYSTEM CACHES
22.8 以下のバージョンでは、このコマンドは SHOW CACHES という名前です)
Query
Response
DESCRIBE FILESYSTEM CACHE '<cache_name>'
SHOW FILESYSTEM CACHES コマンドで確認できます。 (22.8 以下のバージョンでは、
このコマンドは DESCRIBE CACHE という名前です)
Query
Response
静的 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/でホストされています - ローカルストレージ上の cache が使用されます
ATTACH TABLE クエリでは、指定された UUID がデータのディレクトリ名に対応しており、エンドポイントは GitHub の生コンテンツの URL です。
パラメータ
オプションパラメータ
クエリが例外
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 以降では、ゼロコピーレプリケーションはデフォルトで無効になっています。 この機能を本番環境で使用することは推奨されません。