ClickHouse 问题总结（持续更新）

• 1、以时间来分区的日志表，行为表等，建表分区时尽量避免用时间戳，年月日来分区。

  • 原因：因为以这种基数大的属性列分区时，存储数据的时候，磁盘上就会生成N个数据目录，merge会跟不上或者很慢。
  • 解决方案：建议用年月（toYYYYMM）或者年（toYYYY）来当建表时的索引列。

• 2、Too many parts(XXX). Merges are processing significantly slower than inserts.

  • 原因：当发送一个插入请求的时候，涉及了N多个分区的数据，在磁盘上会生成N个数据目录，merge跟不上。
  • 解决方案：①设置分区的时候需要思考清楚，是否会导致插入的时候涉及太多分区。
    ②插入的时候，尽量避免数据中的“分区”列过多。比如一张表建表时是以年月日来分区的，你插入几万数据，但是涉及的年月日有几百个之多，那么插入速度会非常的慢。这个时候就建议你把数据按年月日分成N等份，分批插入较好（如果需要插入的数据一直是这样，那么建议还是以按年月或者按年分区会比较好）。

• 3、查询的过程中clickhouse-server进程老是挂掉。

  • 原因：clickhouse查询一些需要非常大内存的sql时，会被OS kill掉。因为安装时max_memory_usage_for_all_queries的默认值为0，即不限制clickhouse内存使用。
  • 解决方案：clickhouse安装完成以后，在users.xml这个配置文件中配置一下max_memory_usage_for_all_queries，控制
    clickhouse-server的最大占用内存，避免被OS kill掉。

• 4、Memory limit (for query) exceeded:would use 10.01GiB (attempt to allocate chunk of 386,753,325 bytes),
  maximum: 8.00 GiB

  • 原因：max_memory_usage指定单个SQL查询在该机器上面最大内存使用量。也就是说，你执行的这条sql耗费的内存超过了最大的运行值。
  • 解决方案：降低空间复杂度。比如不要select *一个数据量很大的表，limit一下。或者Join的时候小表放在右边，“右表广播”。

• 5、Clickhouse 集群数据丢失,Can’t get data for node /clickhouse/tables/XXX。一看clickhouse的运行日志：Cannot create table from metadata file /var/lib/clickhouse/metadata/xx/xxx.sql, error: Coordination::Exception: Can’t get data for node /clickhouse/tables/xx/cluster_xxx-01/xxxx/metadata: node doesn’t exist (No node), stack trace:

  • 原因：这个是因为是因为zookeeper数据或者挂载目录的数据丢失了，从而使clickhouse数据库无法正常启动。
  • 解决方案：
    • ①备份/var/lib/clickhouse/metadata/ 下的丢失的那个表的SQL，以及/var/lib/clickhouse/data/下对应那张表的数据。如果觉得不保险的话，可以全部都备份。
    • ②将/var/lib/clickhouse/metadata/ 下的丢失的那个表的SQL与/var/lib/clickhouse/data/对应那张表的数据的数据删除。
    • ③启动数据库
    • ④创建与原来表数据结构相同的MergeTree表。
    • ⑤将①备份的数据文件复制到新表的数据目录中。
    • ⑥重启数据库
    • ⑦重新创建原结构本地表
    • ⑧重新创建原结构分布式表
    • ⑨insert into (分布式表) select * from (MergeTree表)

• 6、用驱动包插入数据时遇到错误：com.github.clickhousepower.jdbc.ClickhouseSQLException:DB:Exception: Unexpected packet Data received from client.Stack trace。

  • 原因：可能是由多线程引起的。一个线程中的写操作还没有完成，另一个线程又发起了读写操作。
  • 解决方案：建议插入数据的时候用单线程。大批量，少批次。