Clickhouse优缺点、性能以及错误躺坑

最新推荐文章于 2024-08-18 10:35:39 发布

天空飘来一个云哥哥

最新推荐文章于 2024-08-18 10:35:39 发布

阅读量1w

点赞数 4

分类专栏： clickHouse

本文链接：https://blog.csdn.net/qq_42016966/article/details/110487663

版权

clickHouse 专栏收录该内容

16 篇文章 3 订阅

订阅专栏

优点：

为了高效的使用CPU，数据不仅仅按列存储，同时还按向量进行处理；
数据压缩空间大，减少IO；处理单查询高吞吐量每台服务器每秒最多数十亿行；
索引非B树结构，不需要满足最左原则；只要过滤条件在索引列中包含即可；即使在使用的数据不在索引中，由于各种并行处理机制ClickHouse全表扫描的速度也很快；
写入速度非常快，50-200M/s，按照每行100Byte估算，大约相当于50W-200W条/s的写入速度。对于大量的数据更新非常适用。

缺点：

不支持事务；
不支持高并发，官方建议qps为100，可以通过修改配置文件增加连接数，但是在服务器足够好的情况下；
SQL满足日常使用80%以上的语法，join写法比较特殊；最新版已支持类似SQL的join，但性能不好；
尽量做1000条以上批量的写入，避免逐行insert或小批量的insert，update，delete操作，因为ClickHouse底层会不断的做异步的数据合并，会影响查询性能，这个在做实时数据写入的时候要尽量避开；
Clickhouse快是因为采用了并行处理机制，即使一个查询，也会用服务器一半的CPU去执行，所以ClickHouse不能支持高并发的使用场景，默认单查询使用CPU核数为服务器核数的一半，安装时会自动识别服务器核数，可以通过配置文件修改该参数。

相关优化：

为每一个账户添加join_use_nulls配置，左表中的一条记录在右表中不存在，右表的相应字段会返回该字段相应数据类型的默认值，而不是标准SQL中的Null值。
JOIN操作时一定要把数据量小的表放在右边，ClickHouse中无论是Left Join 、Right Join还是Inner Join永远都是拿着右表中的每一条记录到左表中查找该记录是否存在，所以右表必须是小表。
批量写入数据时，必须控制每个批次的数据中涉及到的分区的数量，在写入之前最好对需要导入的数据进行排序。无序的数据或者涉及的分区太多，会导致ClickHouse无法及时对新导入的数据进行合并，从而影响查询性能。
尽量减少JOIN时的左右表的数据量，必要时可以提前对某张表进行聚合操作，减少数据条数。有些时候，先GROUP BY再JOIN比先JOIN再GROUP BY查询时间更短。
ClickHouse的建表分区字段值不宜过多，防止数据导入过程磁盘可能会被打满。
CPU一般在50%左右会出现查询波动，达到70%会出现大范围的查询超时，CPU是最关键的指标，要非常关注。
数据写入性能：建议每次写入不少于1000行的批量写入，或每秒不超过一个写入请求。当使用tab-separated格式将一份数据写入到MergeTree表中时，写入速度大约为50到200MB/s。如果您写入的数据每行为1Kb，那么写入的速度为50，000到200，000行每秒。如果您的行更小，那么写入速度将更高。为了提高写入性能，您可以使用多个INSERT进行并行写入，这将带来线性的性能提升。

其他补充：

MySQL单条SQL是单线程的，只能跑满一个core，ClickHouse相反，有多少CPU，吃多少资源，所以飞快；
ClickHouse不支持事务，不存在隔离级别。ClickHouse的定位是分析性数据库，而不是严格的关系型数据库。
IO方面，MySQL是行存储，ClickHouse是列存储，后者在count()这类操作天然有优势，同时，在IO方面，MySQL需要大量随机IO，ClickHouse基本是顺序IO。
有人可能觉得上面的数据导入的时候，数据肯定缓存在内存里了，这个的确，但是ClickHouse基本上是顺序IO。对IO基本没有太高要求，当然，磁盘越快，上层处理越快，但是99%的情况是，CPU先跑满了（数据库里太少见了，大多数都是IO不够用）。

重点：错误避免
1、Clickhouse 高频删除数据导致 Cannot allocate memory.

001

2、clickHouse中字段没有强类型校验：

注：如果我们建表的时候指定数据类型为int32，但是数据插入时不小心插入了一个超过int32范围的数据，最终存到表里的数据会被ClickHouse内部机制进行截取，造成数据不一致
002
3、clickHouse中对重复数据的处理：

经测试，clickHouse对重复数据插入，同一个分片上会进行去重，不同分片间不保证重复，所以clickHouse对重复数据有可能进行了去重也有可能没去重，这是不预测的！

如果更改配置文件： SET insert_deduplicate=0
那么clickHouse不会对重复数据进行删除，保持跟hive一致
整体配置：在user.xml 中新增 --------> <insert_deduplicate>0</insert_deduplicate>

4、Clickhouse 批量插入报错：Too many partitions for single INSERT block (more than 100)

两种解决办法：
1、配置文件修改：在users.xml配置文件中进行配置。配置在 profiles 块中。CH的配置文件是即时生效，不需要重启服务

2、在一个会话中临时修改：SET max_partitions_per_insert_block=1000。用于临时导入大量数据的情况。
参数：https://www.jianshu.com/p/8aa2a20ab00a

5、Clickhouse 删除数据，然后插入相同的数据不显示

尝试1：执行手动合并命令–→ optimize table +本地表名 ON CLUSTER report_shards_replicas;
optimize table agg_conversion_record_local ON CLUSTER report_shards_replicas;
结果：失败

尝试2 ： SET insert_deduplicate=0
另外ck没有事务概念，但是为了保证重复插入的insert的幂等性，会检测重复，如果重复则跳过。
如果想不跳过可以SET insert_deduplicate=0

不建议关掉这个重复检查，因为这事唯一的幂等性检测，另外重复的数据块是以批次为单位的，如果同一批次和第二批次是一模一样的，通常情况下就不会产生删除了再插入的情况。
结果：成功
6、Clickhouse 新增一个字段，并且赋默认值

语法：ALTER TABLE apm.track_apm_network ADD COLUMN timestamp DateTime DEFAULT now();
问题：历史数据新增字段之后，默认取now()当前时间，每次查询同一条数据结果不一致，每次都是当前时间
解决：测试发现，只有历史数据中的新增的字段会发生变化，新插入的数据正常没有影响。
故添加需要赋now() 时间所需的字段，若历史数据对业务影响不大，可以先truncate 将历史数据清除

7、Clickhouse 有默认时间字段，后续通过insert into插入数据问题

背景： INSERT INTO cs_user_info (id,user_name,pass_word,phone,email) VALUES (100,‘cicada’,‘123’,‘121231231’,‘cicada@com’) 语句，要使用默认值则不必添加默认值的字段，系统会自动生成值
实际代码中调用发现，框架会自动封装所有的字段，类似 INSERT INTO cs_user_info (id,user_name,pass_word,phone,email,time,create_day) VALUES (?,?,?,?,?,?)
产生问题：其中time和create_day必须赋予初始值，若赋初始值的话那么now()当前时间不生效

解决方案：发现在插入数据时可以直接用now()来进行写入，clickHouse后台会自动解析然后生成时间
example：
INSERT INTO cs_user_info (id,user_name,pass_word,phone,email) VALUES (100,‘cicada’,‘123’,‘121231231’,‘cicada@com’,now(),now())

8、Clickhouse 的物化视图的大坑介绍

物化视图的工作原理：当将数据写入到物化视图中SELECT子句所指定的表时，插入的数据会通过SELECT子句查询进行转换并将最终结果插入到视图中，存储到磁盘。与视图的不同点是：视图只是一个Sql的链接，它并不存储实际的数据

原以为的使用背景：通过定义好一段聚合逻辑，其会不断的在后台对原始表的数据查询，并将聚合的结果存储到本地

现实测试发现：它并不会对每一条增量数据进行实时计算，而是类似触发器对每批次插入的数据进行汇总，然后增量叠加(注意：是叠加，历史数据它并不会重新计算)、

结果：导致我们取到的数据并不是一次汇总的结果，而是多次汇总的叠加增量值，后续如果要使用数据，还需要对数据再次进行聚合

测试案例链接：https://altinity.com/blog/clickhouse-materialized-views-illuminated-part-1 或 https://blog.csdn.net/vkingnew/article/details/106775064

注意：
（1）删除视图的数据：需要删除 ----→ .inner.表名表
alter table “.inner.track_apm_network_view_local” on cluster report_shards_replicas delete where app_id not in (‘11191’,‘11527’);
（2）物化视图的原始表来源，尽量是避免为分布式表，用本地表

9、Clickhouse 更改列字段类型报错

003
尝试：既然分布式DDL不成功，单独选择一台机器上执行依旧报错：ALTER of key column column_name must be metadata-only
原因：查询clickHouse 的essue，发现clickHouse默认不支持对主键字段类型的更改，故报错
004