学习(mianshi)必备-ClickHouse高性能查询/写入和常见注意事项(五)

目录

一、ClickHouse高性能查询原因-稀疏索引

 二、ClickHouse高性能写入-LSM-Tree存储结构

什么是LSM-Tree

 三、ClickHouse的常见注意事项和异常问题排查

---

一、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