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

  导航

        在完成将公司日志数据从Elasticsearch(下称ES)转战到Clickhouse后，个人认为有必要将过程记录分享。限于篇幅及便于分类组织，我会以一个系列文章的形式记录：

• 01 《Elasticsearch vs Clickhouse》
• 02 《Clickhouse的基础知识扫盲》
• 03 《​Clickhouse多分片多副本集群部署​》
• 04 《​​Clickhouse表引擎选择和表结构设计​》
• 05 《​clickhouse高效数据处理工具vector​》
• 06 《​​​​​​​​​clickhouse的数据可视化工具clickvisual​》
• 07 《kibana自定义插件跳转clickvisual》
• 08 《妙用clickvisual api实现用户自动管理》（敬请期待）

一、表引擎选择

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

        √ 存储的数据按主键排序

        √ 支持分区

        √ 支持数据副本

        √ 支持数据采样

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

在结合我司日志平台的实际场景后，选用了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)),
    `exception` 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;

表结构设计说明：

三、参考资料

• Clickhouse

        ​​https://clickhouse.com/docs/zh​​

下回预告

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