clickhouse集群表删除_clickhouse

最新推荐文章于 2024-05-29 15:37:20 发布

weixin_39639919

最新推荐文章于 2024-05-29 15:37:20 发布

阅读量3.5k

点赞数 2

文章标签： clickhouse集群表删除

本文链接：https://blog.csdn.net/weixin_39639919/article/details/111663314

版权

OLTP:联机事务处理

OLAP:联机分析处理

业内有一个常识性的认知，按顺序存储的数据会拥有更高的查询性能。因为读取顺序文件会用更少的磁盘寻到和旋转延迟时间（这里主要指机械磁盘），同时顺序读取也能利用操作系统层面文件缓存的预读功能，所以数据库的查询性能与数据再物理磁盘上的存储顺序息息相关。

clickhouse是一款MPP架构的列式存储数据库，它拥有完备的管理功能，所以它称得上是一个DBMS，而不仅仅是一个数据库。它具备了如下的基本功能：

DDL：可以动态创建、修改或者删除数据库、表、视图，无需重启服务
DML：可以动态查询、插入、修改或者删除数据。
权限控制：可以按照用户粒度设置数据库或者表的操作权限，保障数据的安全性。
数据备份和恢复：提供了数据备份导出与导入恢复机制，满足生产环境的要求。
分布式管理：提供集群模式，能够自动管理多个数据库节点。

clickhouse在诞生之初是为了服务Yandex自家的web流量分析产品，在存储数据超过20万亿行的情况下，clickhouse做到了90%的查询都能够在1秒内返回的惊人之举。可以说clickhouse具备了人们对一款高性能OLAP数据库的美好向往，它能够基本胜任各种数据分析类的场景，并且随着数据体量的增大，它的优势也会变得越为明显。

clickhouse有如下不足：

不支持事务。
不擅长根据主键按行粒度进行查询（虽然支持），故不应该把clickhouse当做key-value数据库使用。
不擅长按行删除数据（虽然支持）。

列式存储和数据压缩，对于一款高性能数据库来说是必不可少的特性。如果你想让查询变得更快，最简单且有效的方法就是减少数据扫描范围和数据传输时的大小，而列式存储和存储压缩就可以帮助实现上述两点。列式存储和数据压缩通常是伴生的，因为一般来说列式存储是数据压缩的前提。

假设一张表T有50个字段A1~A50，100行数据。现在需要查询前5个字段：

select A1,A2,A3,A4,A5 from T;

如果是按行存储的数据库，数据库首先会逐行扫描，并获取每行数据的所有50个字段，然后再从每一行数据中返回A1~A5这5个字段。按列存储的数据库，直接获取A1~A5这5列数据，避免扫描所有字段。

按列存储相比按行存储的另一个优势是对数据压缩的友好性。假设有两个字符串abcdefghi和bcdefghi，现在对他们进行压缩：

压缩前：abcdefghi_bcdefghi

压缩后：abcdefghi_(9,8)

可以看到，压缩的本质是按照一定步长对数据进行匹配扫描，当发现重复部分的时候就进行编码转换。例如上述示例中的(9,8)表示如果从下划线开始向前移动9个字节，会匹配到8个字节长度的重复项，即bcdefghi。真实的压缩算法比这个示例更为复杂，但压缩的是指就是如此。数据中的重复项越多，压缩率越高，压缩率越高，数据体量越小，在网络中的传输越快，对网络带宽和磁盘IO的压力也就越小。

既然如此，那怎样的数据最有可能具备重复的特性呢？答案是属于同一个列字段的数据，因为他们拥有相同的数据类型和现实语义，重复项的可能性自然就更高。

ClickHouse是一款使用列式存储的数据库，数据按列进行组织，属于同一列的数据会被保存在一起，列与列之间也会由不同的文件分别保存。数据默认使用LZ4算法压缩。列式存储除了降低IO和存储的压力外，还为向量化执行做好了铺垫。

向量化执行，可以简单看作是一箱消除程序中循环的优化。这里做一个比喻：小胡经营了一家果汁店，虽然电力的鲜榨果汁深受大家的喜爱，但客户总是抱怨制作果汁的速度太慢。小胡的电力只有一台榨汁机，每次他都会从篮子里拿出一个苹果，放到榨汁机内等待出汁。若有8个用户，则需要重复上述流程8次，全部制作完需要40分钟。若将榨汁机数量变成8台同时作业，则只需要5分钟。非向量化执行的方式是用1台榨汁机重复玄幻制作n次，而向量化执行的方式是用n台榨汁机只执行一次。

为了实现向量化执行，需要利用CPU的SIMD指令。SIMD的全称是Single Instruction Multiple Data，即单条指令操作多条数据。它是通过数据并行以提高性能的一种实现方式，原理是在CPU寄存器层面实现数据的并行操作。

相比HBase和Redis这类Nosql数据库，Clickhouse使用关系模型描述数据并提供了传统数据库的概念（数据库，表，视图，函数等）与此同时，clickhouse完全使用sql作为查询语言（支持group by、order by、join、in等大部分标准的sql）。

ClickHouse在数据存取方面，既支持分区（纵向扩展，利用多线程原理），也支持分片（横向扩展，利用分布是原理）。在分布式领域，计算移动比数据移动更加划算。可以预先将数据分布到各台服务器，然后将数据的计算查询下推到数据所在的服务器。

HDFS、Spark、HBase和ES的分布式系统，都采用了Master-Slave主从架构，由一个管控节点作为Leader统筹全局。而ClickHouse采用Multi-Master多主架构，集群中的每个节点角色对等，客户端访问任意一个节点都能得到相同的效果。天然规避了单点故障，非常适合多数据中心，异地多活的场景。

数据分片是将数据进行横向切分，ClickHouse支持分片，分片依赖于集群。每个集群有1到多个分片组成，每个分片对应了ClickHouse的一个服务节点，分片的数量上限取决于节点数量。（1个分片只能对应一个服务节点）

ClickHouse并不像其他分布式系统那样，拥有高度自动化的分片功能。ClickHouse提供了本地表与分布式表的概念。一张本地表等同于一份数据的分片。而分布式表本身不存储任何数据，它是本地表的访问代理，其作用类似分库中间件。借助分布式表，能够代理访问多个数据分片，从而实现分布式查询。

Column和Field是ClickHouse数据最基础的映射单元。ClickHouse按列存储数据，内存中的一列数据由一个Column对象表示。如果需要操作单个具体的数值（也就是单列中的一行数据），则需要使用Field对象，Field对象代表一个单值。

数据的序列化和反序列化工作由DataType负责。但它不负责数据的读取，而是转由从Column或Field对象获取。

ClickHouse内部的数据操作是面向Block对象进行的，并且采用了流的形式。虽然Column和Field组成了数据的基本映射单元，但对应到实际的操作，他们还缺少一些必要的信息，比如数据的类型及列的名称。于是ClickHouse设计了Block对象，Block对象可以看做数据表的子集。Block对象的本质是由数据对象、数据类型和列名称组成的三元组。

ClickHouse的集群由分片组成，而每个分片由通过副本组成。ClickHouse的1个节点只能拥有1个分片，也就是说如果要实现1分片、1副本，则至少要部署两个服务节点。分片只是一个逻辑概念，其物理承载还是由副本承担的。

ClickHouse会在内存中进行Group by，并且使用HashTable装载数据。与此同时，他们非常在意CPU L3级别的缓存，因为一次L3的缓存失效会带来70~100ns的延迟。这意味着在单核CPU上，它会浪费4000万次/秒的运算，而在一个32线程的CPU上，则可能会浪费5亿次/秒的运算。因为注意了这些细节，所以ClickHouse在基准查询中能做到1.75亿次/秒的数据扫描性能。

clickhouse服务安装：

安装 | ClickHouse文档clickhouse.tech

Docker Hubhub.docker.com

clickhouse GUI客户端：

推荐dbeaver

clickhouse服务配置：

/etc/clickhouse-server ##服务器端的配置文件目录，包括全局配置文件config.xml和用户配置users.xml等
/var/lib/clickhouse ##默认的数据存储目录（通常会修改默认路径配置，将数据保存到大容量磁盘挂载的路径）
/var/log/clickhouse-server ##默认保存日志的目录（通常会修改默认路径配置，将日志保存到大容量磁盘挂载的路径）

操作系统级别配置：

/etc/security/limits.d/clickhouse.conf ##文件句柄数量的配置。 
# cat /etc/security/limits.d/clickhouse.conf 
clickhouse	soft	nofile	262144 
clickhouse	hard	nofile	262144 
/etc/cron.d/clickhouse-server ##cron定时任务配置，用于恢复因异常原因终端的clickhouse服务进程。 
# cat /etc/cron.d/clickhouse-server #*/10 * * * * root (which service > /dev/null 2>&1 && (service clickhouse-server condstart ||:)) || /etc/init.d/clickhouse-server condstart > /dev/null 2>&1

可以看到，在默认的情况下，每隔10秒就会使用condstart尝试启动一次clickhouse服务，condstart命令启动逻辑如下：

is_running || service_or_func start

启动clickhouse服务：

方式一：该方式会默认读取/etc/clickhouse-server/config.xml配置文件。

systemctl start clickhouse-server

方拾二：指定配置启动。

clickhouse-server --config-file=/etc/clickhouse-server/config-ch5.xml

ClickHouse底层访问接口支持TCP和HTTP两种协议，其中，TCP协议拥有更好地性能，其默认端口为9000，主要用于集群间的内部通信及CLI客户端。而HTTP协议则拥有更好的兼容性，可以通过REST服务的形式被广泛用于JAVA、Python等客户端，默认端口为8123。

clickhouse-client ## 交互式ClickHouse客户端

cat ~/.clickhouse-client-history ##查看通过clickhouse-client执行的sql语句，相关查询结果会统一被记录到~/.clickhouse-client-history文件中，用于审计之用。

## 非交互式执行，用于批量处理场景。执行脚本时，追加--query参数指定执行的sql。下面是数据导入导出
# cat /chbase/test_fetch.tsv | clickhouse-client --query "INSERT INTO test_fetch FORMAT TSV"
# clickhouse-client --query="SELECT * FROM test_fetch" > /chbase/test_fetch.tsv

默认情况下，clickhouse-client一次只能执行一条sql，若需执行多条，需要--multiquery参数。多条sql查询结果按顺序返回。

# clickhouse-client -h 10.37.129.10 --multiquery --query="SELECT 1;SELECT 2;SELECT 3;"

常用参数：

--host/-h：服务端地址，默认值为localhost。如果修改config.xml内listen_host，则需要依靠此参数指定服务端地址
--port：服务端TCP端口，默认值为9000。如果要修改config.xml内tcp_port，则需要此参数指定。
--user/-u：登录的户名，默认值为default。如果使用非default的其他户名登录，则需要此参数指定
--password：登录的密码，默认值为空。
--database/-d：登录的数据库，默认值为default。
--time/-t：在非交互式执行时，会打印每条SQL的执行时间。
--format/-f：使用指定的默认格式输出结果
--stacktrace:如果出现异常，会打印堆栈跟踪信息。
--config-file:指定配置文件名称

内置的实用工具：

clickhouse-local（是非交互式运行的）可以独立运行大部分SQL查询，不需要依赖任何ClickHouse服务端程序，它可以理解成是ClickHouse服务单机版微内核，是一个轻量级的应用层序。clickhouse-local只能够使用File表引擎它的数据与同机运行的ClickHouse服务也是完全隔离的，相互之间并不能访问。

## 实现对系统用户内存用量的查询。
ps aux | tail -n +2 | awk '{ printf("%st%sn", $1, $4) }' | clickhouse-local -S "user String, memory Float64" -q "SELECT user, round(sum(memory), 2) as memoryTotal FROM table GROUP BY user ORDER BY memoryTotal DESC FORMAT Pretty"

clickhouse-local 常用参数：

-S/--structure：表结构的简写方式。

-N/-table：表名称，默认值是table。

--DDL
clickhouse-local -q "CREATE TABLE test_table (id Int64) ENGINE = File(CSV, stdin)"
--使用-S、-N简写 
clickhouse-local -S "id Int64" -N "test_table"

-if/--input-format:输入数据的格式，默认是TSV，例如：

echo -e "1n2n3" | clickhouse-local -S "id Int64" -if "CSV" -N "test_table"

-f/--file:输入数据的地址，默认值是stdin标准输入

-q/--query：待执行的sql，多条语句之间以分号分割。

clickhouse-benchmark是一个基准测试小公举，它可以自动运行sql查询，并生成运行指标报告。

# echo "SELECT * FROM system.numbers LIMIT 100" | clickhouse-benchmark -i 5
Loaded 1 queries.

按指定的参数执行5次该查询，执行完成后，输出包含QPS、RPS等指标报告。

localhost:9000, queries 5, QPS: 1112.974, RPS: 111297.423, MiB/s: 0.849, result RPS: 111297.423, result MiB/s: 0.

还会出具各百分位的查询执行时间

0.000% 0.001 sec.
10.000% 0.001 sec.
20.000% 0.001 sec.
30.000% 0.001 sec.
40.000% 0.001 sec.
50.000% 0.001 sec.
60.000% 0.001 sec.
70.000% 0.001 sec.
80.000% 0.001 sec.
90.000% 0.001 sec.
95.000% 0.001 sec.
99.000% 0.001 sec.
99.900% 0.001 sec.
99.990% 0.001 sec.

最低0.47元/天解锁文章

weixin_39639919

关注

2
点赞
踩
1

收藏

觉得还不错? 一键收藏
0
评论
clickhouse集群表删除_clickhouse

OLTP:联机事务处理OLAP:联机分析处理业内有一个常识性的认知，按顺序存储的数据会拥有更高的查询性能。因为读取顺序文件会用更少的磁盘寻到和旋转延迟时间（这里主要指机械磁盘），同时顺序读取也能利用操作系统层面文件缓存的预读功能，所以数据库的查询性能与数据再物理磁盘上的存储顺序息息相关。clickhouse是一款MPP架构的列式存储数据库，它拥有完备的管理功能，所以它称得上是一个DBMS，而不仅仅...
复制链接

扫一扫