Prerequisites
- Ensure you already have a ClickHouse table that you can sink data to. For additional guidance on creating a table and setting up ClickHouse, refer to this quick start guide.
- Ensure you have an upstream materialized view or source that you can sink data from.
We highly recommend using the deduplication engine, like ReplacingMergeTree, in ClickHouse. This is because it addresses the potential problem of duplicate writes in ClickHouse during RisingWave recovery when primary keys can be duplicated.
Syntax
Parameters
Upsert sinks
While RisingWave supportsappend-only sinks for all ClickHouse engines, support for upsert sinks is limited. Additionally, for ReplacingMergeTree engines, an append-only sink will not insert duplicate data.
RisingWave supports upsert sinks for the following ClickHouse engines:
- CollapsingMergeTree:
DELETEoperations are transformed intoINSERT with SIGN = -1. - VersionedCollapsingMergeTree:
DELETEoperations are transformed intoINSERT with SIGN = -1. - ReplacingMergeTree:
DELETEoperations are transformed intoINSERT with SIGN = 1.
Supported table engines
RisingWave supports the following table engines of ClickHouse:- MergeTree
- ReplacingMergeTree
- SummingMergeTree
- AggregatingMergeTree
- CollapsingMergeTree
- VersionedCollapsingMergeTree
- GraphiteMergeTree
- ReplicatedMergeTree
- ReplicatedReplacingMergeTree
- ReplicatedSummingMergeTree
- ReplicatedAggregatingMergeTree
- ReplicatedCollapsingMergeTree
- ReplicatedVersionedCollapsingMergeTree
- ReplicatedGraphiteMergeTree
- SharedMergeTree
- SharedReplacingMergeTree
- SharedSummingMergeTree
- SharedAggregatingMergeTree
- SharedCollapsingMergeTree
- SharedVersionedCollapsingMergeTree
- SharedGraphiteMergeTree
Load data with COPY TO STDOUT
ClickHouse will automatically use the PostgreSQL-compatible COPY command to load data from RisingWave. For more details on the COPY command, see COPY.
Examples
This section includes several examples that you can use if you want to quickly experiment with sinking data to ClickHouse.Create a ClickHouse table (if you do not already have one)
For example, let’s consider creating a basic ClickHouse table with the primary key asseq_id and the ENGINE set to ReplacingMergeTree. It’s important to emphasize that without using ReplacingMergeTree or other deduplication techniques, there is a significant risk of duplicate writes to ClickHouse.
Note that only S3-compatible object store is supported, such as AWS S3 or MinIO.
Create an upstream materialized view or source
The following query creates an append-only source. For more details on creating a source, see CREATE SOURCE.Append-only sink from append-only source
If you have an append-only source and want to create an append-only sink, settype = append-only in the CREATE SINK SQL query.
Append-only sink from upsert source
If you have an upsert source and want to create an append-only sink, settype = append-only and force_append_only = true. This will ignore delete messages in the upstream, and turn upstream update messages into insert messages.
Upsert sink from upsert source
If you have an upsert source and want to create an upsert sink, settype = upsert. When the sink type is upsert, be sure to set the primary_key field to specify the primary key of the downstream ClickHouse table.
Data type mapping
In ClickHouse, the
Nested data type doesn’t support multiple levels of nesting. Therefore, when sinking RisingWave’s struct data to ClickHouse, you need to flatten or restructure the nested data to align with ClickHouse’s requirement.
Before v1.9, when inserting data into a ClickHouse sink, an error would be reported if the values were “nan (not a number)”, “inf (infinity)”, or “-inf (-infinity)”. Since v1.9, we have made a change to this behavior. If the ClickHouse column is nullable, we will insert null values in such cases. If the column is not nullable, we will insert 0 instead.
Please be aware that the range of specific values varies among ClickHouse types and RisingWave types. Refer to the table below for detailed information.