文章目录
- 1. 写入方法
- 方法一：文件导入
- 方法二：插入语句
- 方法三：JDBC接口
- 2. 性能瓶颈
- 3. 其它注意事项
- 4. 总结
众所周知，在精心设计的索引（见前文：
clickhouse之索引）以及极致压制硬件物理性能(见前文
clickhouse之向量执行引擎)的作用下，clickhouse单机表现出卓越的查询和计算性能。但是有些使用场景，对数据库的写性能要求同样很高，那么clickhouse在写数据上的表现究竟如何呢？因为最近我们的小伙伴因为项目需要有做过一些测试，我简单总结一下吧~~
1. 写入方法
方法一：文件导入
具体方法见前文：clickhouse文件导入导出，该方法的优点是：写入性能好，相当于其它关系型数据库copy式的的写入；但缺点也很明显，就是使用比较受限，没有办法从其他机器上进行数据的写入。
方法二：插入语句
通过insert语句逐条插入的方法性能最差，且对于MergeTree表引擎来说，在大数据量写入的情况下该方法会触发频繁的后台文件合并，甚至会出现“too many parts”的错误。 当然该方法也有提升的办法，就是将一批数据用一条insert数据来写入，举例如下：
INSERT INTO mytable VALUES
('2010-03-10', 28194901262, '8006-6129-3130-5580', 1169)
('2015-10-17', 67128904894, '4681-5453-2740-1617', 8109)
('2013-08-05', 79681799770, '6661-8986-3509-6991', 55);这个问题在clickhouse的github上有issue讨论，见：https://github.com/ClickHouse/ClickHouse/issues/1067
方法三：JDBC接口
目前来看，使用jdbc接口主要有两种驱动：一种是官方发布的使用HTTP协议的驱动；还有一种是housepower开源的基于TCP的驱动。从看到的一些资料来说，普遍反映使用housepower的驱动性能优于官方提供的版本；从我们自己的测试结果来看也大致如此：单个分片的情况下，使用housepower驱动的性能（150MB/s）接近于官方（80MB/s）的两倍，但是有一个现象是随着分片数的增多，使用官方JDBC驱动的性能会随着分片数线性增长，而housepower驱动则不会，尤其在分片数大于8个以后，官方的性能反而更佳。
2. 性能瓶颈
从我们测试的过程和结果来看，影响clickhouse写入性能的包括如下因素：
- 网卡带宽：在使用千兆网卡的情况下，网络很容易成为整个写入测试的瓶颈，一般到80MB/s左右；在换用万兆网卡后，速度可以测到150MB/s~200MB/s以上。
- 磁盘IO：如果clickhouse只配置了单块儿SATA盘做数据盘，那么磁盘IO也会是提升写入性能的瓶颈所在，建议使用多块儿盘做RAID。
- CPU：我们测试使用了24核的服务器，当写入测试程序激励打到150MB/s以上的速度时，整个CPU的使用率会较长时间处于2000%以上。
- 物化视图：如果写入的表上有相关的物化视图逻辑，那么也会影响到最终的写入性能，因为CPU会将很多计算用在物化视图的处理上，具体影响大小取决于物化视图逻辑的复杂度以及物化视图的数量，从我们自己的项目来看，下降了至少一半的性能。
3. 其它注意事项
- 对于分布式CH集群的写入，建议写本地表，而不是直接写分布式表，具体原因在于如果写入分布式表，那么写入的那个点容易成为单点故障或瓶颈；写入本地表的话则可以使用chproxy来做代理转发流量，或者自己实现流量的负载均衡。
- 通过JDBC接口进行写入时，要注意batchSize的调优，太小容易出现“too many parts”的问题，太大又会使整体的写入性能下降，具体的取值可根据实际的环境做调整。
- 副本的存在对整体写入性能的影响不大。
4. 总结
总体来看，在理想情况下，clickhouse的写入性能能够达到官方宣称的200MB/s左右（https://clickhouse.com/docs/zh/introduction/performance/#shu-ju-de-xie-ru-xing-neng），且总体写入性能还可以通过多分片的方式来进行扩展。这样的表现基本能够满足我们的使用需求。
