ClickHouse的表引擎介绍（三）

引入表引擎的概念以及特点

官方网站：https://clickhouse.com/docs/zh/engines/table-engines/

**表引擎决定了如何存储表的数据。**包括:

➢ 数据的存储方式和位置，写到哪里以及从哪里读取数据。

➢ 支持哪些查询以及如何支持

比如数组不能在merge引擎中使用。

➢ 并发数据访问。

➢ 索引的使用(如果存在)。

➢ 是否可以执行多线程请求。

➢ 数据复制参数。

表引擎的使用方式就是必须显式在创建表时定义该表使用的引擎，以及引擎使用的相关参数。

** 特别注意：引擎的名称大小写敏感。**

一、TinyLog

以列文件的形式保存在磁盘上，不支持索引，没有并发控制。一般保存少量数据的小表， 生产环境上作用有限。可以用于平时练习测试用。

create table t_tinylog ( id String, name String) engine=TinyLog;

二、Memory

内存引擎，数据以未压缩的原始形式直接保存在内存当中，服务器重启数据就会消失。 读写操作不会相互阻塞，不支持索引。简单查询下有非常非常高的性能表现(超过 10G/s)。

一般用到它的地方不多，除了用来测试，就是在需要非常高的性能，同时数据量又不大(上限大概 1 亿行)的场景。

三、MergeTree

ClickHouse 中最强大的表引擎当属 *MergeTree(合并树)引擎及该系列(MergeTree)
中的其他引擎，支持索引和分区。而且基于 MergeTree，还衍生除了很多小弟，也是非常有特色的引擎。

MergeTree 其实还有很多参数(绝大多数用默认值即可)，但是三个参数是更加重要的， 也涉及了关于 MergeTree 的很多概念。

相当于Inoodb在MySQL中的地位

主要特点:

• 存储的数据按主键排序。

  这使得您能够创建一个小型的稀疏索引来加快数据检索。

• 如果指定了 分区键 的话，可以使用分区。

  在相同数据集和相同结果集的情况下 ClickHouse 中某些带分区的操作会比普通操作更快。查询中指定了分区键时 ClickHouse 会自动截取分区数据。这也有效增加了查询性能。

• 支持数据副本。

  ReplicatedMergeTree 系列的表提供了数据副本功能。更多信息，请参阅 数据副本 一节。

• 支持数据采样。

该类型的引擎：

• MergeTree
• ReplacingMergeTree
• SummingMergeTree
• AggregatingMergeTree
• CollapsingMergeTree
• VersionedCollapsingMergeTree
• GraphiteMergeTree

3.1、简单的创建表和插入语句

建表语句

create table t_order_mt(
   id UInt32,
   sku_id String,
   total_amount Decimal(16,2),
   create_time Datetime
) engine =MergeTree
partition by toYYYYMMDD(create_time) 
primary key (id)
order by (id,sku_id);

插入数据

insert into t_order_mt values 
 (101,'sku_001',1000.00,'2020-06-01 12:00:00') ,
 (102,'sku_002',2000.00,'2020-06-01 11:00:00'),
 (102,'sku_004',2500.00,'2020-06-01 12:00:00'), 
 (102,'sku_002',2000.00,'2020-06-01 13:00:00'), 
 (102,'sku_002',12000.00,'2020-06-01 13:00:00'), 
 (102,'sku_002',600.00,'2020-06-02 12:00:00');

3.2、重要的参数

一、partition by 分区**(可选)**

**1）作用：**分区的目的主要是降低扫描的范围，优化查询速度。如果不指明partition by的话，只会使用一个分区

**2）分区目录：**MergeTree 是以列文件+索引文件+表定义文件组成的，但是如果设定了分区那么这些文件就会保存到不同的分区目录中。

**3）并行：**分区后，面对涉及跨分区的查询统计，ClickHouse 会以分区为单位并行处理。

4）数据写入与分区合并：任何一个批次的数据写入都会产生一个临时分区，不会纳入任何一个已有的分区。写入后的**某个时刻(大概 10-15 分钟后)，ClickHouse 会自动执行合并操作(等不及也可以手动。**通过 optimize 执行)，把临时分区的数据，合并到已有分区中。

optimize table xxxx final;

二、primary key 主键**(可选)**

ClickHouse 中的主键，和其他数据库不太一样，它只提供了数据的一级索引，但是却不是唯一约束。这就意味着是可以存在相同 primary key 的数据的。

主键的设定主要依据是查询语句中的 where 条件。

根据条件通过对主键进行某种形式的二分查找，能够定位到对应的index granularity,避 免了全表扫描。

index granularity: 直接翻译的话就是索引粒度，指在稀疏索引中两个相邻索引对应数 据的间隔。ClickHouse 中的 MergeTree 默认是 8192。官方不建议修改这个值，除非该列存在 大量重复值，比如在一个分区中几万行才有一个不同数据。

**稀疏索引:**稀疏索引的好处就是可以用很少的索引数据，定位更多的数据，代价就是只能定位到索 引粒度的第一行，然后再进行进行一点扫描。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-jsRQ1PqS-1639116496903)(https://www.cuizb.top/myblog/static/image/56iA55aP57Si5byVLTE2MzkxMTU0OTMwNTg=.png)]

三、order by(必选)

order by 设定了分区内的数据按照哪些字段顺序进行有序保存。

**order by 是 MergeTree 中唯一一个必填项，**甚至比 primary key 还重要，因为当用户不设置主键的情况，很多处理会依照 order by 的字段进行处理

要求:主键必须是 order by 字段的前缀字段。

比如 order by 字段是 (id,sku_id) 那么主键必须是 id 或者(id,sku_id)

四、二级索引

目前在 ClickHouse 的官网上二级索引的功能在 v20.1.2.4 之前是被标注为实验性的，在这个版本之后默认是开启的。

1)老版本使用二级索引前需要增加设置

是否允许使用实验性的二级索引(v20.1.2.4 开始，这个参数已被删除，默认开启)
set allow_experimental_data_skipping_indices=1;

2)创建测试表

create table t_order_mt2(
		id UInt32,
		sku_id String,
		total_amount Decimal(16,2),
		create_time Datetime,
		INDEX a total_amount TYPE minmax GRANULARITY 5
 ) engine =MergeTree
	partition by toYYYYMMDD(create_time)
	primary key (id)
	order by (id, sku_id)
	settings index_granulrity = 8192;

其中 GRANULARITY N 是设定二级索引对于一级索引粒度的粒度。

3)插入数据

insert into t_order_mt values 
 (101,'sku_001',1000.00,'2020-06-01 12:00:00') ,
 (102,'sku_002',2000.00,'2020-06-01 11:00:00'),
 (102,'sku_004',2500.00,'2020-06-01 12:00:00'), 
 (102,'sku_002',2000.00,'2020-06-01 13:00:00'), 
 (102,'sku_002',12000.00,'2020-06-01 13:00:00'), 
 (102,'sku_002',600.00,'2020-06-02 12:00:00');

五、数据TTL

TTL 即 Time To Live，MergeTree 提供了可以管理数据表或者列的生命周期的功能。

total_amount Decimal(16,2) TTL create_time+interval 10 SECOND, create_time Datetime

1)列级别 TTL

create table t_order_mt3(
		id UInt32,
		sku_id String,
		total_amount Decimal(16,2) TTL create_time+interval 10 SECOND, create_time Datetime
 ) engine =MergeTree
	 partition by toYYYYMMDD(create_time)
	 primary key (id)
	 order by (id, sku_id);

    到期后，指定的字段数据归0。

2)表级 TTL

下面的这条语句是数据会在 create_time 之后 10 秒丢失

alter table t_order_mt3 MODIFY TTL create_time + INTERVAL 10 SECOND;

涉及判断的字段必须是 Date 或者 Datetime 类型，推荐使用分区的日期字段。

能够使用的时间周期:

• • SECOND
• • MINUTE
• • HOUR
• • DAY
• • WEEK
• • MONTH
• • QUARTER
• • YEAR

四、ReplacingMergeTree

ReplacingMergeTree 是 MergeTree 的一个变种，它存储特性完全继承 MergeTree，只是多了一个去重的功能。 尽管 MergeTree 可以设置主键，但是 primary key 其实没有唯一约束的功能。如果你想处理掉重复的数据，可以借助这个 ReplacingMergeTree。

1)去重时机

数据的去重只会在合并的过程中出现。合并会在未知的时间在后台进行，所以你无法预 先作出计划。有一些数据可能仍未被处理。

2)去重范围

如果表经过了分区，去重只会在分区内部进行去重，不能执行跨分区的去重。

所以 ReplacingMergeTree 能力有限， ReplacingMergeTree 适用于在后台清除重复的数据以节省空间，但是它不保证没有重复的数据出现。

创建表

create table t_order_rmt(
   id UInt32,sku_id String,
total_amount Decimal(16,2) , create_time Datetime
) engine =ReplacingMergeTree(create_time)
  partition by toYYYYMMDD(create_time)
  primary key (id)
  order by (id, sku_id);

ReplacingMergeTree() 填入的参数为版本字段，重复数据保留版本字段值最大的。
如果不填版本字段，默认按照插入顺序保留最后一条。

向表中插入数据

insert into t_order_rmt values 
(101,'sku_001',1000.00,'2020-06-01 12:00:00') , 
(102,'sku_002',2000.00,'2020-06-01 11:00:00'), 
(102,'sku_004',2500.00,'2020-06-01 12:00:00'), 
(102,'sku_002',2000.00,'2020-06-01 13:00:00'), 
(102,'sku_002',12000.00,'2020-06-01 13:00:00'), 
(102,'sku_002',600.00,'2020-06-02 12:00:00');

执行第一次查询

select * from t_order_rmt;

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-YK1BSbXo-1639116496908)(https://www.cuizb.top/myblog/static/image/5pyq5ZG95ZCNLTE2MzkxMTU2MjEzMTc=.png)]

手动合并

OPTIMIZE TABLE t_order_rmt FINAL;

再执行一次查询

select * from t_order_rmt;

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-KFSzyHRa-1639116496909)(https://www.cuizb.top/myblog/static/image/5pyq5ZG95ZCNMS0xNjM5MTE1NjcwODMw.png)]

通过测试得到结论

➢ 实际上是使用 order by 字段作为唯一键
➢ 去重不能跨分区
➢ 只有同一批插入(新版本)或合并分区时才会进行去重
➢ 认定重复的数据保留，版本字段值最大的
➢ 如果版本字段相同则按插入顺序保留最后一笔

五、SummingMergeTree

对于不查询明细，只关心以维度进行汇总聚合结果的场景。

如果只使用普通的 MergeTree 的话，无论是存储空间的开销，还是查询时临时聚合的开销都比较大。ClickHouse 为了这种场景，提供了一种能够“预聚合”的引擎 SummingMergeTree

步骤如上，修改创建表时表引擎为SummingMergeTree

总结：

• ➢ 以SummingMergeTree()中指定的列作为汇总数据列
• ➢ 可以填写多列必须数字列，如果不填，以所有非维度列且为数字列的字段为汇总数据列
• ➢ 以 order by 的列为准，作为维度列
• ➢ 其他的列按插入顺序保留第一行
• ➢ 不在一个分区的数据不会被聚合
• ➢ 只有在同一批次插入(新版本)或分片合并时才会进行聚合

举例：

能不能直接执行以下 SQL 得到汇总值

select total_amount from XXX where province_name=’’ and create_date=’xxx’

不行，可能会包含一些还没来得及聚合的临时明细

如果要是获取汇总值，还是需要使用 sum 进行聚合，这样效率会有一定的提高，但本身 ClickHouse 是列式存储的，效率提升有限，不会特别明显。

select sum(total_amount) from province_name=’’ and create_date=‘xxx’

六、Integrations（集成引擎）

ClickHouse 提供了多种方式来与外部系统集成，包括表引擎。像所有其他的表引擎一样，使用CREATE TABLE或ALTER TABLE查询语句来完成配置。然后从用户的角度来看，配置的集成看起来像查询一个正常的表，但对它的查询是代理给外部系统的。这种透明的查询是这种方法相对于其他集成方法的主要优势之一，比如外部字典或表函数，它们需要在每次使用时使用自定义查询方法。

以下是支持的集成方式:

- ODBC

- JDBC

- MySQL

MySQL 引擎可以对存储在远程 MySQL 服务器上的数据执行 `SELECT` 查询。

调用格式：

```sql
MySQL('host:port', 'database', 'table', 'user', 'password'[, replace_query, 'on_duplicate_clause']);
```

**调用参数**

- `host:port` — MySQL 服务器地址。
- `database` — 数据库的名称。
- `table` — 表名称。
- `user` — 数据库用户。
- `password` — 用户密码。
- `replace_query` — 将 `INSERT INTO` 查询是否替换为 `REPLACE INTO` 的标志。如果 `replace_query=1`，则替换查询
- `'on_duplicate_clause'` — 将 `ON DUPLICATE KEY UPDATE 'on_duplicate_clause'` 表达式添加到 `INSERT` 查询语句中。例如：`impression = VALUES(impression) + impression`。如果需要指定 `'on_duplicate_clause'`，则需要设置 `replace_query=0`。如果同时设置 `replace_query = 1` 和 `'on_duplicate_clause'`，则会抛出异常。

此时，简单的 `WHERE` 子句（例如 `=, !=, >, >=, <, <=`）是在 MySQL 服务器上执行。

其余条件以及 `LIMIT` 采样约束语句仅在对MySQL的查询完成后才在ClickHouse中执行。

`MySQL` 引擎不支持 [可为空](https://clickhouse.com/docs/zh/engines/table-engines/integrations/mysql/) 数据类型，因此，当从MySQL表中读取数据时，`NULL` 将转换为指定列类型的默认值（通常为0或空字符串）。

- MongoDB

- HDFS

- S3

- Kafka

此引擎与 [Apache Kafka](https://kafka.apache.org/) 结合使用。

Kafka 特性：

- 发布或者订阅数据流。
- 容错存储机制。
- 处理流数据。

老版格式：

```sql
`Kafka(kafka_broker_list, kafka_topic_list, kafka_group_name, kafka_format
      [, kafka_row_delimiter, kafka_schema, kafka_num_consumers])`
```

新版格式：

```sql
`Kafka SETTINGS
  kafka_broker_list = 'localhost:9092',
  kafka_topic_list = 'topic1,topic2',
  kafka_group_name = 'group1',
  kafka_format = 'JSONEachRow',
  kafka_row_delimiter = '\n',
  kafka_schema = '',
  kafka_num_consumers = 2`
```

必要参数：

- `kafka_broker_list` – 以逗号分隔的 brokers 列表 (`localhost:9092`)。
- `kafka_topic_list` – topic 列表 (`my_topic`)。
- `kafka_group_name` – Kafka 消费组名称 (`group1`)。如果不希望消息在集群中重复，请在每个分片中使用相同的组名。
- `kafka_format` – 消息体格式。使用与 SQL 部分的 `FORMAT` 函数相同表示方法，例如 `JSONEachRow`。了解详细信息，请参考 `Formats` 部分。

可选参数：

- `kafka_row_delimiter` - 每个消息体（记录）之间的分隔符。
- `kafka_schema` – 如果解析格式需要一个 schema 时，此参数必填。例如，[普罗托船长](https://capnproto.org/) 需要 schema 文件路径以及根对象 `schema.capnp:Message` 的名字。
- `kafka_num_consumers` – 单个表的消费者数量。默认值是：`1`，如果一个消费者的吞吐量不足，则指定更多的消费者。消费者的总数不应该超过 topic 中分区的数量，因为每个分区只能分配一个消费者。

**示例**：

```sql
  `CREATE TABLE queue (
    timestamp UInt64,
    level String,
    message String
  ) ENGINE = Kafka('localhost:9092', 'topic', 'group1', 'JSONEachRow');

  SELECT * FROM queue LIMIT 5;

  CREATE TABLE queue2 (
    timestamp UInt64,
    level String,
    message String
  ) ENGINE = Kafka SETTINGS kafka_broker_list = 'localhost:9092',
                            kafka_topic_list = 'topic',
                            kafka_group_name = 'group1',
                            kafka_format = 'JSONEachRow',
                            kafka_num_consumers = 4;

  CREATE TABLE queue2 (
    timestamp UInt64,
    level String,
    message String
  ) ENGINE = Kafka('localhost:9092', 'topic', 'group1')
              SETTINGS kafka_format = 'JSONEachRow',
                       kafka_num_consumers = 4;`
```

消费的消息会被自动追踪，因此每个消息在不同的消费组里只会记录一次。如果希望获得两次数据，则使用另一个组名创建副本。

**消费组可以灵活配置并且在集群之间同步。例如，如果群集中有10个主题和5个表副本，则每个副本将获得2个主题。 如果副本数量发生变化，主题将自动在副本中重新分配。了解更多信息请访问 [http://kafka.apache.org/intro](https://kafka.apache.org/intro)。**

`SELECT` 查询对于读取消息并不是很有用（调试除外），因为每条消息只能被读取一次。使用物化视图创建实时线程更实用。您可以这样做：

1. 使用引擎创建一个 Kafka 消费者并作为一条数据流。
2. 创建一个结构表。
3. 创建物化视图，改视图会在后台转换引擎中的数据并将其放入之前创建的表中。

当 `MATERIALIZED VIEW` 添加至引擎，它将会在后台收集数据。可以持续不断地从 Kafka 收集数据并通过 `SELECT` 将数据转换为所需要的格式。

示例：

```sql
  `CREATE TABLE queue (
    timestamp UInt64,
    level String,
    message String
  ) ENGINE = Kafka('localhost:9092', 'topic', 'group1', 'JSONEachRow');

  CREATE TABLE daily (
    day Date,
    level String,
    total UInt64
  ) ENGINE = SummingMergeTree(day, (day, level), 8192);

  CREATE MATERIALIZED VIEW consumer TO daily
    AS SELECT toDate(toDateTime(timestamp)) AS day, level, count() as total
    FROM queue GROUP BY day, level;

  SELECT level, sum(total) FROM daily GROUP BY level;`
```

为了提高性能，接受的消息被分组为 [max_insert_block_size](https://clickhouse.com/docs/zh/operations/settings/settings/#settings-max_insert_block_size) 大小的块。如果未在 [stream_flush_interval_ms](https://clickhouse.com/docs/zh/operations/settings/settings/#stream-flush-interval-ms) 毫秒内形成块，则不关心块的完整性，都会将数据刷新到表中。

停止接收主题数据或更改转换逻辑，请 detach 物化视图：

  `DETACH TABLE consumer;
  ATTACH TABLE consumer;`

如果使用 `ALTER` 更改目标表，为了避免目标表与视图中的数据之间存在差异，推荐停止物化视图。

## **配置[](https://clickhouse.com/docs/zh/engines/table-engines/integrations/kafka/#pei-zhi)**

与 `GraphiteMergeTree` 类似，Kafka 引擎支持使用ClickHouse配置文件进行扩展配置。可以使用两个配置键：全局 (`kafka`) 和 主题级别 (`kafka_*`)。首先应用全局配置，然后应用主题级配置（如果存在）。

```sql
  `
  
    cgrp
    smallest
  

  
  
    250
    100000
  `
```

- EmbeddedRocksDB

- RabbitMQ

该引擎允许 ClickHouse 与 [RabbitMQ](https://www.rabbitmq.com/) 进行集成.

`RabbitMQ` 可以让你:

- 发布或订阅数据流。
- 在数据流可用时进行处理。

 **创建一张表[](https://clickhouse.com/docs/zh/engines/table-engines/integrations/rabbitmq/#table_engine-rabbitmq-creating-a-table)**

```sql
`CREATE TABLE [IF NOT EXISTS] [db.]table_name [ON CLUSTER cluster]
(
    name1 [type1] [DEFAULT|MATERIALIZED|ALIAS expr1],
    name2 [type2] [DEFAULT|MATERIALIZED|ALIAS expr2],
    ...
) ENGINE = RabbitMQ SETTINGS
    rabbitmq_host_port = 'host:port',
    rabbitmq_exchange_name = 'exchange_name',
    rabbitmq_format = 'data_format'[,]
    [rabbitmq_exchange_type = 'exchange_type',]
    [rabbitmq_routing_key_list = 'key1,key2,...',]
    [rabbitmq_row_delimiter = 'delimiter_symbol',]
    [rabbitmq_schema = '',]
    [rabbitmq_num_consumers = N,]
    [rabbitmq_num_queues = N,]
    [rabbitmq_queue_base = 'queue',]
    [rabbitmq_deadletter_exchange = 'dl-exchange',]
    [rabbitmq_persistent = 0,]
    [rabbitmq_skip_broken_messages = N,]
    [rabbitmq_max_block_size = N,]
    [rabbitmq_flush_interval_ms = N]`
```

必要参数:

- `rabbitmq_host_port` – 主机名:端口号 (比如, `localhost:5672`).
- `rabbitmq_exchange_name` – RabbitMQ exchange 名称.
- `rabbitmq_format` – 消息格式. 使用与SQL`FORMAT`函数相同的标记，如`JSONEachRow`。 更多信息，请参阅 [Formats](https://clickhouse.com/docs/zh/interfaces/formats/) 部分.

可选参数:

- `rabbitmq_exchange_type` – RabbitMQ exchange 的类型: `direct`, `fanout`, `topic`, `headers`, `consistent_hash`. 默认是: `fanout`.
- `rabbitmq_routing_key_list` – 一个以逗号分隔的路由键列表.
- `rabbitmq_row_delimiter` – 用于消息结束的分隔符.
- `rabbitmq_schema` – 如果格式需要模式定义，必须使用该参数。比如, [Cap’n Proto](https://capnproto.org/) 需要模式文件的路径以及根 `schema.capnp:Message` 对象的名称.
- `rabbitmq_num_consumers` – 每个表的消费者数量。默认：`1`。如果一个消费者的吞吐量不够，可以指定更多的消费者.
- `rabbitmq_num_queues` – 队列的总数。默认值: `1`. 增加这个数字可以显著提高性能.
- `rabbitmq_queue_base` - 指定一个队列名称的提示。这个设置的使用情况如下.
- `rabbitmq_deadletter_exchange` - 为[dead letter exchange](https://www.rabbitmq.com/dlx.html)指定名称。你可以用这个 exchange 的名称创建另一个表，并在消息被重新发布到 dead letter exchange 的情况下收集它们。默认情况下，没有指定 dead letter exchange。Specify name for a [dead letter exchange](https://www.rabbitmq.com/dlx.html).
- `rabbitmq_persistent` - 如果设置为 1 (true), 在插入查询中交付模式将被设置为 2 (将消息标记为 'persistent'). 默认是: `0`.
- `rabbitmq_skip_broken_messages` – RabbitMQ 消息解析器对每块模式不兼容消息的容忍度。默认值：`0`. 如果 `rabbitmq_skip_broken_messages = N`，那么引擎将跳过 *N* 个无法解析的 RabbitMQ 消息（一条消息等于一行数据）。
- `rabbitmq_max_block_size`
- `rabbitmq_flush_interval_ms`

同时，格式的设置也可以与 rabbitmq 相关的设置一起添加。

示例:

```sql
  `CREATE TABLE queue (
    key UInt64,
    value UInt64,
    date DateTime
  ) ENGINE = RabbitMQ SETTINGS rabbitmq_host_port = 'localhost:5672',
                            rabbitmq_exchange_name = 'exchange1',
                            rabbitmq_format = 'JSONEachRow',
                            rabbitmq_num_consumers = 5,
                            date_time_input_format = 'best_effort';`
```

RabbitMQ 服务器配置应使用 ClickHouse 配置文件添加。

必要配置:

```sql
 `
    root
    clickhouse
 `
```

可选配置:

```sql
 `
    clickhouse
 `
```

## **描述[](https://clickhouse.com/docs/zh/engines/table-engines/integrations/rabbitmq/#description)**

`SELECT`对于读取消息不是特别有用（除了调试），因为每个消息只能读取一次。使用[物化视图](https://clickhouse.com/docs/zh/sql-reference/statements/create/#create-view)创建实时线程更为实用。要做到这一点:

1. 使用引擎创建一个 RabbitMQ 消费者，并将其视为一个数据流。
2. 创建一个具有所需结构的表。
3. 创建一个物化视图，转换来自引擎的数据并将其放入先前创建的表中。

当`物化视图`加入引擎时，它开始在后台收集数据。这允许您持续接收来自 RabbitMQ 的消息，并使用 `SELECT` 将它们转换为所需格式。一个 RabbitMQ 表可以有多个你需要的物化视图。

数据可以根据`rabbitmq_exchange_type`和指定的`rabbitmq_routing_key_list`进行通道。每个表不能有多于一个 exchange。一个 exchange 可以在多个表之间共享 - 因为可以使用路由让数据同时进入多个表。

Exchange 类型的选项:

- `direct` - 路由是基于精确匹配的键。例如表的键列表: `key1,key2,key3,key4,key5`, 消息键可以是等同他们中的任意一个.
- `fanout` - 路由到所有的表 (exchange 名称相同的情况) 无论是什么键都是这样.
- `topic` - 路由是基于带有点分隔键的模式. 比如: `.logs`, `records.*.*.2020`, `.2018,*.2019,*.2020`.
- `headers` - 路由是基于`key=value`的匹配，设置为`x-match=all`或`x-match=any`. 例如表的键列表: `x-match=all,format=logs,type=report,year=2020`.
- `consistent_hash` - 数据在所有绑定的表之间均匀分布 (exchange 名称相同的情况). 请注意，这种 exchange 类型必须启用 RabbitMQ 插件: `rabbitmq-plugins enable rabbitmq_consistent_hash_exchange`.

设置`rabbitmq_queue_base`可用于以下情况:

- 来让不同的表共享队列, 这样就可以为同一个队列注册多个消费者，这使得性能更好。如果使用`rabbitmq_num_consumers`和/或`rabbitmq_num_queues`设置，在这些参数相同的情况下，实现队列的精确匹配。
- 以便在不是所有消息都被成功消费时，能够恢复从某些持久队列的阅读。要从一个特定的队列恢复消耗 - 在`rabbitmq_queue_base`设置中设置其名称，不要指定`rabbitmq_num_consumers`和`rabbitmq_num_queues`（默认为1）。要恢复所有队列的消费，这些队列是为一个特定的表所声明的 - 只要指定相同的设置。`rabbitmq_queue_base`, `rabbitmq_num_consumers`, `rabbitmq_num_queues`。默认情况下，队列名称对表来说是唯一的。
- 以重复使用队列，因为它们被声明为持久的，并且不会自动删除。可以通过任何 RabbitMQ CLI 工具删除）

为了提高性能，收到的消息被分组为大小为 [max_insert_block_size](https://clickhouse.com/docs/zh/operations/server-configuration-parameters/settings/#settings-max_insert_block_size) 的块。如果在[stream_flush_interval_ms](https://clickhouse.com/docs/zh/operations/server-configuration-parameters/settings/)毫秒内没有形成数据块，无论数据块是否完整，数据都会被刷到表中。

如果`rabbitmq_num_consumers`和/或`rabbitmq_num_queues`设置与`rabbitmq_exchange_type`一起被指定，那么:

- 必须启用`rabbitmq-consistent-hash-exchange` 插件.
- 必须指定已发布信息的 `message_id`属性（对于每个信息/批次都是唯一的）。

对于插入查询时有消息元数据，消息元数据被添加到每个发布的消息中:`messageID`和`republished`标志（如果值为true，则表示消息发布不止一次） - 可以通过消息头访问。

不要在插入和物化视图中使用同一个表。

示例:

```sql
  `CREATE TABLE queue (
    key UInt64,
    value UInt64
  ) ENGINE = RabbitMQ SETTINGS rabbitmq_host_port = 'localhost:5672',
                            rabbitmq_exchange_name = 'exchange1',
                            rabbitmq_exchange_type = 'headers',
                            rabbitmq_routing_key_list = 'format=logs,type=report,year=2020',
                            rabbitmq_format = 'JSONEachRow',
                            rabbitmq_num_consumers = 5;

  CREATE TABLE daily (key UInt64, value UInt64)
    ENGINE = MergeTree() ORDER BY key;

  CREATE MATERIALIZED VIEW consumer TO daily
    AS SELECT key, value FROM queue;

  SELECT key, value FROM daily ORDER BY key;`
```

## **虚拟列[](https://clickhouse.com/docs/zh/engines/table-engines/integrations/rabbitmq/#virtual-columns)**

- `_exchange_name` - RabbitMQ exchange 名称.
- `_channel_id` - 接收消息的消费者所声明的频道ID.
- `_delivery_tag` - 收到消息的DeliveryTag. 以每个频道为范围.
- `_redelivered` - 消息的`redelivered`标志.
- `_message_id` - 收到的消息的ID；如果在消息发布时被设置，则为非空.
- `_timestamp` - 收到的消息的时间戳；如果在消息发布时被设置，则为非空.

- PostgreSQL

更多的引擎请移驾ClickHouse官网：表引擎https://clickhouse.com/docs/zh/engines/table-engines/

本文作者：好名字
原文链接：https://www.cuizb.top/myblog/article/1639116339
版权声明： 本博客所有文章除特别声明外，均采用 CC BY 3.0 CN协议进行许可。转载请署名作者且注明文章出处。

更多文章和干货请关注公众号