【大数据实战】聊聊clickhouse的性能问题-高性能分析

聊聊ck的性能问题

在OLAP的查询场景中，同样的数据量，ClickHouse表现出了比同类可比较产品更优的性能。
查看Yandex的内部测试结果：结果

可以看到CK在OLAP场景下的性能还是非常强的，那么是不是它在每个指标上表现都很好呢？
事实上，并不是这样的，它也有自己的缺点，接下来我们可以大致来看看ClickHouse的性能指标。

单个大查询的吞吐量

吞吐量可以使用每秒处理的行数或每秒处理的字节数来衡量。

如果数据被放置在page cache中，则一个不太复杂的查询在单个服务器上大约能够以2-10GB／s（未压缩）的速度进行处理（对于简单的查询，速度可以达到30GB／s）。
如果数据没有在page cache中的话，那么速度将取决于你的磁盘系统和数据的压缩率。例如，如果一个磁盘允许以400MB／s的速度读取数据，并且数据压缩率是3，则数据的处理速度为1.2GB/s。这意味着，如果你是在提取一个10字节的列，那么它的处理速度大约是1-2亿行每秒。

对于分布式处理，处理速度几乎是线性扩展的，但这受限于聚合或排序的结果不是那么大的情况下。

所以影响ck单个查询吞吐量的因素大概有这些：

• 查询复杂性：复杂的查询通常需要更多的计算和资源，可能会对查询吞吐量产生负面影响。复杂的查询包括多个聚合函数、子查询、连接等。简单的查询通常比复杂的查询具有更高的吞吐量。

• 硬件配置：ClickHouse 的性能与底层硬件配置密切相关。例如，处理器的性能、内存的容量和带宽、磁盘的类型和速度等都会对查询吞吐量产生影响。优化硬件配置可以提高 ClickHouse 的性能。

• 数据模型和表设计：合理的数据模型和表设计可以提高查询性能。例如，使用合适的数据类型、分区表、合理的表结构等都可以减少查询的数据量和提高查询性能。

• 数据分布和复制：ClickHouse 支持数据分布和复制来实现数据的高可用性和负载均衡。合理的数据分布和复制策略可以提高查询性能。如果数据分布不均匀或者复制策略不合理，可能导致查询吞吐量下降。

• 并发查询：ClickHouse 支持并发查询，可以同时处理多个查询请求。如果系统中存在大量并发查询，可能会降低单个查询的吞吐量。合理的并发配置可以平衡吞吐量和响应时间。

• 查询优化：ClickHouse 提供了一些查询优化的技术，例如预先计算、索引、采样等。合理使用这些优化技术可以提高查询性能和吞吐量。

处理短查询的延迟时间

如果一个查询使用主键并且没有太多行(几十万)进行处理，并且没有查询太多的列，那么在数据被page cache缓存的情况下，它的延迟应该小于50毫秒(在最佳的情况下应该小于10毫秒)。
否则，延迟取决于数据的查找次数。如果你当前使用的是HDD，在数据没有加载的情况下，查询所需要的延迟可以通过以下公式计算得知： 查找时间（10 ms） * 查询的列的数量 * 查询的数据块的数量。

什么是短查询？
短查询是指执行时间非常短的查询操作。通常情况下，短查询的执行时间在几毫秒甚至更短的时间范围内完成。这些查询通常是简单的、针对少量数据进行的操作，例如基于某个条件的快速过滤、获取少量列的数据等。

短查询通常具有以下特点：

简单：短查询通常只涉及一两个条件和少量的列，并且不包含复杂的聚合操作或连接操作。

快速：由于短查询操作的数据量较小，执行时间通常非常短，一般在几毫秒的时间范围内完成。

高并发：由于短查询的执行时间短，可以在单位时间内处理大量的查询请求，适合于高并发的场景。

短查询在实际应用中非常常见，尤其是在交互式应用、实时分析和监控等场景下。这些查询通常用于快速获取实时数据、实时监控系统的状态或指标，并对结果进行实时展示或响应。

为什么查询公式是：查找时间（10 ms） * 查询的列的数量 * 查询的数据块的数量

查找时间（10 ms）：假设每个查找操作的平均时间为 10 毫秒。这是一个经验值，可以根据实际情况进行调整。

查询的列的数量：假设查询涉及的列的数量是一个固定值。这个值可以根据具体的查询语句确定。

查询的数据块的数量：假设查询需要扫描的数据块数量也是一个固定值。数据块是 ClickHouse 中数据的存储单元，查询的吞吐量可以受到扫描的数据块数量的影响。

处理大量短查询的吞吐量

在相同的情况下，ClickHouse可以在单个服务器上每秒处理数百个查询（在最佳的情况下最多可以处理数千个）。但是由于这不适用于分析型场景。因此建议每秒最多查询100次。

数据的写入性能

建议每次写入不少于1000行的批量写入，或每秒不超过一个写入请求。
当使用tab-separated格式将一份数据写入到MergeTree表中时，写入速度大约为50到200MB/s。如果您写入的数据每行为1Kb，那么写入的速度为50，000到200，000行每秒。如果行更小，那么写入速度将更高。为了提高写入性能，可以使用多个INSERT进行并行写入，这将带来线性的性能提升。

为什么clickhouse的写入性能高？

1.列存
2.数据压缩：能够有效地减少数据的存储空间，从而提高写入性能
3.分布式架构
4.多线程写入：ClickHouse采用多线程写入机制，能够同时处理多个写入请求，从而提高写入性能。

磁盘顺序读写和随机读写的性能差距大概是1千到5千倍之间
连续 I/O 顺序读写，磁头几乎不用换道，或者换道的时间很短，性能很高，比如0.03 * 2000 MB /s
随机 I/O 随机读写，会导致磁头不停地换道，造成效率的极大降低，0.03MB/s

ClickHouse中的MergeTree也是LSM-Tree存储结构的思想（日志结构合并树，但不是树），而是利用磁盘顺序读写能力，实现一个多层读写的存储结构 是一种分层，有序，面向磁盘的数据结构，核心思想是利用了磁盘批量的顺序写要远比随机写性能高出很多 大大提升了数据的写入能力。
充分利用了磁盘顺序写的特性，实现高吞吐写能力，数据写入后定期在后台Compaction。在数据导入时全部是顺序append写，在后台合并时也是多个段merge sort后顺序写回磁盘。官方公开benchmark测试显示能够达到50MB-200MB/s的写入吞吐能力，按照每行100Byte估算，大约相当于50W-200W条/s的写入速度。

它的缺点

1，不支持事务，不支持真正的删除/更新；
2，不支持高并发，官方建议qps为100，可以通过修改配置文件增加连接数，但是在服务器足够好的情况下；
3，SQL满足日常使用80%以上的语法，join写法比较特殊；最新版已支持类似SQL的join，但性能不好；
4，尽量做1000条以上批量的写入，避免逐行insert或小批量的insert，update，delete操作，因为ClickHouse底层会不断的做异步的数据合并，会影响查询性能，这个在做实时数据写入的时候要尽量避开；
5，Clickhouse快是因为采用了并行处理机制，即使一个查询，也会用服务器一半的CPU去执行，所以ClickHouse不能支持高并发的使用场景，默认单查询使用CPU核数为服务器核数的一半，安装时会自动识别服务器核数，可以通过配置文件修改该参数。