【大数据实战】聊聊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核数为服务器核数的一半,安装时会自动识别服务器核数,可以通过配置文件修改该参数。

你可能感兴趣的:(大数据,clickhouse,数据库)