列式数据库管理系统ClickHouse、批量执行sql语句及超长语句及容器日志文件过大问题

本文介绍了列式数据库管理系统ClickHouse,其在大数据分析中的优势,如高性能查询、实时创建表和数据处理。同时,针对ClickHouse在Docker容器中启动失败的问题,重点讲述了如何控制日志大小以防止日志过大引发的问题。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

一、关于列式数据库管理系统 ClickHouse

    ClickHouse是什么?ClickHouse是一个用于联机分析(OLAP)的列式数据库管理系统(DBMS)。由Yandex公司从一个自身开发的专门用于聚合数据的系统Metrage发展而来。 clickHouse以卓越的查询性能著称,目前在大数据的存储和分析领域有广泛应用。

    ClickHouse不单是一个数据库, 它是一个数据库管理系统。因为它允许在运行时创建表和数据库、加载数据和运行查询,而无需重新配置或重启服务。列式数据库是以列相关存储架构进行数据存储的数据库,主要适合于批量数据处理和即时查询。列式数据库把一列中的数据值串在一起存储起来,然后再存储下一列的数据。

    在传统的行式数据库系统中,把一行中的数据值串在一起存储起来,然后再存储下一行的数据。数据存储顺序如下图,处于同一行中的数据总是被物理的存储在一起。常见的行式数据库系统有:MySQL、Postgres和MS SQL Server。

    常见的列式数据库有: Vertica、 Paraccel (Actian Matrix,Amazon Redshift)、 Sybase IQ、 Exasol、 Infobright、 InfiniDB、 MonetDB (VectorWise, Actian Vector)、 LucidDB、 SAP HANA、 Google Dremel、 Google PowerDrill、 Druid、 kdb+。

OLAP联机分析场景的关键特征:

绝大多数是读请求
数据以相当大的批次(> 1000行)更新,而不是单行更新;或者根本没有更新。
已添加到数据库的数据不能修改。
对于读取,从数据库中提取相当多的行,但只提取列的一小部分。
宽表,即每个表包含着大量的列
查询相对较少(通常每台服务器每秒查询数百次或更少)
对于简单查询,允许延迟大约50毫秒
列中的数据相对较小:数字和短字符串(例如,每个URL 60个字节)
处理单个查询时需要高吞吐量(每台服务器每秒可达数十亿行)
事务不是必须的
对数据一致性要求低
每个查询有一个大表。除了他以外,其他的都很小。

查询结果明显小于源数据。换句话说,数据经过过滤或聚合,因此结果适合于单个服务器的RAM中。

    ClickHouse是真正的列式数据库管理系统,数据压缩,数据的磁盘存储,多核心并行处理,多服务器分布式处理,支持SQL,ClickHouse可以在任何具有x86_64,AArch64或PowerPC64LE CPU架构的Linux,FreeBSD或Mac OS X上运行。官方预构建的二进制文件通常针对x86_64进行编译,并利用SSE 4.2指令集,因此,除非另有说明,支持它的CPU使用将成为额外的系统需求。要在不支持SSE 4.2或AArch64,PowerPC64LE架构的处理器上运行ClickHouse,应该通过适当的配置调整从源代码构建ClickHouse。

下面是检查当前CPU是否支持SSE 4.2的命令:

$ grep -q sse4_2 /proc/cpuinfo && echo "SSE 4.2 supported" || echo "SSE 4.2 not supported"

二、批量执行sql语句及超长语句

    ClickHouse批量执行sql语句及超长语句:

#命令行创建数据库
clickhouse-client --query "CREATE DATABASE IF NOT EXISTS tutorial"
#也可以登录之后执行执行
CREATE DATABASE IF NOT EXISTS tutorial

    把创建表的语句写到一个文件中,从ClickHouse教程 | ClickHouse Docs复制到vim文件时,添加set paste可以避免格式混乱。例如写入到了文件create_table_sql.sql中。然后可以通过--queries-file执行越长SQL语句。

#执行创建表的语句
clickhouse-client --user default --password --queries-file create_table_sql.sql路径
#也可以明文显示密码执行创建表的语句
clickhouse-client --user 用户名 --password 密码 -d 数据库 --multiquery < create_table_sql.sql路径

#下载提取官网上中提供的测试表数据
curl https://datasets.clickhouse.tech/hits/tsv/hits_v1.tsv.xz | unxz --threads=`nproc` > hits_v1.tsv
#官网中的大量SQL脚本文件的执行方法
clickhouse-client --user default --password --query "INSERT INTO tutorial.hits_v1 FORMAT TSV" --max_insert_block_size=100000 < hits_v1.tsv

三、Clickhouse启动失败排查发现docker容器日志文件过大问题

    clickhouse启动失败,总是在启动一会之后退出。无法使用.

test@hello: systemctl status clickhouse-server
clickhouse-server.service - ClickHouse Server (analytic DBMS for big data)
Main PID: 4895 (code=exited, status=0/SUCCESS)
test@hello: journalctl -u clickhouse-server
clickhouse-server[986]: Cannot add message to the log: Code: 243, e.displayText() = DB::Exception: Cannot reserve 1.00 MiB, not enough space, Stack t

    也可以到clickhouse的默认日志目录 /var/log/clickhouse-server 中去查看。经过排查看到最上面的日志中有一行:not enough space。然后查看磁盘发现系统盘确实使用了100%了。通过排查发现 /var/lib/docker/containers 下的容器占用空间很大,深入查看日志文件近100G了。当然可以对日志进行清除从而减少占用。但下次依然还会出现这样的问题。

    解决docker容器日志过大的根本还是要控制容器日志大小。在创建容器时就需要控制日志大小。可以使用如下参数实现。

test@hello: docker run -it --log-opt max-size=100m --log-opt max-file=10 clickhouse-server

    最好的方式是修改docker配置文件 /etc/docker/daemon.json,增加配置如下后重启docker并重新创建容器才会生效:

test@hello:# cat /etc/docker/daemon.json
{
    "log-driver":"json-file",
    "log-opts":{
        "max-size" :"100m",
        "max-file":"10"
    }
}
test@hello:# systemctl daemon-reload
test@hello:# systemctl restart docker

    另外就是要排查容器的问题,容器日志过大很可能是容器启动有问题导致容器一直在报错写日志导致的。可以找到日志文件排查。

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

青岛IT音悦人.林戈

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值