clickhouse性能情况以及相关优化
⼀、ClickHouse性能情况
主要分为4个⽅⾯
1、单个查询吞吐量
场景⼀:
如果数据被放置在page cache中,则⼀个不太复杂的查询在单个服务器上⼤约能够以2-10GB/s(未压缩)的速度进⾏处理(对于简单的查询,速度可以达到30GB/s)
场景⼆:
如果数据没有在page cache中的话,那么速度将取决于你的磁盘系统和数据的压缩率
例如:
a、如果⼀个磁盘允许以400MB/s的速度读取数据,并且数据压缩率是3,则数据的处理速度为1.2GB/s。
b、这意味着,如果你是在提取⼀个10字节的列,那么它的处理速度⼤约是1-2亿⾏每秒
c、对于分布式处理,处理速度⼏乎是线性扩展的,但这受限于聚合或排序的结果不是那么⼤的情况下
2、处理短查询的延时时间
(1)数据被page cache缓存的情况下,它的延迟应该⼩于50毫秒(最佳情况下应该⼩于10毫秒),否则,延迟取决于数据的查次数
(2)延迟可以通过以下公式计算得知:查时间(10 ms) * 查询的列的数量 * 查询的数据块的数量
3、处理⼤量短查询
(1)ClickHouse可以在单个服务器上每秒处理数百个查询(在最佳的情况下最多可以处理数千个)
(2)但是由于这不适⽤于分析型场景。建议每秒最多查询100次
4、数据写⼊性能
(1)建议每次写⼊不少于1000⾏的批量写⼊,或每秒不超过⼀个写⼊请求
(2)当使⽤tab-separated格式将⼀份数据写⼊到MergeTree表中时,写⼊速度⼤约为50到200MB/s
(3)如果您写⼊的数据每⾏为1Kb,那么写⼊的速度为50,000到200,000⾏每秒
(4)如果您的⾏更⼩,那么写⼊速度将更⾼
(5)如果您的⾏更⼩,那么写⼊速度将更⾼
注意:ClickHouse并⾮⽆所不能,查询语句需要不断的调优,可能与查询条件有关,不同的查询条件表是左join还是右join也是很有讲究的
补充问题:
mysql与ClickHouse性能写⼊区别?
mysql:
(1)MySQL单条SQL是单线程的,只能跑满⼀个core
(2)IO⽅⾯,MySQL是⾏存储,MySQL需要⼤量随机IO
ClickHouse:
(1)ClickHouse相反,有多少CPU,吃多少资源,所以飞快
(2)ClickHouse不⽀持事务,不存在隔离级别。ClickHouse的定位是分析性数据库,⽽不是严格的关系型数据库
(3)IO⽅⾯,ClickHouse是列存储,后者在count()这类操作天然有优势,ClickHouse基本是顺序IO
思考:
据导⼊的时候,数据肯定缓存在内存⾥了,这个的确,但是ClickHouse基本上是顺序IO。对IO基本没有太⾼要求,当然,磁盘越快,上层处理越快,但是99%的情况是,CPU先跑满了(数据库⾥太少见了,⼤多数都是IO不够⽤)
⼆、ClickHouse相关优化
(1)关闭虚拟内存,物理内存和虚拟内存的数据交换,会导致查询变慢
(2)为每⼀个账户添加join_use_nulls配置,左表中的⼀条记录在右表中不存在,右表的相应字段会返回该字段相应数据类型的默认值,⽽不是标准SQL中的Null 值
(3)JOIN操作时⼀定要把数据量⼩的表放在右边,ClickHouse中⽆论是Left Join 、Right Join还是Inner Join永远都是拿着右表中的每⼀条记录到左表中查该记录是否存在,所以右表必须是⼩表
(4)批量写⼊数据时,必须控制每个批次的数据中涉及到的分区的数量,在写⼊之前最好对需要导⼊的数据进⾏排序。⽆序的数据或者涉及的分区太多,会导致ClickHouse⽆法及时对新导⼊的数据进⾏合并,从⽽影响查询性能
(5)尽量减少JOIN时的左右表的数据量,必要时可以提前对某张表进⾏聚合操作,减少数据条数。有些时候,先GROUP BY再JOIN⽐先JOIN再GROUP BY查询时间更短
(6)ClickHouse的分布式表性能性价⽐不如物理表⾼,建表分区字段值不宜过多,防⽌数据导⼊过程磁盘可能会被打满
(7)CPU⼀般在50%左右会出现查询波动,达到70%会出现⼤范围的查询超时,CPU是最关键的指标,要⾮常关注
三、ClickHouse有哪些优缺点?
优点:
(1)为了⾼效的使⽤CPU,数据不仅仅按列存储,同时还按向量进⾏处理
(2)数据压缩空间⼤,减少IO;处理单查询⾼吞吐量每台服务器每秒最多数⼗亿⾏
(3)索引⾮B树结构,不需要满⾜最左原则;只要过滤条件在索引列中包含即可;即使在使⽤的数据不在索引中,由于各种并⾏处理机制ClickHouse全表扫描的速度也很快
(4)写⼊速度⾮常快,50-200M/s,对于⼤量的数据更新⾮常适⽤
缺点:
(1)不⽀持事务,不⽀持真正的删除/更新
(2)不⽀持⾼并发,官⽅建议qps为100,可以通过修改配置⽂件增加连接数,但是在服务器⾜够好的情况下
(3)不⽀持真正的删除/更新⽀持不⽀持事务(期待后续版本⽀持)
(4)不⽀持⼆级索引
(5)有限的SQL⽀持,join实现与众不同
(6)不⽀持窗⼝功能
(7)元数据管理需要⼈⼯⼲预维护
(8)SQL满⾜⽇常使⽤80%以上的语法,join写法⽐较特殊;最新版已⽀持类似SQL的join,但性能不好
(9)ClickHouse快是因为采⽤了并⾏处理机制,即使⼀个查询,也会⽤服务器⼀半的CPU去执⾏,所以ClickHouse不能⽀持⾼并发的使⽤场景,默认单查询使⽤CPU核数为服务器核数的⼀半,安装时会⾃动识别服务器核数,可以通过配置⽂件修改该参数
四、ClickHouse的特性有哪些?
(1)真正的列式数据库管理系统
概述:
除了数据本⾝外不应该存在其他额外的数据意味着为了避免在值旁边存储它们的长度«number»,你必须⽀持固定长度数值类型
例如:
a、10亿个UInt8类型的数据在未压缩的情况下⼤约消耗1GB左右的空间,如果不是这样的话,这将对CPU的使⽤产⽣强烈影响
b、即使是在未压缩的情况下,紧凑的存储数据也是⾮常重要的,因为解压缩的速度主要取决于未压缩数据的⼤⼩
注意:hbase的特性有哪些
a、在⼀些其他系统中也可以将不同的列分别进⾏存储,但由于对其他场景进⾏的优化,使其⽆法有效的处理分析查询。例如:
HBase,BigTable,Cassandra,HyperTable
b、在这些系统中,你可以得到每秒数⼗万的吞吐能⼒,但是⽆法得到每秒⼏亿⾏的吞吐能⼒
说明:
a、ClickHouse不单单是⼀个数据库,它是⼀个数据库管理系统
b、它允许在运⾏时创建表和数据库、加载数据和运⾏查询,⽽⽆需重新配置或重启服务
(2)数据压缩
a、⼀些列式数据库管理系统中(例如:InfiniDB CE 和 MonetDB) 并没有使⽤数据压缩
b、但是, 若想达到⽐较优异的性能,数据压缩确实起到了⾄关重要的作⽤。
(3)数据的磁盘存储
a、许多的列式数据库(如 SAP HANA, Google PowerDrill)只能在内存中⼯作,这种⽅式会造成⽐实际更多的设备预算
b、ClickHouse被设计⽤于⼯作在传统磁盘上的系统,它提供每GB更低的存储成本,但如果有可以使⽤SSD和内存,它也会合理的利⽤这些资源
(4)多核⼼并⾏处理
ClickHouse会使⽤服务器上⼀切可⽤的资源,从⽽以最⾃然的⽅式并⾏处理⼤型查询
(5)多服务器分布式处理
a、列式数据库管理系统中,⼏乎没有⼀个⽀持分布式的查询处理
b、在ClickHouse中,数据可以保存在不同的shard上,每⼀个shard都由⼀组⽤于容错的replica组成,查询可以并⾏地在所有shard上进⾏处理。这些对
⽤户来说是透明的
(6)⽀持SQL
a、ClickHouse⽀持基于SQL的声明式查询语⾔,该语⾔⼤部分情况下是与SQL标准兼容的
b、⽀持的查询包括 GROUP BY,ORDER BY,IN,JOIN以及⾮相关⼦查询
c、不⽀持窗⼝函数和相关⼦查询
(7)向量引擎
为了⾼效的使⽤CPU,数据不仅仅按列存储,同时还按向量(列的⼀部分)进⾏处理,这样可以更加⾼效地使⽤CPU
(8)实时的数据更新
a、ClickHouse⽀持在表中定义主键
b、为了使查询能够快速在主键中进⾏范围查,数据总是以增量的⽅式有序的存储在MergeTree中
c、因此,数据可以持续不断地⾼效的写⼊到表中,并且写⼊的过程中不会存在任何加锁的⾏为
(9)索引
按照主键对数据进⾏排序,这将帮助ClickHouse在⼏⼗毫秒以内完成对数据特定值或范围的查
(10)适合在线查询
在线查询意味着在没有对数据做任何预处理的情况下以极低的延迟处理查询并将结果加载到⽤户的页⾯中
(11)⽀持近似计算
ClickHouse提供各种各样在允许牺牲数据精度的情况下对查询进⾏加速的⽅法:
a、⽤于近似计算的各类聚合函数,如:distinct values, medians, quantiles
b、基于数据的部分样本进⾏近似查询。这时,仅会从磁盘检索少部分⽐例的数据
c、不使⽤全部的聚合条件,通过随机选择有限个数据聚合条件进⾏聚合。这在数据聚合条件满⾜某些分布条件下,在提供相当准确的聚合结果的同时降
低了计算资源的使⽤
(12)⽀持数据复制和数据完整性
a、ClickHouse使⽤异步的多主复制技术
b、当数据被写⼊任何⼀个可⽤副本后,系统会在后台将数据分发给其他副本,以保证系统在不同副本上保持相同的数据
c、在⼤多数情况下ClickHouse能在故障后⾃动恢复,在⼀些少数的复杂情况下需要⼿动恢复。
五、ClickHouse的超出内存限制解决办法
ClickHouse进⾏复杂查询时,包含多个left join和group by,会报错:超出内存限制。
1.临时设置
SET max_memory_usage = 128000000000; #128G,
如果没有那么多的内存可⽤,ClickHouse可以通过设置这个“溢出”数据到磁盘:
set max_bytes_before_external_group_by=20000000000; #20G
set max_memory_usage=40000000000; #40G
将max_memory_usage设置为max_bytes_before_external_group_by⼤⼩的两倍。
如果发现还是报内存不够或者服务器直接崩溃,设置partial_merge_join = 1,但是运⾏速度会很慢。
2.全局设置
在l⽂件中为每个⽤户设置参数:
#max_memory_usage:在单个ClickHouse服务进程中,运⾏⼀次查询限制使⽤的最⼤内存⽤量,默认值为10G;
#max_bytes_before_external_group_by:在执⾏GROUP BY聚合查询的时候,限制使⽤的最⼤内存⽤量,默认值为0,即不做限制。当超过阈值数量的时候,聚合查询将会进⼀步借⽤本地磁盘。
#use_uncompressed_cache:使⽤未压缩的缓存⼤⼩,默认0不限制。
<max_bytes_before_external_group_by>0</max_bytes_before_external_group_by>
<max_memory_usage>10000000000</max_memory_usage>
<use_uncompressed_cache>0</use_uncompressed_cache>
版权声明:本站内容均来自互联网,仅供演示用,请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198,我们将在24小时内删除。
发表评论