引用地址:https://blog.csdn.net/wnn654321/article/details/129209041
一、ClickHouse高性能查询原因-稀疏索引
密集索引:
在密集索引中,数据库中的每个键值都有一个索引记录,可以加快搜索速度,但需要更多空间来存储索引记录本身,索引记录包含键值和指向磁盘上实际记录的指针。
mysql中Innodb引擎的主键就是密集索引
稀疏索引:
在稀疏索引中,不会为每个关键字创建索引记录,而是为数据记录文件的每个存储块设一个键-指针对,存储块意味着块内存储单元连续
案例:
Mysql的MyISAM引擎里面, 使用均为稀疏索引;
Mysql的Innodb引擎里面,如果有主键,则主键为密集索引
Kafka里面的索引文件也是采用稀疏索引进行构造消息索引
ClickHouse的合并树MergeTree引擎是稀疏索引,默认index_granularity设置8192,新版本的提供了自适应粒度大小的特性
建表语句最后加这个,可以调整
SETTINGS index_granularity = 8192
结论:
ClickHouse一级索引就是【稀疏索引】,可以大幅减少索引占用的空间
默认的索引力度8192,假如1亿行数据只需要存储12208行索引,占用空间小,clickhouse中一级索引的数据是常驻内存的,取用速度极快
稀疏索引所占空间小,并且插入和删除时所需维护的开销也小,缺点是速度比密集索引慢一点
密集索引空间占用多,比稀疏索引更快的定位一条记录,缺点就是会占用较多的空间
不变思想:时间换空间、空间换时间
二、ClickHouse高性能写入-LSM-Tree存储结构
先明白一个测试数据:
磁盘顺序读写和随机读写的性能差距大概是1千到5千倍之间
连续 I/O 顺序读写,磁头几乎不用换道,或者换道的时间很短,性能很高,比如0.03 * 2000 MB /s
随机 I/O 随机读写,会导致磁头不停地换道,造成效率的极大降低,0.03MB/s
ClickHouse中的MergeTree也是类LSM树的思想,所以我们也需要了解LSM树
充分利用了磁盘顺序写的特性,实现高吞吐写能力,数据写入后定期在后台Compaction
在数据导入时全部是顺序append写,在后台合并时也是多个段merge sort后顺序写回磁盘
官方公开benchmark测试显示能够达到50MB-200MB/s的写入吞吐能力,按照每行100Byte估算,大约相当于50W-200W条/s的写入速度
什么是LSM-Tree
全称 Log-Structured Merge-Tree 日志结构合并树,但不是树,而是利用磁盘顺序读写能力,实现一个多层读写的存储结构
是一种分层,有序,面向磁盘的数据结构,核心思想是利用了磁盘批量的顺序写要远比随机写性能高出很多
大大提升了数据的写入能力,但会牺牲部分读取性能为代价
HBase、LevelDB、ClickHouse这些NoSQL存储都是采用的类LSM树结构
在 NoSQL 系统里非常常见,基本已经成为必选方案, 为了解决快速读写的问题去设计的
可以分两个部分理解
Log-Structured日志结构的,打印日志是一行行往下写,不需要更改,只需要在后边追加就好了
Merge-tree ,合并就是把多个合成一个,自上而下
LSM-tree 是一个多层结构,就更一个喷泉树一样,上小下大
专门为 key-value 存储系统设计的,最主要的就两个个功能
写入put(k,v)
查找 get(k)得到v
首先是内存的 C0 层,保存了所有最近写入的 (k,v),这个内存结构是有序的,且可以随时原地更新,同时支持随时查询
接下去的 C1 到 Ck 层都在磁盘上,每一层都是一个有序的存储结构
降低一点读性能,通过牺牲小部分读性能,换来高性能写
写入流程:
put 操作,首先追加到写前日志(Write Ahead Log),然后加到C0 层
当 C0 层的数据达到一定大小,就把 C0 层 和 C1 层合并,这个过程就是Compaction(合并)
合并出来的新的C1 会顺序写磁盘,替换掉原来的C1
当 C1 层达到一定大小,会和下层继续合并,合并后删除旧的,留下新的
查询流程:
最新的数据在 C0 层,最老的数据在 Cn 层
查询也是先查 C0 层,如果没有要查的数据,再查 C1,逐层查下去直到最后一层
缺点:
读放大:
读取数据时实际读取的数据量大于真正的数据量,在LSM树中需要先在C0查看当前key是否存在,不存在继续从Cn层中寻找
写放大:
写入数据时实际写入的数据量大于真正的数据量,在LSM树中写入时可能触发Compact操作,导致实际写入的数据量远大于该key的数据量
三、ClickHouse的常见注意事项和异常问题排查
注意点一:
查询要使用的列,避免select * 全部字段,浪费IO资源
注意点二:
避免大量的小批量数据,插入更新操作,会导致分区过多
每次插入1条,产生了一个分区,大量写入产生大量临时分区和合并操作浪费资源
注意点三:
JOIN操作时一定要把数据量小的表放在右边,无论是Left Join 、Right Join还是Inner Join,右表中的每一条记录到左表中查找该记录是否存在,所以右表必须是小表
注意点四:
批量写入数据时,控制每个批次的数据中涉及到的分区的数量,无序的数据导致涉及的分区太多,建议写入之前最好对需要导入的数据进行排序
注意点五:
写入分布式表还是本地表? 建议:数据量不大,写入本地表和分布式表都行
分布式表不存储数据,本地表存储数据的表
大量数据,日新增500万行以上,分布式表在写入时会在本地节点生成临时数据,会产生写放大,所以会对CPU及内存造成一些额外消耗,服务器merge的工作量增加, 导致写入速度变慢;
数据写入默认是异步的(可以开启同步写但性能会影响),先在分布式表所在的机器进行落盘, 然后异步的发送到本地表所在机器进行存储,中间没有一致性的校验,短时间内可能造成不一致,且如果分布式表所在机器时如果机器出现down机, 会存在数据丢失风险。
建议大数据量尽量少使用分布式表进行写操作,可以根据业务规则均衡的写入本地表;
必须用的话尽量只用读,因为写分布式表对性能影响非常大
注意点六:
单sql查询可以压榨CPU ,但并发多条查询则不是很强
一个分区查询占据一个CPU,业务需要查询表的多个分区可以多个CPU并行处理
注意点七:
没有完整的事务支持,不支持Transaction
OLAP类业务由于数据量非常大,建议数据批量写入,尽量避免数据更新或少更新
注意点八:
在分布式模式下,ClickHouse会将数据分为多个分片,并且分布到不同节点上,有哪种分片策略
ClickHouse提供了丰富的sharding策略,让业务可以根据实际需求选用
random随机分片:写入数据会被随机分发到分布式集群中的某个节点上
constant固定分片:写入数据会被分发到固定一个节点上
hash column value分片:按照某一列的值进行hash分片
常见异常问题:
错误码 300,Too many parts
写入频率过快,使用了不合理的分区键导致总的 part 数目太多,直接拿精确到秒的 timestamp 来作为分区键来进行分区,GG了。
错误码252,Too many partitions for single INSERT block (more than 100),同一批次写入里包括大于100个分区值,clickhouse认为这样会存在性能问题
让数据是按照天/小时分区的,一批数据里的日期跨度为一年,单次插入可能产生365个分区,导致后台异步合并数据出现问题,也避免跨度过大
解决方案:单批次写入数据,要控制写入分区过多
参数:max_partitions_per_insert_block 限制单个插入块中的最大分区数,默认是100
————————————————
版权声明:本文为CSDN博主「这是王姑娘的微博」的原创文章,遵循CC 4.0 BY-SA版权协议,转载请附上原文出处链接及本声明。
原文链接:https://blog.csdn.net/wnn654321/article/details/129209041