我们切换Clickhouse后,硬盘就爆了

Hello,大家好,在我们使用了clickhouse进行数据存储后,多多少少遇到一些棘手的问题,在此记录。

我们使用clickhouse改造后,系统流畅度得到大幅提升,大家有兴趣可以来体验一下效果,Webfunny前端监控和埋点系统

如大家所知,Clickhouse数据有几大优点,很适合处理海量的数据,如:查询效率高、clickhouse号称10亿数据,毫秒级查询返回结果;数据压缩率高、它采用了列式存储,对数据压缩有天然优势,节省硬盘资源;集群化、clickhouse天生支持集群化,同时有分区和分片设计,已经涵盖了我们按天分表的设计;

因此我们义无反顾的采用clickhouse进行了改造,效果确实符合我们要求,但是迎来了第一个问题,硬盘爆了。

咦?不是说存储压缩率高,节省硬盘吗?这还没弄几下,硬盘就爆满了,咋整?今天我们就分三步来告诉大家怎么排查和优化设置。

第一步、对比查找硬盘消耗最多的东西是什么

进入linux服务器,查看总体消耗

硬盘消耗情况查看:df -h

在 Linux 系统中,/dev/vda3 通常是一个设备文件,代表一个磁盘分区,是无法通过cd命令进入的。

所以我们可以进入 cd / 然后执行 du -sh * 命令来查看硬盘占用细节。

经过一番排查,最终确定是clickhouse对硬盘的消耗最大。

第二步、排查数据库内部占用情况

通过对Table size进行排序,可以看出,数据的总量也不过就是在百兆以内,所以肯定不是业务表消耗的。

既然不是业务表,那么就应该是是系统表消耗的,所以我们在clickhouse官网上找到了关于系统表的描述,原文查看

官网描述中,介绍了有哪些系统表,已经他们的创建规则,所以我们对这些系统表进行注意排查,也许是我的数据库版本原因,有些日志表是找不到的

sql整理如下:

sql 复制代码
SELECT count(*) FROM system.query_log

SELECT count(*) FROM system.metric_log

SELECT count(*) FROM system.trace_log

SELECT count(*) FROM system.part_log

经排查,占用最多的是query_log这个系统表,虽然业务数据才几百兆,但是query_log却有几亿条,是大头,其他log也有百万到千万不等。

接着我们对query_log进行了清理,这一步耗时比较长,要耐心等一会,执行sql如下:

sql 复制代码
ALTER TABLE system.query_log DELETE 
WHERE query_start_time < '2024-10-26 00:00:00'

我们先清理的linux系统里的日志文件,然后执行删除sql,可以看到硬盘的消耗明显下降了,由此可以确定硬盘爆满的原因了。

第三步、优化配置和解决方法

clickhouse默认会采集所有的日志备用,但是很多时候我们不会去查看日志,对于不需要的经常去查看这些日志的同学,可以调整配置内容

clickhouse提供了官网配置文档,进入/etc/clickhouse-server/config.xml文件中可以调整各项参数

  • database: database the system log table belongs to. This option is deprecated now. All system log tables are under database system.
  • table: table to insert data.
  • partition_by: specify PARTITION BY expression.
  • ttl: specify table TTL expression. 这里是设置删除周期,它默认是30天,你可以设置为1天或者其他时间。
  • flush_interval_milliseconds: interval of flushing data to disk.
  • engine: provide full engine expression (starting with ENGINE = ) with parameters. This option conflicts with partition_by and ttl. If set together, the server will raise an exception and exit.
  • max_size_rows: 分区最大行数,个人认为,如果有必要可以设置小一点
xml 复制代码
<clickhouse>
    <query_log>
        <database>system</database>
        <table>query_log</table>
        <partition_by>toYYYYMM(event_date)</partition_by>
        <ttl>event_date + INTERVAL 30 DAY DELETE</ttl>
        <!--
        <engine>ENGINE = MergeTree PARTITION BY toYYYYMM(event_date) ORDER BY (event_date, event_time) SETTINGS index_granularity = 1024</engine>
        -->
        <flush_interval_milliseconds>7500</flush_interval_milliseconds>
        <max_size_rows>1048576</max_size_rows>
        <reserved_size_rows>8192</reserved_size_rows>
        <buffer_size_rows_flush_threshold>524288</buffer_size_rows_flush_threshold>
        <flush_on_crash>false</flush_on_crash>
    </query_log>
</clickhouse>

好了,这个就是我们解决clichouse硬盘爆满的整个过程了,希望对你有帮助。

相关推荐
AI 算法大模型备案~当当8 分钟前
各地备案数量怎么看:一份属地公告的认读与台账方法
java·数据库·人工智能
小蜗 strong20 分钟前
和电脑猜拳(随机程序应用)
服务器·前端·python
梦帮科技35 分钟前
量子张量网络破局大模型:从矩阵乘积态 (MPS) 到张量列 (TT-SVD) 低秩收缩全推导
网络·数据结构·数据库·线性代数·矩阵·架构·模拟退火算法
曹牧1 小时前
PL/SQL Developer:导出建表语句
数据库·sql
念念不忘 必有回响1 小时前
MySQL 事务与隔离级别完全指南
数据库·mysql
下家2 小时前
为了脱离前端鄙视链,于是自己写个框架 - React 党看完沉默了
前端·前端框架
zhiyouTech2 小时前
从“被看见“到“被信任“:关于信源评级机制的一点观察
大数据·前端·人工智能
Hashan2 小时前
Vibe Coding 下前后端怎么对接接口?后端不给力的兜底方案
前端·后端·vibecoding
JosieBook2 小时前
【WinForm 代码反脆弱系列】04 数据库操作 —— 连接字符串、连接对象与连接池
数据库·oracle
小蒜学长2 小时前
基于SpringBoot+Vue的小学数学智能出题系统(代码+数据库+LW)
java·数据库·spring boot·后端·智能出题系统