「从ES到CK 04」Clickhouse表引擎选择和表结构设计

一、表引擎选择

在系列文章《Clickhouse的基础知识扫盲》也有提到过，合并树(MergeTree)系列的表引擎被誉为Clickhouse 中最强大的表引擎，其中MergeTree引擎作为其系列内其他表引擎的基础，具有如下特性：

√ 存储的数据按主键排序

√ 支持分区

√ 支持数据副本

√ 支持数据采样

在继承MergeTree引擎特性的基础上，衍生出如下各有特色的表引擎，满足不同场景的需求：

表引擎	说明
SummingMergeTree	该引擎继承自MergeTree。区别在于，当合并SummingMergeTree表的数据片段时，ClickHouse会把所有具有相同主键的行合并为一行，该行包含了被合并的行中具有数值数据类型的列的汇总值。如果主键的组合方式使得单个键值对应于大量的行，则可以显著的减少存储空间并加快数据查询的速度。
ReplacingMergeTree	会删除排序键值相同的重复项以节省空间，但是它不保证没有重复的数据出现
AggregatingMergeTree	一般用来做增量数据的聚合统计，包括物化视图的数据聚合。
CollapsingMergeTree	引擎继承于MergeTree，并在数据块合并算法中添加了折叠行的逻辑
VersionedCollapsingMergeTre服务器托管网e	擎继承自 MergeTree 并将折叠行的逻辑添加到合并数据部分的算法中
GraphiteMergeTree	该引擎用来对Graphite数据进行瘦身及汇总
Replicated*	数据副本，支持： ReplicatedMergeTree ReplicatedSummingMergeTree ReplicatedReplacingMergeTree ReplicatedAggregatingMergeTree ReplicatedCollapsingMergeTree ReplicatedVersionedCollapsingMergeTree ReplicatedGraphiteMergeTree

在结合我司日志平台的实际场景后，选用了ReplicatedMergeTree引擎存储完整的日志数据~

二、表结构设计

在系列文章《Clickhouse的基础知识扫盲》也有提到过表结构的相关概念，话不多说直接上DDL，以java日志的表结构为例：

CREATE TABLE elk.java_log_local
(
    `service_name` String CODEC(ZSTD(1)),
    `server_ip` String CODEC(ZSTD(1)),
    `sys_code` String CODEC(ZSTD(1)),
    `env_type` String CODEC(ZSTD(1)),
    `class_name` String CODEC(ZSTD(1)),
    `log_level` String CODEC(ZSTD(1)),
    `thread` String CODEC(ZSTD(1)),
    `_time_nanosecond_` DateTime64(3, 'Asia/Shanghai'),
    `msg` String CODEC(ZSTD(1)),
    `ex服务器托管网ception` String CODEC(ZSTD(1)),
    `traceId` String CODEC(ZSTD(1)),
    `spanId` String CODEC(ZSTD(1)),
    INDEX idx_msg msg TYPE tokenbf_v1(30720, 2, 0) GRANULARITY 1
)
ENGINE = ReplicatedMergeTree('/clickhouse/tables/{shard}/java_log', '{replica}')
PARTITION BY toYYYYMMDD(_time_nanosecond_)
ORDER BY (_time_nanosecond_, sys_code, env_type, service_name)
-- TTL toDateTime(_time_nanosecond_) + toIntervalDay(14)
SETTINGS storage_policy = '51cto', index_granularity = 8192;

表结构设计说明：

属性	语句	说明
索引	INDEX idx_msg msg TYPE tokenbf_v1(30720, 2, 0) GRANULARITY 1	msg字段为日志详情，涉及长文本模糊匹配的场景，故针对该字段建立跳数索引
主键	–	无
排序(必填)	ORDER BY (time_nanosecond, sys_code, env_type, service_name)	结合业务场景，根据字段使用频率、优先级，由高至低组合
压缩方式	CODEC(ZSTD(1))	此处选用字符串字段常用的ZSTD压缩算法，压缩级别为1
分区	PARTITION BY toYYYYMMDD(time_nanosecond)	此处选用日期作为分区依据，注意避免过于精细的分区方案，以免影响整体性能
数据生命周期	TTL toDateTime(time_nanosecond) + toIntervalDay(14)	考虑到生命周期可能会根据实际情况而变动，在生产环境中我选用move/delete partition的方式来控制数据生命周期。因为ttl值设定后修改，会引发全表扫描，故设计表结构时需考虑清楚是否引入ttl设置
存储策略	storage_policy = ’51cto’	此处采用多级存储，将数据按策略分别存在ssd、hdd和oss，具体可参考《Clickhouse多分片多副本集群部署》

三、参考资料

Clickhouse

https://clickhouse.com/docs/zh

下回预告

由于logstash消耗的资源较高，在日志平台转战clickhouse后，引入了高效数据处理工具vector，欢迎关注后续更新的系列文章~

服务器托管，北京服务器托管，服务器租用 http://www.fwqtg.net
机房租用，北京机房租用，IDC机房托管， http://www.fwqtg.net

相关推荐: 7个理由：从Java8升级到Java17【翻译】

从Java8升级到Java17的7个理由原文地址: 7 Reasons to Migrate from Java 8 to Java 17 释放吧，Java的全部力量。[手动狗头] 简介从Java8到Java18，Java已经经历了漫长的发展历程（Java…

导航

一、表引擎选择

二、表结构设计

三、参考资料

下回预告

服务器托管，北京服务器托管，服务器租用，机房机柜带宽租用