- Amazon S3 object storage.
- Azure Blob Storage.
- Unsupported: The Hadoop Distributed File System (HDFS)
ClickHouse also has support for external table engines, which are different from
the external storage option described on this page, as they allow reading data
stored in some general file format (like Parquet). On this page we are describing
storage configuration for the ClickHouse
MergeTree family or Log family tables.- to work with data stored on
Amazon S3disks, use the S3 table engine. - to work with data stored in Azure Blob Storage, use the AzureBlobStorage table engine.
- to work with data in the Hadoop Distributed File System (unsupported), use the HDFS table engine.
Configure external storage
MergeTree and Log
family table engines can store data to S3, AzureBlobStorage, HDFS (unsupported) using a disk with types s3,
azure_blob_storage, hdfs (unsupported) respectively.
Disk configuration requires:
- A
typesection, equal to one ofs3,azure_blob_storage,hdfs(unsupported),local_blob_storage,web. - Configuration of a specific external storage type.
- A
typeequal toobject_storage object_storage_type, equal to one ofs3,azure_blob_storage(or justazurefrom24.3),hdfs(unsupported),local_blob_storage(or justlocalfrom24.3),web.
Optionally,
metadata_type can be specified (it is equal to local by default), but it can also be set to plain, web and, starting from 24.4, plain_rewritable.
Usage of plain metadata type is described in plain storage section, web metadata type can be used only with web object storage type, local metadata type stores metadata files locally (each metadata files contains mapping to files in object storage and some additional meta information about them).
For example:
24.1):
MergeTree tables,
add the following section to the configuration file:
disk instead of storage_policy. In this case it is not necessary
to have the storage_policy section in the configuration file, and a disk
section is enough.
refresh_parts_interval and table_disk
This setting is intended for non-Replicated MergeTree tables where parts may be written externally and metadata discovery must be refreshed from storage. The MergeTree settingrefresh_parts_interval enables periodic refresh of the list of data parts from the underlying storage (e.g. to pick up parts written externally). The important distinction is shared metadata across replicas vs replica-local metadata (e.g. S3 with local metadata per replica): only when metadata is shared will new parts be visible to all replicas. Using object storage alone does not imply shared metadata.
-
Object storage (e.g.
disk = 's3') does not imply shared metadata. When metadata is stored locally per replica (the default), each replica independently manages its pointers to blobs in object storage. Changes made on one replica are not visible to others. In that case,refresh_parts_intervaldoes not make new parts visible across replicas, because the metadata each replica reads is replica-local. -
Automatic part refreshing requires that the filesystem metadata be shared (or that the table use table-owned, readonly metadata so that refresh is applicable). Setting
table_disk = truetogether with a table-local disk (e.g.SETTINGS disk = disk(type=object_storage, ...), table_disk = true) is one way to get the correct semantics: the table owns the metadata life cycle and the storage is treated as readonly, sorefresh_parts_intervalruns and externally added parts can be discovered. -
With a globally defined disk (e.g.
disk = 's3'instorage_configuration) and default local metadata, each replica has its own metadata state. Even though blobs may be in S3, the storage is not considered shared for the purpose ofrefresh_parts_interval, and new parts created outside ClickHouse or on another replica will not be detected.
table_disk = true as above. Relying only on refresh_parts_interval with replica-local metadata will not refresh parts as expected.
refresh_parts_interval is not used for ReplicatedMergeTree tables.
Replicated tables already synchronize parts through the replication mechanism.
This setting is only applicable to non-replicated MergeTree tables where parts are written externally and metadata refresh is required.Dynamic Configuration
There is also a possibility to specify storage configuration without a predefined disk in configuration in a configuration file, but can be configured in theCREATE/ATTACH query settings.
The following example query builds on the above dynamic disk configuration and
shows how to use a local disk to cache data from a table stored at a URL.
type=web is nested within
the disk of type=cache.
The example uses
type=web, but any disk type can be configured as dynamic,
including local disk. Local disks require a path argument to be inside the
server config parameter custom_local_disks_base_directory, which has no
default, so set that also when using local disk.web is from the server configuration file:
Using S3 Storage
Required parameters
Optional parameters
Google Cloud Storage (GCS) is also supported using the type
s3. See GCS backed MergeTree.Using Plain Storage
In22.10 a new disk type s3_plain was introduced, which provides a write-once storage.
Configuration parameters for it are the same as for the s3 disk type.
Unlike the s3 disk type, it stores data as is. In other words,
instead of having randomly generated blob names, it uses normal file names
(the same way as ClickHouse stores files on local disk) and does not store any
metadata locally. For example, it is derived from data on s3.
This disk type allows keeping a static version of the table, as it does not
allow executing merges on the existing data and does not allow inserting of new
data. A use case for this disk type is to create backups on it, which can be done
via BACKUP TABLE data TO Disk('plain_disk_name', 'backup_name'). Afterward,
you can do RESTORE TABLE data AS data_restored FROM Disk('plain_disk_name', 'backup_name')
or use ATTACH TABLE data (...) ENGINE = MergeTree() SETTINGS disk = 'plain_disk_name'.
Configuration:
24.1 it is possible configure any object storage disk (s3, azure, hdfs (unsupported), local) using
the plain metadata type.
Configuration:
Using S3 Plain Rewritable Storage
A new disk types3_plain_rewritable was introduced in 24.4.
Similar to the s3_plain disk type, it does not require additional storage for
metadata files. Instead, metadata is stored in S3.
Unlike the s3_plain disk type, s3_plain_rewritable allows executing merges
and supports INSERT operations.
Mutations and replication of tables are not supported.
A use case for this disk type is for non-replicated MergeTree tables. Although
the s3 disk type is suitable for non-replicated MergeTree tables, you may opt
for the s3_plain_rewritable disk type if you do not require local metadata
for the table and are willing to accept a limited set of operations. This could
be useful, for example, for system tables.
Configuration:
24.5 it is possible to configure any object storage disk
(s3, azure, local) using the plain_rewritable metadata type.
Using Azure Blob Storage
MergeTree family table engines can store data to Azure Blob Storage
using a disk with type azure_blob_storage.
Configuration markup:
Connection parameters
Authentication parameters (the disk will try all available methods and Managed Identity Credential):
Limit parameters
Other parameters
Examples of working configurations can be found in integration tests directory (see e.g. test_merge_tree_azure_blob_storage or test_azure_blob_storage_zero_copy_replication).
Zero-copy replication is not ready for productionZero-copy replication is disabled by default in ClickHouse version 22.8 and higher. This feature is not recommended for production use.
Using HDFS storage (Unsupported)
In this sample configuration:- the disk is of type
hdfs(unsupported) - the data is hosted at
hdfs://hdfs1:9000/clickhouse/
Using Data Encryption
You can encrypt the data stored on S3, or HDFS (unsupported) external disks, or on a local disk. To turn on the encryption mode, in the configuration file you must define a disk with the typeencrypted and choose a disk on which the data will be saved. An encrypted disk ciphers all written files on the fly, and when you read files from an encrypted disk it deciphers them automatically. So you can work with an encrypted disk like with a normal one.
Example of disk configuration:
store/all_1_1_0/data.bin to disk1, then in fact this file will be written to the physical disk along the path /path1/store/all_1_1_0/data.bin.
When writing the same file to disk2, it will actually be written to the physical disk at the path /path1/path2/store/all_1_1_0/data.bin in encrypted mode.
Required Parameters
Optional Parameters
Example of disk configuration:
Using local cache
It is possible to configure local cache over disks in storage configuration starting from version 22.3. For versions 22.3 - 22.7 cache is supported only fors3 disk type. For versions >= 22.8 cache is supported for any disk type: S3, Azure, Local, Encrypted, etc.
For versions >= 23.5 cache is supported only for remote disk types: S3, Azure, HDFS (unsupported).
Cache uses LRU cache policy.
Example of configuration for versions later or equal to 22.8:
Note: Size values support units likeki,Mi,Gi, etc. (e.g.,10Gi).
File Cache Query/Profile Settings
Cache system tables
Cache commands
This command is only supported when no<cache_name> is provided
Show a list of filesystem caches which were configured on the server.
(For versions less than or equal to 22.8 the command is named SHOW CACHES)
Query
Response
SHOW FILESYSTEM CACHES command. (For versions less
than or equal to 22.8 the command is named DESCRIBE CACHE)
Query
Response
Using static Web storage (read-only)
This is a read-only disk. Its data is only read and never modified. A new table is loaded to this disk viaATTACH TABLE query (see example below). Local disk
is not actually used, each SELECT query will result in a http request to
fetch required data. All modification of the table data will result in an
exception, i.e. the following types of queries are not allowed: CREATE TABLE,
ALTER TABLE, RENAME TABLE,
DETACH TABLE and TRUNCATE TABLE.
Web storage can be used for read-only purposes. An example use is for hosting
sample data, or for migrating data. There is a tool clickhouse-static-files-uploader,
which prepares a data directory for a given table (SELECT data_paths FROM system.tables WHERE name = 'table_name').
For each table you need, you get a directory of files. These files can be uploaded
to, for example, a web server with static files. After this preparation,
you can load this table into any ClickHouse server via DiskWeb.
In this sample configuration:
- the disk is of type
web - the data is hosted at
http://nginx:80/test1/ - a cache on local storage is used
ATTACH TABLE query the UUID provided matches the directory name of the data, and the endpoint is the URL for the raw GitHub content.
Required parameters
Optional parameters
If a query fails with an exception
DB:Exception Unreachable URL, then you can try to adjust the settings: http_connection_timeout, http_receive_timeout, keep_alive_timeout.
To get files for upload run:
clickhouse static-files-disk-uploader --metadata-path <path> --output-dir <dir> (--metadata-path can be found in query SELECT data_paths FROM system.tables WHERE name = 'table_name').
When loading files by endpoint, they must be loaded into <endpoint>/store/ path, but config must contain only endpoint.
If URL is not reachable on disk load when the server is starting up tables, then all errors are caught. If in this case there were errors, tables can be reloaded (become visible) via DETACH TABLE table_name -> ATTACH TABLE table_name. If metadata was successfully loaded at server startup, then tables are available straight away.
Use http_max_single_read_retries setting to limit the maximum number of retries during a single HTTP read.
Zero-copy Replication (not ready for production)
Zero-copy replication is possible, but not recommended, withS3 and HDFS (unsupported) disks. Zero-copy replication means that if the data is stored remotely on several machines and needs to be synchronized, then only the metadata is replicated (paths to the data parts), but not the data itself.
Zero-copy replication is not ready for productionZero-copy replication is disabled by default in ClickHouse version 22.8 and higher. This feature is not recommended for production use.