メインコンテンツへスキップ
ClickHouse で処理されるデータは通常、ClickHouse server が稼働している マシンのローカルファイルシステムに保存されます。そのため大容量のディスクが必要になり、 コストが高くなる場合があります。データをローカルに保存しないようにするため、 以下のようなストレージオプションがサポートされています。
  1. Amazon S3 オブジェクトストレージ
  2. Azure Blob Storage
  3. 非サポート: Hadoop Distributed File System (HDFS)

ClickHouse は external テーブルエンジン もサポートしていますが、これは このページで説明している外部ストレージオプションとは異なります。external テーブルエンジン では、 Parquet などの一般的なファイルフォーマットで保存されたデータを読み取れます。このページでは、 ClickHouse の MergeTree ファミリーまたは Log ファミリーのテーブル向けの ストレージ構成について説明します。
  1. Amazon S3 ディスクに保存されたデータを扱うには、S3 テーブルエンジン を使用します。
  2. Azure Blob Storage に保存されたデータを扱うには、AzureBlobStorage テーブルエンジン を使用します。
  3. Hadoop Distributed File System (非サポート) 内のデータを扱うには、HDFS テーブルエンジン を使用します。

外部ストレージを構成する

MergeTree および Log ファミリーに属するテーブルエンジンでは、型がそれぞれ s3azure_blob_storagehdfs (未サポート) のディスクを使用して、データを S3AzureBlobStorageHDFS (未サポート) に保存できます。 ディスクの設定には、次のものが必要です。
  1. type セクション。値は s3azure_blob_storagehdfs (未サポート) 、local_blob_storageweb のいずれかです。
  2. 対応する外部ストレージタイプの設定。
ClickHouse バージョン 24.1 以降では、新しい設定オプションを使用できます。 これには、次の指定が必要です。
  1. typeobject_storage にする
  2. object_storage_types3azure_blob_storage (24.3 以降では単に azure も可) 、hdfs (未サポート) 、local_blob_storage (24.3 以降では単に local も可) 、web のいずれかにする

必要に応じて metadata_type も指定できます (デフォルトは local) 。また、plainweb、および 24.4 以降では plain_rewritable も設定できます。 plain メタデータタイプの使用方法は plain storage セクション で説明されています。web メタデータタイプは、web オブジェクトストレージタイプでのみ使用できます。local メタデータタイプはメタデータファイルをローカルに保存します (各メタデータファイルには、オブジェクトストレージ内のファイルへの対応関係と、それらに関する追加のメタ情報が含まれます) 。 例:
は次の設定と同等です (バージョン 24.1 以降) :
以下の設定:
は次と等しくなります:
ストレージ構成全体の例は、次のようになります。
バージョン24.1以降では、次のようになる場合もあります:
特定の種類のストレージをすべてのMergeTreeテーブルのデフォルトにするには、 設定ファイルに次のセクションを追加します。
特定のテーブルに対して特定のストレージポリシーを設定したい場合は、 テーブルの作成時に設定でそれを定義できます:
storage_policy の代わりに disk を使用することもできます。この場合、 設定ファイルに storage_policy セクションを用意する必要はなく、disk セクションだけで十分です。

refresh_parts_interval と table_disk

この設定は、パーツが外部から書き込まれる可能性があり、ストレージ上のメタデータを再検出する必要がある、非レプリケートの MergeTree テーブルを対象としています。 MergeTree 設定 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 する方法を示しています。
以下の例では、外部ストレージにcacheを追加します。
以下でハイライトされている設定では、type=web のディスクが type=cache のディスクの内側にネストされていることに注意してください。
この例では type=web を使用していますが、ローカルディスクを含め、どのディスクタイプでも動的に構成できます。 ローカルディスクでは、path 引数を server 設定パラメータ custom_local_disks_base_directory の配下にする必要があります。これには デフォルト値がないため、ローカルディスクを使用する場合はこれも設定してください。
config ベースの構成と sql で定義した構成を組み合わせることも 可能です:
ここで、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 メタデータタイプを使用して、任意のオブジェクトストレージディスク (s3azurehdfs (未サポート) 、local) を設定できるようになりました。 設定:

S3 Plain Rewritable Storage の使用

新しいディスクタイプ s3_plain_rewritable24.4 で導入されました。 s3_plain ディスクタイプと同様に、メタデータファイル用の追加ストレージは必要ありません。代わりに、メタデータは S3 に保存されます。 s3_plain ディスクタイプとは異なり、s3_plain_rewritable ではマージを実行でき、INSERT 操作もサポートされます。 Mutations とテーブルのレプリケーションはサポートされていません。 このディスクタイプのユースケースの 1 つは、非レプリケートの MergeTree テーブルです。s3 ディスクタイプも非レプリケートの MergeTree テーブルに適していますが、テーブルのローカルメタデータが不要で、利用できる操作が限られていても問題ない場合は、s3_plain_rewritable ディスクタイプを選択できます。たとえば、システムテーブルで有用です。 設定:
等しい
24.5 以降では、plain_rewritable メタデータタイプを使用して任意のオブジェクトストレージディスク (s3azurelocal) を設定できます。

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/ に配置されています
なお、HDFS はサポート対象外のため、使用時に問題が発生する可能性があります。問題が発生した場合は、修正内容を含むプルリクエストをぜひ作成してください。
HDFS は一部の特殊なケースでは正常に動作しない可能性がある点に留意してください。

データ暗号化を使用する

S3HDFS (未サポート) の外部ディスク、またはローカルディスクに保存されるデータは暗号化できます。暗号化モードを有効にするには、設定ファイルで encrypted 型のディスクを定義し、データの保存先となるディスクを指定する必要があります。encrypted ディスクは、書き込まれるすべてのファイルをリアルタイムで暗号化し、encrypted ディスク上のファイルを読み取る際には自動的に復号します。そのため、encrypted ディスクは通常のディスクと同じように扱えます。 ディスク設定の例:
たとえば、ClickHouseがあるtableのデータを 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 の使用

バージョン 22.3 以降では、ストレージ構成内のディスクに対してローカル cache を設定できます。 バージョン 22.3 ~ 22.7 では、cache は s3 ディスク type でのみサポートされます。バージョン >= 22.8 では、cache は S3、Azure、Local、Encrypted など、あらゆるディスク type でサポートされます。 バージョン >= 23.5 では、cache は S3、Azure、HDFS (非サポート) などのリモートディスク type でのみサポートされます。 cache には LRU cache ポリシーが使用されます。 バージョン 22.8 以降の構成例:
22.8より前のバージョンの設定例:
File Cache ディスク設定: これらの設定は、ディスク設定セクションで定義する必要があります。
: サイズ値は kiMiGi などの単位をサポートします (例: 10Gi) 。

ファイルcacheのクエリ/プロファイル設定

cache設定およびcacheのクエリ設定は、最新バージョンの ClickHouse に対応しています。 それ以前のバージョンでは、一部サポートされていない場合があります。

cache関連のシステムテーブル

cacheコマンド

SYSTEM CLEAR|DROP FILESYSTEM CACHE (<cache_name>) (ON CLUSTER)ON CLUSTER
このコマンドは、<cache_name> が指定されていない場合にのみ使用できます
SHOW FILESYSTEM CACHES
server に設定されているファイルシステムcacheの一覧を表示します。 (22.8 以下のバージョンでは、このコマンドは SHOW CACHES という名前です)
Query
Response
DESCRIBE FILESYSTEM CACHE '<cache_name>'
特定の cache の設定と、いくつかの一般的な統計情報を表示します。 cache 名は 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 が使用されます
ストレージは、クエリ内で一時的に設定することもできます。Web データセットを継続的に使用する予定がない場合は、動的設定を参照し、設定ファイルの編集を省略してください。デモデータセット は GitHub でホストされています。独自のテーブルを Web ストレージ向けに準備するには、ツール clickhouse-static-files-uploader を参照してください。
この ATTACH TABLE クエリでは、指定された UUID がデータのディレクトリ名に対応しており、エンドポイントは GitHub の生コンテンツの URL です。
すぐに試せるテストケースです。config にこの設定を追加する必要があります。
次に、このクエリを実行します。

パラメータ

オプションパラメータ

クエリが例外 DB:Exception Unreachable URL で失敗する場合は、設定 http_connection_timeouthttp_receive_timeoutkeep_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 以降では、ゼロコピーレプリケーションはデフォルトで無効になっています。 この機能を本番環境で使用することは推奨されません。
最終更新日 2026年6月25日