Clickhouse 入门（一篇就够了）

1. 知识基础

1.1 什么是OLAP?

OLAP（联机分析处理） 是一种用于在大规模数据集上进行复杂分析的数据处理方法。与OLTP（联机事务处理）系统专注于支持日常业务交易和操作不同，OLAP系统旨在提供对多维数据的快速、灵活的查询和分析能力。

OLAP场景有以下关键的特征：

• 主要读请求： 数据库主要用于读取操作，而写入操作相对较少。
• 大批量更新： 更新操作通常以相当大的批次进行，而非单行更新，并且可能是禁止或较少进行的。
• 不可修改的数据： 一旦数据添加到数据库，就不能修改。
• 大量列的宽表： 数据表包含大量列，可能是宽表结构。
• 查询少，但复杂： 查询数量相对较少，但每个查询可能涉及提取大量行的一小部分列，且查询可能是复杂的。
• 允许一定的延迟： 对于简单查询，可以接受一定的延迟，约50毫秒。
• 小型数据： 列中的数据相对较小，包括数字和短字符串。
• 高吞吐量： 需要处理单个查询时的高吞吐量，每秒可达数十亿行。
• 非必须事务： 对事务的要求不高，即可容忍一些数据不一致性。
• 低数据一致性要求： 数据一致性的要求相对较低。
• 每个查询有一个大表： 通常每个查询涉及一个大表，而其他表规模较小。
• 结果适合RAM： 查询结果通常经过过滤或聚合，适合于单个服务器的RAM中。

1.2 什么是列式存储?

列式存储 是一种数据库和数据存储系统的组织方式，其中数据按列而不是按行进行存储。相比之下，传统的行式存储数据库系统以行为单位存储数据。下面是列式存储的主要特点：

• 数据组织方式（列归类，处理特定列）： 列式存储将同一列的数据存储在一起，而不是将整行数据存储在一起。这意味着数据库引擎可以更加高效地读取和处理特定列的数据。
• 数据压缩（相似性）： 列式存储通常更容易实现数据压缩。因为同一列的数据通常具有相似性，压缩算法可以更好地利用这些相似性，从而减小存储空间的需求。
• 查询性能提升（加载需要分析的列，而不是加载整行）： 列式存储在处理分析型查询（例如聚合、过滤等）时通常具有更好的性能。这是因为只需读取和处理查询所需的列，而不必加载整行的数据。
• 适用于分析工作负载： 列式存储特别适用于分析型工作负载，其中通常需要处理大量的聚合操作和复杂查询。
• 高效的列存储索引（使用特定的列存储索引）： 为了支持高效的列式存储，数据库系统通常使用专门的列存储索引，这些索引能够更快速地定位和检索特定列的数据。
• 适用于大规模数据仓库（数据压缩、缓存）： 列式存储对于大规模数据仓库非常有用，因为在这种场景下，数据的分析和报告是主要的工作负载。

2. Clickhouse为何物？

2.1 概念

ClickHouse 是一个用于 联机分析(OLAP) 的 列式 数据库管理系统(DBMS)。

要用于大规模数据分析的领域，特别是在需要处理海量数据并执行复杂查询的场景中表现出色。以下是一些主要的应用领域：

• 在线广告分析： ClickHouse可以用于分析在线广告的效果，处理大量的点击数据和用户行为，以优化广告投放策略。
• 日志分析： 处理大量的日志数据是ClickHouse的一项强项。它可以用于分析服务器日志、应用程序日志等，帮助识别潜在问题、监控系统性能等。
• 电商数据分析： 针对电子商务平台的大量交易和用户行为数据进行分析，包括销售趋势、用户行为模式等。
• 大数据仪表盘： ClickHouse可以支持创建实时或准实时的大数据仪表盘，用于监控业务指标、数据可视化等。
• 科学研究： 在科学研究领域，特别是需要分析大规模实验数据的情境下，ClickHouse可以用于加速数据处理和分析过程。
• 物联网（IoT）数据分析： 处理大量的物联网设备生成的数据，用于监测、预测和优化物联网系统。

2.2 优缺点

以下是ClickHouse的一些优点：

优点	描述
高性能	ClickHouse专注于高性能的OLAP查询，特别适用于大规模数据集的复杂分析。其列式存储引擎和优化的查询执行计划使其在数据扫描和聚合方面表现卓越
列式存储引擎	ClickHouse采用列式存储引擎，将表按列而不是按行存储。这种存储结构使得在分析查询中只读取所需的列，从而提高了查询性能
分布式架构	ClickHouse是一个分布式系统，可以水平扩展以处理更大的数据集。它支持分布式查询，可以在多个节点上并行执行查询，实现高可用性和负载均衡
适用于时序数据	ClickHouse对时序数据有专门的支持和优化，包括时间窗口、采样、填充等功能。这使其成为处理时间序列数据的理想选择
灵活的数据分布和复制策略	ClickHouse允许用户定义数据分布和复制策略，以适应不同的业务需求。这种灵活性使得在大规模分布式环境中进行高可用性配置和负载均衡变得更为容易
支持多种数据格式	ClickHouse支持多种数据格式的导入和导出，包括CSV、JSON、Parquet等。这使其更适应不同的数据来源和数据处理场景
低延迟查询	ClickHouse在处理大规模数据时能够实现低延迟的查询，这使得它适用于需要快速响应分析查询的应用场景
开源和免费	ClickHouse是开源的，可免费使用，这降低了部署和使用成本

尽管ClickHouse在大规模数据分析和OLAP场景中表现出色，但仍然有一些潜在的限制和不足，这取决于具体的使用场景和需求。以下是一些ClickHouse可能存在的不足之处：

缺点	描述
事务支持有限	ClickHouse的事务支持相对有限，主要关注于读取和分析性能。对于要求强事务一致性的OLTP场景，可能不是首选
写入操作相对较慢	尽管ClickHouse在大规模数据的读取和查询方面表现优越，但对于频繁的单行写入（INSERT、UPDATE、DELETE）操作，性能可能相对较慢
不适合频繁更新的场景	ClickHouse的设计更适用于大规模的批量插入和查询，而不是频繁的更新。频繁的更新可能导致性能下降，因为ClickHouse的列式存储引擎更适用于不可变的数据
复杂连接操作性能相对较慢	在复杂的多表连接操作中，ClickHouse可能表现相对较慢。它的优势主要在于单表和简单连接查询
不支持全文搜索	ClickHouse不支持全文搜索，因此在需要进行全文搜索的场景下，可能需要其他专门的全文搜索引擎的配合
存储过程和触发器不支持	ClickHouse不支持存储过程和触发器，这意味着无法在数据库中实现存储过程式的业务逻辑
部分SQL标准的不支持	ClickHouse实现了大部分SQL标准，但仍然可能存在一些特定SQL功能的不支持或支持有限
维护和管理的复杂性	ClickHouse的配置和管理可能相对复杂，特别是在分布式集群环境中。需要仔细考虑配置、性能调优、数据备份等方面的问题

3. 表引擎

从前面的描述，可以知道ClickHouse采用列式存储引擎，将表按列而不是按行存储。这里还有一个表引擎的概念。

ClickHouse的表引擎 定义了数据表的物理存储结构和访问方法，ClickHouse支持多种表引擎，其中一些常见的引擎包括MergeTree系列、Log系列、外部引擎、其它引擎等。

引擎系列	引擎	用途	特点
MergeTree 系列	MergeTree	大规模数据分析，时序数据	列式存储，适用于分析查询，支持分区和索引
	ReplicatedMergeTree	高可用性，数据冗余	支持数据复制，提高高可用性，支持分区和索引
	Distributed	跨多个节点的分布式查询	支持在多个节点之间执行分布式查询
Log 系列	Log	记录变更日志	用于记录变更日志，通常与其他引擎结合使用
外部引擎	Kafka	集成 ClickHouse 和 Apache Kafka	通过 Kafka 主题读取和写入数据
	MySQL	在 ClickHouse 中访问 MySQL 数据库的数据	用于在 ClickHouse 中访问 MySQL 数据库的数据
	ODBC	通过 ODBC 接口连接到其他数据源	通过 ODBC 接口连接到其他数据源
其它引擎	TinyLog	记录变更日志，轻量级实现	轻量级的 Log 引擎实现，适用于数据量较小的情况
	TinyMergeTree	大规模数据分析，轻量级实现	轻量级的 MergeTree 引擎实现，适用于数据量较小的情况

4. Clickhouse的运行机制

4.1 简单描述

当我们使用 ClickHouse 时，可以将其运行机制简化为以下通俗易懂的描述：

• 表的存储： 想象一张巨大的表，表格中的数据被按列存储，而不是按行。这就好比把所有人的名字都列在一列，年龄列在另一列，这样的方式更适合大规模的数据。
• 分区： 这张表按照时间或其他规则被分成小块，每块称为一个分区。这就像把时间按照一天一天的划分，每天的数据放在不同的“盒子”里。
• 插入数据： 当有新的数据要插入时，数据并不会直接插入到表里。相反，它首先被放入一个“暂存区”，然后在合适的时机被整理到表的对应分区中。
• 查询处理： 当我们执行查询时，ClickHouse 会聪明地只读取需要的列，而不是整行。这就好比我们只关心某些列，而不必查看整个表格。
• 高效合并： 由于数据按照分区存储，ClickHouse 能够定期将不同分区内的数据进行高效的合并操作，以减小存储空间，提高查询速度。

这是 ClickHouse 的基本运行思路。

4.2 详细描述

以下是 ClickHouse 更为运行机制的详细描述：

1. 表的创建与结构定义：用户通过 SQL 语句在 ClickHouse 中创建表，并定义表的结构，包括列的数据类型、分区方式、索引等。每个表都与一个特定的表引擎关联，决定了数据的存储方式和处理特性。
2. 列式存储：ClickHouse 使用列式存储引擎，将相同列的数据存储在一起。这样的存储方式带来了高压缩比和更高的查询性能，尤其适用于大规模数据分析。
3. 数据分区：表可以根据指定的字段进行分区，常见的是按照时间进行分区。分区有助于提高查询性能，允许系统更快速地定位和处理特定时间范围内的数据。
4. 数据插入与合并：当用户插入新的数据时，数据首先会进入 MergeTree 引擎的“暂存区”（MergeTree 小分区），然后根据配置的合并策略，定期进行数据合并操作。合并操作有助于优化数据存储和提高查询性能。
5. 索引的使用：ClickHouse 支持主键索引和辅助索引，提高了查询速度。主键索引用于快速定位唯一行，而辅助索引用于其他查询条件。
6. 异步写入：ClickHouse 支持异步写入，插入操作是非常快速的。写入的数据首先进入 MergeTree 引擎的不同分区，然后可以通过周期性的合并操作进行整理。
7. 分布式计算：如果运行在分布式集群中，ClickHouse 可以在多个节点上并行执行查询。Distributed 引擎用于在多个 ClickHouse 节点之间执行分布式查询，将查询分发到集群中的多个节点，并将结果合并返回。
8. 数据副本和高可用性：ReplicatedMergeTree 引擎支持数据在多个副本之间的复制，提高数据的冗余和高可用性。在集群中的节点之间可以实现故障转移，保障数据的可靠性。
9. 查询处理和优化：当执行查询时，ClickHouse 使用内置的优化器和执行引擎，根据查询的结构和表的分布情况进行优化，以提高查询性能。
10. 异步更新和删除：ClickHouse 支持异步更新和删除操作。通过 ReplicatedMergeTree 引擎的版本控制机制，可以实现在表中执行条件更新和删除。
11. 数据压缩：列式存储以及支持多种压缩算法，帮助减小存储占用，提高 I/O 效率。

5. Clickhouse的安装配置

5.1 安装

ClickHouse支持集群安装，允许在多台服务器上部署和管理ClickHouse数据库。这样的集群环境提供了更高的可用性、负载均衡和横向扩展性。以下是ClickHouse集群的一般安装步骤（大致思路）：

Step 1. 安装ClickHouse： 在每台服务器上按照先前提到的方式安装ClickHouse。确保每个节点都具有相同的ClickHouse版本。

Step 2. 配置ZooKeeper（可选）：

• ClickHouse集群可以使用ZooKeeper进行协调和配置。如果你选择使用ZooKeeper，确保在每个节点上配置ZooKeeper连接信息。
• 在 config.xml 文件中配置ZooKeeper信息。

<zookeeper>
    <node index="1">
        <host>zookeeper1-host</host>
        <port>2181</port>
    </node>
    <!-- 其它 ZooKeeper 节点 -->
</zookeeper>

Step 3. 配置集群节点：在 config.xml 文件中配置ClickHouse节点的信息。

<remote_servers>
    <cluster_zookeeper>
        <shard>
            <weight>1</weight>
            <internal_replication>true</internal_replication>
            <replica>
                <host>node1-host</host>
                <port>9000</port>
            </replica>
            <!-- 其它副本实例 -->
        </shard>
        <!-- Additional shards -->
    </cluster_zookeeper>
</remote_servers>

Step 4. 启动Clickhouse服务：在每个节点上启动ClickHouse服务

sudo service clickhouse-server start

Step 5. 验证集群配置：使用ClickHouse客户端连接到任何一个节点，执行以下查询验证集群配置

SELECT * FROM system.clusters;

其它：ClickHouse还提供了Web界面（ClickHouse Web）用于监控和管理集群。同时也可以使用第三方监控工具来监控集群状态和性能。

---

Clickhouse是通过 数据复制和冗余、自动数据分片和负载均衡、内置的故障转移、监控和警报来实现高可用的，有点类似与Redis。

5.2 配置

ClickHouse的主要配置文件是 config.xml，通常位于/etc/clickhouse-server/目录下，以下是它的核心配置：

• 集群配置：如果使用ClickHouse集群，确保正确配置 config.xml 中的集群信息，包括ZooKeeper的连接信息（如果使用ZooKeeper）、分片和副本配置等。
• 数据分布配置：ClickHouse支持多种数据分布和复制策略。根据数据的特性和查询需求，选择适当的分布策略，并在创建表时配置数据的复制参数。
• ZooKeeper配置（可选）：如果使用ZooKeeper进行协调和配置，确保在 config.xml 中正确配置ZooKeeper的连接信息，以及在ZooKeeper中创建适当的路径。
• 系统表和引擎配置：ClickHouse使用系统表（例如 system.tables 和 system.replicas）来存储关于集群和表的元数据。确保这些系统表的配置和引擎设置得当。
• 缓存设置：ClickHouse具有多层次的缓存，包括操作系统缓存和ClickHouse自身的缓存。根据内存和性能需求，调整 config.xml 中的缓存设置。
• 监控和警报：ClickHouse提供了用于监控集群状态和性能的工具。配置监控工具，并设置警报，以在发生故障或性能下降时及时采取措施。
• 数据目录和磁盘设置：确保配置正确的数据目录和磁盘设置，以及适当的备份策略。ClickHouse需要足够的磁盘空间来存储数据和日志。
• 网络配置：配置网络设置，确保节点之间的通信是安全和可靠的。检查防火墙规则以确保端口是开放的。
• 日志设置：调整日志级别和日志路径，以方便故障排查和性能分析。

完整示例配置如下：

<!-- /etc/clickhouse-server/config.xml -->

<yandex>
    <!-- 基本设置 -->
    <listen_host>::</listen_host>
    <listen_port>8123</listen_port>
    <max_server_memory_usage>75</max_server_memory_usage> <!-- 设置最大内存使用率 -->

    <!-- 集群配置 -->
    <zookeeper>
        <node index="1">
            <host>zookeeper1-host</host>
            <port>2181</port>
        </node>
        <!-- Additional ZooKeeper nodes -->
    </zookeeper>

    <remote_servers>
        <cluster_zookeeper>
            <shard>
                <weight>1</weight>
                <internal_replication>true</internal_replication>
                <replica>
                    <host>node1-host</host>
                    <port>9000</port>
                </replica>
                <!-- Additional replicas -->
            </shard>
            <!-- Additional shards -->
        </cluster_zookeeper>
    </remote_servers>

    <!-- 数据分布配置 -->
    <data_distribution>
        <!-- 根据数据的特性和查询需求，选择适当的分布策略 -->
        <sharding_key>your_sharding_key</sharding_key>
        <!-- 在创建表时配置数据的复制参数 -->
        <replication>
            <shard>
                <internal_replication>true</internal_replication>
                <replica>
                    <host>node1-host</host>
                    <port>9000</port>
                </replica>
                <!-- Additional replicas -->
            </shard>
            <!-- Additional shards -->
        </replication>
    </data_distribution>

    <!-- 系统表和引擎配置 -->
    <system>
        <path>/var/lib/clickhouse/</path> <!-- 设置系统表和引擎的路径 -->
    </system>

    <!-- 缓存设置 -->
    <max_memory_usage_for_all_queries>10737418240</max_memory_usage_for_all_queries>
    <max_memory_usage_for_all_granules>5368709120</max_memory_usage_for_all_granules>

    <!-- 监控和警报 -->
    <query_profiler_real_time>1</query_profiler_real_time>
    <metric_log>1</metric_log>
    <metric_log_path>/var/log/clickhouse-server/metrics/</metric_log_path>
    <max_part_to_read>100</max_part_to_read>

    <!-- 数据目录和磁盘设置 -->
    <path>/var/lib/clickhouse/data/</path> <!-- 设置数据目录 -->
    <disk>
        <enabled>true</enabled>
        <keep_free_space>53687091200</keep_free_space> <!-- 设置磁盘剩余空间 -->
    </disk>

    <!-- 网络配置 -->
    <interserver_http_host>node1-host</interserver_http_host>
    <interserver_http_port>9000</interserver_http_port>

    <!-- 日志设置 -->
    <log>
        <level>information</level> <!-- 设置日志级别 -->
        <path>/var/log/clickhouse-server/</path> <!-- 设置日志路径 -->
    </log>
</yandex>

6. Clickhouse的语法

6.1 基本语法

数据定义语法：

-- 创建表
CREATE TABLE [IF NOT EXISTS] [db.]table_name [ON CLUSTER cluster]
(
    column_name1 [type1] [DEFAULT|MATERIALIZED|ALIAS expr1] [TTL expr_ttl1],
    column_name2 [type2] [DEFAULT|MATERIALIZED|ALIAS expr2] [TTL expr_ttl2],
    ...
) ENGINE = engine

-- 修改表
ALTER TABLE [db.]table
[ADD COLUMN [IF NOT EXISTS] col_name [type] [DEFAULT|MATERIALIZED|ALIAS expr] [AFTER col_after]]
[DROP COLUMN [IF EXISTS] col_name [FROM PARTITION partition]]
[MODIFY COLUMN [IF EXISTS] col_name [type] [DEFAULT|MATERIALIZED|ALIAS expr] [AFTER col_after]]
[MODIFY PRIMARY KEY|AFTER [col_name] ]
[MODIFY ORDER BY [col_name] ]
[MODIFY TTL [col_name] ]
[COMMENT col_name | TABLE 'comment']
[RENAME COLUMN [IF EXISTS] col_name TO new_col_name]
[DROP PARTITION partition]

数据操作：

-- 插入
INSERT INTO [db.]table [(column, ...)] VALUES (expr, ...)

--更新
UPDATE [db.]table
SET col1 = expr1, col2 = expr2, ...
WHERE condition

--删除
DELETE FROM [db.]table WHERE condition

查询语法：

-- 基本查询
SELECT [DISTINCT] select_expr [, ...]
FROM table
[GLOBAL] [ANY|ALL] INNER|LEFT|RIGHT|FULL [OUTER] JOIN table ON expr
[WHERE expr]
[GROUP BY expr_list]
[HAVING expr]
[ORDER BY expr [ASC|DESC], ...]
[LIMIT [n,] m]

--子查询
SELECT ...
FROM ...
WHERE expr IN (SELECT ...)

-- 聚合函数
SELECT COUNT(*), AVG(column), SUM(column), MIN(column), MAX(column)
FROM table

-- 时间序列查询
SELECT ...
FROM ...
SAMPLE BY column
FILL(column) [PREVIOUS] [interpolation]

管理语法：

-- 管理命令
SHOW [SETTINGS|CREATE|TABLES|COLUMNS|PROCESSLIST|QUERIES|PROFILES|EVENTS|DICTIONARIES|ZOOKEEPER|STORAGE POLICIES|CLUSTER|GRANTS|PROCESSLIST|ACCESS]

-- 系统函数
SELECT * FROM system.tables

6.2 数据类型

以下是ClickHouse支持的一些主要数据类型：

数值类型：

• UInt8, UInt16, UInt32, UInt64: 无符号整数
• Int8, Int16, Int32, Int64: 有符号整数
• Float32, Float64: 浮点数

---

日期和时间类型：

• Date: 日期
• DateTime: 日期和时间
• DateTime64: 带有精确度的日期和时间

---

字符串类型：

• String: 固定长度字符串
• FixedString(n): 固定长度字符串，其中n是字符串长度

---

二进制数据类型：

• UUID: 通用唯一标识符
• IPv4, IPv6: IPv4和IPv6地址
• LowCardinality(T): 低基数的列，用于枚举类型等

---

数组和元组类型：

• Array(T): 数组
• Tuple(T1, T2, …): 元组，可以包含不同类型的元素

---

集合类型：

• AggregateFunction: 聚合函数

---

其他类型：

• Nullable(T): 可空类型
• Enum8, Enum16: 枚举类型
• Nested: 嵌套数据类型

7. Clickhouse常见问题与排查

7.1 常见问题

1. 重启 ClickHouse 服务的时间会比较长

• 主要是由于该节点数据分片过多导致加载缓慢，耐心等待即可。

2. 数据插入报错 too many parts exception

• 主要是由于数据插入过于频繁，导致数据分片在后台 merge 缓慢，ClickHouse 启动自我保护机制，拒绝数据继续插入。此时可尝试增大插入数据的 batch_size (10 万) 并降低数据插入的频率（每秒 1 次）以缓解该问题。

3. 复制表变为只读

• 主要是由于 ClickHouse 无法连接 ZooKeeper 集群或 ZooKeeper 上该复制表的元数据丢失导致的，此时新数据无法插入该表。若要解决该问题，首先要检查 ZooKeeper 的连接状况，如果连接失败，则需进一步检查网络状态以及 ZooKeeper 的状态，连接恢复后，复制表就可以继续插入数据了。如果连接正常而元数据丢失，此时可以将复制表转为非复制表然后再进行数据插入操作。

4. 执行 JOIN 操作时内存超限

• 可能是由于 JOIN 前后的两个子查询中没有添加明确的过滤条件导致的，也有可能是由于 JOIN 的数据本身就很大，无法全部加载到内存。此时可以尝试增加过滤条件以减小数据量，或者适当修改配置文件中的内存限制，以装载更多的数据。

7.2 问题排查方法

1. 检查 ClickHouse 运行状态，确保服务正常运行。
2. 检查 ClickHouse 错误日志文件，寻找问题根源。
3. 检查系统日志文件 (/var/log/messages) 中与 ClickHouse 相关的记录，查看是否是系统操作导致 ClickHouse 异常。
4. 对于未知问题或 BUG，可以到官方 GitHub 仓库的 issue 下寻求帮助，需提供完整的问题描述和错误日志信息。

8. Clickhouse性能优化

8.1 性能优化方式

合理设计表结构：

• 考虑表的分区方式，选择适当的主键和索引，以支持查询性能。
• 考虑数据类型的选择，选择合适大小的数据类型，减小存储空间。
• 使用合适的引擎，例如 MergeTree 引擎适用于大规模数据分析。

合理使用分区：

• 根据查询模式选择合适的分区字段，以减小扫描范围，提高查询性能。
• 避免过多分区，因为分区数量过多可能导致合并操作变得复杂。

索引的使用：

• 使用主键索引以提高唯一性查询的性能。
• 使用辅助索引以加速其他类型的查询。但请注意，辅助索引可能会增加写入的复杂性。

合理配置硬件：

• 确保服务器硬件足够强大，特别是磁盘 I/O、内存和 CPU。
• 使用 SSD 替代传统磁盘，以提高磁盘读写速度。
• 考虑使用 NVMe 存储，以更进一步提升 I/O 性能。

查询优化：

• 使用合适的查询条件，避免全表扫描。
• 避免在大表上进行复杂的 JOIN 操作，可以通过分布式计算将查询分解为多个小查询。
• 合理利用 ClickHouse 的内置函数，以减少数据传输和处理的开销。

适当的集群规模：

• 考虑数据量和查询负载，适当调整集群规模。
• 在大规模集群中，使用 Distributed 引擎以实现分布式查询。

数据导入优化：

• 使用批量插入操作以提高数据导入速度。
• 考虑使用异步数据导入，避免实时要求。

系统参数调优：

• 调整 ClickHouse 的配置参数，例如缓存大小、线程数等，以适应不同的硬件和工作负载。

定期维护：

• 定期进行表的优化操作，如 OPTIMIZE TABLE，以减小存储空间并提高查询性能。
• 定期进行系统统计信息的收集，以帮助 ClickHouse 进行更好的查询计划优化。

监控和日志：

• 设置监控和日志，及时发现性能问题并进行调整。
• 根据日志进行故障排查和性能分析。

8.2 系统参数调优

以下是一个示例，将一些调优建议整合到 ClickHouse 的配置文件 config.xml 中，并附有详细描述：

<!-- config.xml -->

<!-- 设置单个查询可以使用的最大线程数 -->
<max_threads>16</max_threads>

<!-- 设置单个查询可以使用的最大内存量 -->
<max_memory_usage>10000000000</max_memory_usage>

<!-- 在进行 GROUP BY 操作之前，最大的数据大小，超过这个大小将执行外部 GROUP BY -->
<max_bytes_before_external_group_by>10000000000</max_bytes_before_external_group_by>

<!-- 在进行 ORDER BY 操作之前，最大的数据大小，超过这个大小将执行外部排序 -->
<max_bytes_before_external_sort>10000000000</max_bytes_before_external_sort>

<!-- MergeTree 引擎执行合并操作的线程数 -->
<merge_tree>
    <merge_threads>4</merge_threads>
</merge_tree>
<!-- MergeTree 引擎合并操作的块大小 -->
<merge_tree>
    <merge_max_block_size>10000000</merge_max_block_size>
</merge_tree>

<!-- 查询日志的最大长度 -->
<query_log>
    <max_length>1000000</max_length>
</query_log>
<!-- 记录查询执行过程中的日志级别 -->
<query_thread_log>
    <log_level>2</log_level>
</query_thread_log>

<!-- 启用分布式聚合的内存优化 -->
<settings>
    <distributed_aggregation_memory_efficient>1</distributed_aggregation_memory_efficient>
</settings>

<!-- 禁用压缩缓存 -->
<settings>
    <use_uncompressed_cache>1</use_uncompressed_cache>
</settings>

max_threads：指定单个查询可以使用的最大线程数。

• 调优建议：根据服务器的 CPU 核数和负载情况，适当设置 max_threads。在高负载情况下，可以适当降低。

max_memory_usage：指定单个查询可以使用的最大内存量。

• 调优建议：根据服务器的可用内存和工作负载，合理设置 max_memory_usage。避免设置得太大，以防止系统因为内存不足而变得缓慢。

max_bytes_before_external_group_by：指定在进行 GROUP BY 操作之前，最大的数据大小，超过这个大小将执行外部 GROUP BY。

• 调优建议：根据 GROUP BY 操作的频率和数据量，适当调整该参数。对于大数据量的 GROUP BY 操作，考虑增大该值。

max_bytes_before_external_sort：指定在进行 ORDER BY 操作之前，最大的数据大小，超过这个大小将执行外部排序。

• 调优建议：根据 ORDER BY 操作的频率和数据量，适当调整该参数。对于大数据量的 ORDER BY 操作，考虑增大该值。

merge_tree的merge_threads：指定 MergeTree 引擎执行合并操作的线程数。

• 调优建议：根据服务器的 CPU 核数和硬盘 I/O 的能力，适当调整 merge_threads。可以考虑增大该值以加速数据合并。

merge_tree的merge_max_block_size：指定 MergeTree 引擎合并操作的块大小。

• 调优建议：根据硬盘 I/O 和表分区的大小，适当调整 merge_max_block_size。通常情况下，增大该值有助于减小合并操作的开销。

query_log_max_length：指定查询日志的最大长度。

• 调优建议：根据日志记录需求，适当调整 query_log_max_length。对于需要详细查询日志的场景，可以增大该值。

query_thread_log_level：指定记录查询执行过程中的日志级别。

• 调优建议：在需要调试查询性能问题时，将 query_thread_log_level 设置为较低的日志级别，以获取更详细的查询执行信息。

distributed_aggregation_memory_efficient：启用分布式聚合的内存优化。

• 调优建议：对于涉及到分布式聚合操作的场景，启用该参数以优化内存使用。

use_uncompressed_cache：禁用压缩缓存。

• 调优建议：在硬盘 I/O 足够快的情况下，禁用压缩缓存可以提高查询性能。