共计 13148 个字符,预计需要花费 33 分钟才能阅读完成。
ckman 介绍
ClickHouse
作为 OLAP
场景特地优良的数据库解决方案,写入速度快,查问性能强,尤其是聚合查问能力特地杰出,已在腾讯、哔哩哔哩、快手等公司失去无效实际。与此同时,ClickHouse
在集群部署时配置简单,流程繁琐也困扰着宽广使用者。在此背景之下,ckman
应运而生。
ckman
(ClickHouse Manager
)是由擎创信息科技公司自主研发的一款治理 ClickHouse
的工具,前端用 vue 框架,后端应用 go 语言编写。它次要用来治理 ClickHouse
集群、节点以及数据监控等,致力于服务 ClickHouse
分布式的操作以及治理。同时提供简略的数据查问窗口。
通过网页端的可视化界面,ckman
能够十分便捷的实现集群的导入、部署、节点的增删以及性能指标的监控等性能,能够大大简化集群部署的操作流程,从而起到事倍功半的成果。
现在,这款工具曾经在 github
上开源啦!有想要体验的同学能够移步 https://github.com/housepower…,欢送 star
和奉献代码。
ckman 装置部署
ckman
部署分为 rpm
包装置和 tar.gz
包装置。其实只是提供的安装包不一样,理论装置还是一样的。
rpm 装置
装置
rpm
装置间接应用命令装置即可:
rpm -ivh ckman-1.2.5.x86_64.rpm
装置实现后,在 /etc/ckman
目录下,会生成工作目录(日志和配置文件等都在该目录下)。
启动
rpm
形式装置的 ckman
有两种启动形式:
形式一:
/usr/local/bin/ckman -c=/etc/ckman/conf/ckman.yaml -p=/run/ckman/ckman.pid -l=/var/log/ckman/ckman.log -d
形式二:
systemctl start ckman
tar.gz 包装置
装置
能够在任意目录进行装置。装置形式为间接解压安装包即可。
tar -xzvf ckman-1.5.0-201216-6b03a3a.Linux.x86_64.tar.gz
启动
进入 ckman
的工作目录,执行:
cd ckman
bin/start
启动之后,在浏览器输出 http://localhost:8808 跳出如下界面,阐明启动胜利:
ckman 配置文件
ckman
的配置文件在ckman
的工作目录下的conf/ckman.yml
。
一级选项 | 二级选项 | 默认值 | 阐明 |
---|---|---|---|
server |
id |
1 |
ckman 集群 id ,同一个集群的ckman 的id 号配置必须不同 |
port |
8808 |
ckman 默认的 http 端口 |
|
https |
false |
是否反对https ,默认为不反对 |
|
pprof |
true |
是否反对 pprof 监控,默认反对 |
|
session_timeout |
3600 |
会话超时(token 生效)工夫,默认为 1 个小时 |
|
token |
提供一个 token ,对立门户能够间接通过该token 拜访 ckman 页面 |
||
log |
level |
INFO |
日志级别,默认为INFO |
max_count |
5 |
滚动日志数量 | |
max_size |
10 |
单个日志大小,默认为10M |
|
max_age |
10 |
日志无效生命周期,默认为 10 天 |
|
prometheus |
hosts |
127.0.0.1:19090 |
普罗米修斯监控的 ip 和端口 |
timeout |
10 |
普罗米修斯的超时工夫 | |
nacos |
enabled |
true |
是否开启nacos ,默认为true |
hosts |
127.0.0.1 |
nacos 服务的ip |
|
port |
8848 |
nacos 服务的端口 |
|
user_name |
nacos |
登录 nacos 的用户名 |
|
password |
0192023A7BBD73250516F069DF18B500 |
登录 nacos 的明码 |
|
namespace |
指定 nacos 的namespace ,默认为DEFAULT |
||
group | DEFAULT_GROUP | 向 nacos 注册的服务所处的组 | |
data_id | ckman | 向 nacos 注册的服务名称、数据项名称 |
装置部署 node_exporter 和 prometheus
参考文档:http://www.eryajf.net/2468.html
node_exporter 和 prometheus 不肯定要部署在同一台主机,在 prometheus 的配置文件中指定监控的 node_exporter 即可。
static_configs: - targets: ['localhost:9100']
node_exporter 个别是用来监控零碎性能指标的,因而个别是配置在各个节点上。
prometheus 和 ckman 不肯定要配置在同一台主机,在 ckman 配置文件中指定 prometheus 的地址和端口即可。
prometheus: hosts: - 192.168.21.73:9090
ckman 性能阐明
ckman 反对的接口
接口 | method | 阐明 |
---|---|---|
/api/login |
POST |
登录 |
/api/logout |
PUT |
退出登录 |
/api/v1/ck/cluster |
GET |
获取所有集群信息 |
/api/v1/ck/cluster |
PUT |
更新集群信息 |
/api/v1/ck/cluster |
POST |
导入集群 |
/api/v1/ck/cluster/{clusterName} |
DELETE |
删除集群 |
/api/v1/ck/destroy/{clusterName} |
PUT |
销毁集群 |
/api/v1/ck/get/{clusterName} |
GET |
获取指定集群的信息 |
/api/v1/ck/node/{clusterName} |
POST |
减少节点 |
/api/v1/ck/node/{clusterName} |
DELETE |
删除节点 |
/api/v1/ck/open_sessions/{clusterName} |
GET |
获取无效 session 个数 |
/api/v1/ck/query/{clusterName} |
GET |
执行Query |
/api/v1/ck/rebalance/{clusterName} |
PUT |
Rebanlance 集群数据 |
/api/v1/ck/slow_sessions/{clusterName} |
GET |
获取慢 SQL 查问 |
/api/v1/ck/start/{clusterName} |
PUT |
启动集群 |
/api/v1/ck/stop/{clusterName} |
PUT |
进行集群 |
/api/v1/ck/table/{clusterName} |
GET |
形容表 |
/api/v1/ck/table/{clusterName} |
PUT |
更新表 |
/api/v1/ck/table/{clusterName} |
POST |
创立表 |
/api/v1/ck/table/{clusterName} |
DELETE |
删除表 |
/api/v1/ck/table_metric/{clusterName} |
GET |
获取表集群信息 |
/api/v1/ck/upgrade/{clusterName} |
PUT |
降级集群 |
/api/v1/config |
GET |
获取配置 |
/api/v1/config |
PUT |
批改配置 |
/api/v1/deploy/ck |
POST |
部署ck |
/api/v1/metric/query |
GET |
获取 query 指标 |
/api/v1/metric/query_range |
GET |
获取范畴指标 |
/api/v1/package |
GET |
获取安装包列表 |
/api/v1/package |
POST |
上传安装包 |
/api/v1/package |
DELETE |
删除安装包 |
/api/v1/zk/replicated_table/{clusterName} |
GET |
获取复制表状态 |
/api/v1/zk/status/{clusterName} |
GET |
获取集群状态 |
登录
ckman
默认的登录名为ckman
,明码为 Ckman123456!
登陆胜利后会失去一个 token
,该token
在 1 个小时内无效,token
生效后须要从新登录。
登陆胜利后会进入如下所示的主页:
在主页上,除了有创立集群和导入集群等操作按钮外,还有集群展现的列表。
这个集群列表是通过 ckman
工作目录下 conf/clusters.json
文件导入进来的。次要展现集群名、是否反对正本、节点 ip、节点数量、zk 节点等信息。
重点说下 clusters.json
这个文件。
如下所示,为一个clusters.json
的示例文件。
{
"ck_cluster_config_version": 5, # 配置版本,如果配置了多核心部署,会从 nacos 上同步集群配置,版本号大的会笼罩版本号小的
"test": { #集群名称
"mode": "import", #集群的模式,import 示意是导入的集群,还有 deploy,示意是通过部署的,import 的集群只能查看,不能操作,deploy 的集群能够查看和操作
"hosts": [ #ck 节点 ip 列表
"192.168.101.40",
"192.168.101.41",
"192.168.101.42",
"192.168.101.57"
], #ck 节点的 hostname
"names": [
"vm10140",
"vm10141",
"vm10142",
"zhanglei01"
],
"port": 9000, #ck 节点的端口
"user": "eoi", #ck 用户
"password": "123456", #ck 明码
"database": "default", #拜访的数据库
"cluster": "test", #集群的名字
"zkNodes": [ #zk 的 ip 列表
"192.168.101.40",
"192.168.101.41",
"192.168.101.42"
],
"zkPort": 2181, #zk 的端口
"isReplica": true, #是否反对正本
"version": "20.8.5.45", #ck 版本
"sshUser": "", #ssh 连贯节点主机的用户名,如果是 import 的集群,此处为空"sshPassword":"", #ssh 连贯节点主机的明码
"shards": [ #分片信息,以下示意 2 分片 2 正本
{
"replicas": [ #正本信息
{
"ip": "192.168.101.40",
"hostname": "vm10140"
},
{
"ip": "192.168.101.41",
"hostname": "vm10141"
}
]
},
{
"replicas": [
{
"ip": "192.168.101.42",
"hostname": "vm10142"
},
{
"ip": "192.168.101.57",
"hostname": "zhanglei01"
}
]
}
],
"path": "" #存放数据的门路,如果是 import 的集群,为空
}
}
每次对集群进行操作(减少、删除、批改、rebanlance
等),都会批改 clusters.json
这个文件,相应的 ck_cluster_config_version
都会发生变化。
安装包治理
在主页上点击设置按钮,进入如下的页面:
点击Upload RPMs
,呈现如下界面。
留神安装包上传时须要三个安装包都上传(server
、client
、common
),上传胜利后,在安装包列表下会显示新上传的记录:
留神:如果上传的安装包有缺失(比方少了
common
),安装包依然能上传胜利,但不会显示在列表上。
上传胜利的安装包其实位于 ckman
工作目录的 package
目录下:
点击删除按钮,则会删除掉对应版本的安装包。
此处的安装包次要用来部署 ck
集群、节点部署 ck
以及降级 ck
集群的时候应用。
集群治理
创立集群
点击主页的 Create a ClickHouse Cluster
,就会进入创立集群的界面:
须要填写的项次要有以下:
ClickHouse Version
:ck
的版本,不须要本人填写,通过下拉列表抉择,下拉列表中会列出ckman
服务器中所有的安装包版本。- 此处版本信息只会列出以后 `ckman` 服务下的安装包版本,如果配置了多核心,其余 `ckman` 的安装包是无奈看见的
Cluster Name
:集群的名字,留神不要和已有的名字重合ClickHouse TCP Port
:clickhouse
的TCP
端口,默认是9000
,当然也能够本人指定ClickHouse Node List
:clickhouse
节点列表,以逗号分隔
Replica
:是否开启正本,默认是敞开- 如果开启了正本,默认是 1 个 `shard` 一个正本,所以节点数量肯定要是偶数,否则会报错 - 如果要减少节点的正本数,可通过减少节点实现,创立集群时最多只能指定一个正本 - 如果没有开启正本,则有几个节点就有几个 `shard`
Zookeeper Node List
:zk
列表ZooKeeper Port
:zk
端口,默认是2181
Data path
:ck
节点数据寄存的门路Cluster Username
:ck
的用户名Cluster Password
:ck
的明码
SSH Username
:ssh
登录ck
节点的用户名- 该用户必须具备 `root` 权限或是 `root` 自身,否则部署无奈胜利,个别都是 `root`。
SSH Password
:ssh
登录ck
节点的明码
通过此种形式装置部署胜利的集群的 mode
就是deploy
,能够对其进行删、改、rebanlance
、启停、降级以及节点的增删等操作。
导入集群
点击主页的 Import a ClickHouse Cluster
按钮,会进去导入集群界面。
须要填写的信息如下所示:
Cluster Name
: 节点名称,该名称必须是的确存在的集群名,且不能与ckman
中已有的集群名字反复。
ClickHouse Node IP
:clickhouse
节点ip
列表,以逗号分隔
ClickHouse TCP Port
:ck
节点TCP
端口,默认为9000
Zookeeper Node List
:zk
节点列表
ZooKeeper Port
:zk
端口,默认为2181
Cluster Username
:ck
的用户名
Cluster Password
:ck
的明码
导入集群有个前提是该集群必须的确存在,否则导入会呈现问题。
导入的集群的 mode
为import
,这种模式的集群不能进行批改、rebanlance
、启停、降级以及节点的增删等操作(因为这些操作都须要提供 root
用户权限,然而导入的集群没有提供这些信息),然而能够删除和查看。
治理节点
从首页点击 Go to cluster
, 进入集群的治理界面。
次要有 Overview
、Manage
、Tables
、Session
、Query Execution
、Settings
等选项,点击 Manage
按钮,进入上面的页面:
右上角的操作:Start Cluster
、Stop Cluster
、Destroy Cluster
以及 Rebanlance Cluster
针对的是 deploy
模式的集群,import
的集群均不可操作。
Start Cluster
: 启动集群- `ssh` 到每台 `ck` 节点下启动 `clickhouse` 服务,都胜利才返回胜利
Stop Cluster
- `ssh` 到每台 `ck` 节点下敞开 `clickhouse` 服务,都胜利才返回胜利
Destroy Cluster
- 首先第一步要进行正在运行的 `clickhouse` 服务 - 而后卸载 `clickhouse` 软件 - 删除 `cluster.json` 并同步到 `nacos` - 销毁集群与删除集群的区别:- 销毁集群后集群彻底不存在了 - 删除集群只是删除 `ckman` 中集群治理的入口(`cluster.json`),集群还存在,能够从新导入
Rebanlance Cluster
- 个别状况下,通过 `clickhouse-sinker` 插入的数据基本上是平衡散布在各个节点的。然而如果新增了一个节点,那么新增的节点数据肯定是空的,这时候能够通过 `rebanlance` 工具进行数据搬运 - `rebanlance` 搬运数据是间接将某个分区的数据间接搬运到指标节点,在搬运的过程中如果有查问操作,正在搬运的这部分数据是无奈查到的,因而在进行 `rebanlance` 操作时,请防止查问操作(`rebanlance` 操作工夫很短,个别不会影响业务)
降级集群
如果上传了新版本的安装包,能够从 Upgrade Cluster
下拉列表中抉择新版本,点击 Upgrade
即可进行降级。
减少节点
减少节点须要填写:
New Node IP
: 新节点的IP
Node Shard
: 节点的Shard NUmber
。
- 如果填写的
shard
是曾经存在的,那么减少的节点会作为已存在shard
的一个正本;如果shard
不存在(个别是最大的shard
编号 +1,如果不是就不正确了),就会新减少一个shard
。
减少节点时须要先将集群整体都停掉,而后将新节点的信息减少到 metrika.xml
中,同步给所有的节点,再重启集群。
删除节点
删除节点时须要留神的是:如果某个 shard
原本是有正本的,删除节点后该 shard
正本没有了,要同时更新 replica
的标记,删除节点并不会销毁该节点,只会进行该节点的 clickhouse
服务,并从 cluster.json
中删除掉。
同减少节点一样,删除节点也要先将集群停掉,将删除后的信息更新到 metrika.xml
中,同步给其余所有节点,再重启集群。
监控治理
监控治理须要提前配置好 node_exporter
和prometheus
。
node_exporter
须要配置在 ck
节点上,这样能力监控 ck
的指标。
在 ck
节点装置好 node_exporter
后,再在 prometheus
中配置 node_exporter
的节点信息。
scrape_configs:
# The job name is added as a label `job=<job_name>` to any timeseries scraped from this config.
- job_name: 'prometheus'
# metrics_path defaults to '/metrics'
# scheme defaults to 'http'.
static_configs:
- targets: ['localhost:9090', 'localhost:9100', '192.168.101.40:9100', '192.168.101.41:9100', '192.168.101.42:9100', '192.168.101.57:9100']
集群监控
点击 Overview
就进入到集群监控页面,如下图所示:
ClickHouse Table KPIs
指标 | 阐明 |
---|---|
clickhouse.Query |
针对 Clickhouse 集群的分布式表发动的查问,依照发动时刻的分布图 |
ClickHouse Node KPIs
指标 | 阐明 |
---|---|
cpu usage |
CPU 占用状况 |
memory usage |
内存占用状况 |
disk usage |
硬盘占用状况 |
IOPS |
IO 指标 |
ZooKeeper KPIs
指标 | 阐明 |
---|---|
znode_count |
znode 数 |
leader_uptime |
leader 存活工夫 |
stale_sessions_expired |
过期的会话 |
jvm_gc_collection_seconds_count |
jvm gc 的次数 |
jvm_gc_collection_seconds_sum |
jvm gc 破费的工夫 |
数据加载监控
数据加载监控次要是针对 clickhouse-sinker
,这是一款从kafka
导入数据到 clickhouse
的工具。
点击主页的 Data Loader Management
按钮,就能够进入数据加载治理页面,从此处能够看到 clickhouse-sinker
的一些指标。
指标 | 阐明 |
---|---|
sum by(task)(rate(clickhouse_sinker_consume_msgs_total[1m])) |
clickhouse_sinker 生产 Kafka 音讯的速率(个 / 秒) |
sum by(task) (rate(clickhouse_sinker_flush_msgs_total[1m])) |
clickhouse_sinker 写 ClickHouse 的速率(行 / 秒) |
sum by(task) (clickhouse_sinker_shard_msgs) |
clickhouse_sinker shard buffer 以后蕴含的音讯数目 |
sum by(task) (clickhouse_sinker_ring_msgs) |
clickhouse_sinker ring buffer 以后蕴含的音讯数目 |
sum by(task)(clickhouse_sinker_parsing_pool_backlog) |
clickhouse_sinker 解析协程池以后积压的音讯数目 |
sum by(task) (clickhouse_sinker_writing_pool_backlog) |
clickhouse_sinker 输入协程池以后积压的批数目 |
表治理
表治理次要分为Table Metrics
、Table Replication Status
、以及Zookeeper Status
。
Table Metrics
统计表的一些指标。
Queries Cost
有三个值:
0.5
:过来 7 天 50%SQL 的均匀耗时0.99
:过来 7 天 99%SQL 的均匀耗时max
:过来 7 天 SQL 最大耗时
Table Replication Status
统计复制表的一些状态。
此处会统计每个 shard
下每张表的各正本之间的统计量。
实践上每个 shard
内正本之间各表的统计都应该相等的,如果有不相等,就阐明有节点落后了,这时候落后的节点会标黄。如果某个正本上所有的表都落后,阐明这个正本可能出问题了。
Zookeeper Status
zookeeper
的相干指标查看。
可查看的指标包含:版本,主从状态,均匀提早,近似数据总和大小,znode 数等。
会话治理
Open Sessions
显示以后正在进行的会话。
Slow Sessions
显示 7
天内最慢的 10
条SQL
语句。
蕴含 SQL
的执行工夫、SQL
耗时、SQL
语句、ck
用户、query id
、查问的 IP
以及线程号。
Query 治理
ckman
还提供了简略的 clickhouse
查问的页面。通过该页面能够查问集群中的数据。
留神:
该工具只能查问,不能进行
mutation
的相干操作。该工具次要针对分布式表,本地表也能查,然而如果本地表在集群的其余节点不存在,就会报错。即便表在所有节点都存在,查问进去的数据也是某个节点的数据,因而每次查问进去的数据可能不统一。
Settings
ckman 设置
除了集群可配置之外,ckman
也有一些本人的配置项:
HA Pair Addresses
:多核心部署ckman
的节点列表Prometheus Addresses
: 普罗米修斯配置地址Alert Manager Addresses
:告警治理地址
配置实现后,点击Save & Reboot
,会将这些配置信息从新写入到配置文件,并重启ckman
。
命令行工具
ckman
除了下面的网络端界面以外,还提供了一些命令行工具:
exporter
导出指定工夫范畴的数据到HDFS
。
如:
exporter --ch-hosts=192.168.101.40,192.168.101.42 --ch-user=eoi --ch-password=123456 --ch-tables=dbtest,tbtesttype --hdfs-addr=localhost:50070 --hdfs-dir=/data
参数阐明:
v
- 查看版本号
ch-hosts
- clickhouse 节点列表(每 shard 仅列出一个)
ch-port
- clickhouse tcp 端口号,默认 9000
ch-user
- clickhouse 用户
ch-password
- clickhouse 明码
ch-database
- clickhouse 数据库,默认 default
ch-tables
- 表名列表
dt-begin
- 开始工夫,默认 1970-01-01
dt-end
- 完结工夫
max-file-size
- 文件最大大小限度,默认 10G
hdfs-addr
- hdfs 的 ip:port
hdfs-user
- hdfs 的用户
hdfs-dir
- hdfs 的文件门路
purger
删除指定工夫范畴的数据。间接drop
分区数据。
如:
purger --ch-hosts=192.168.101.40,192.168.101.42 --ch-port=9000 --ch-user=eoi --ch_password=123456 --ch-database=default --ch-tables=dbtest --dt-begin=2021-02-01 --dt-end=2021-02-28
参数阐明:
v
- 查看版本号
ch-hosts
- clickhouse 节点列表(每 shard 仅列出一个)
ch-port
- clickhouse tcp 端口号,默认 9000
ch-user
- clickhouse 用户
ch-password
- clickhouse 明码
ch-database
- clickhouse 数据库,默认 default
ch-tables
- 表名列表
dt-begin
- 开始工夫,默认 1970-01-01
dt-end
- 完结工夫
schemer
在指定结点创立与另一指定结点雷同的表格。
通过该工具,会在指标节点上创立于源节点除 system 数据库以外的所有数据库和表。如:
schemer --src-host=192.168.101.40 --dst-host=192.168.21.73 --ch-port=9000 --ch-user=eoi --ch-password=123456
参数阐明:
v
- 显示版本信息
src-host
- 源节点
dst-host
- 指标节点
ch-port
- tcp 端口号,默认 9000
ch-user
- 指标节点 ck 用户
ch-password
- 指标节点 ck 明码
rebanlancer
集群结点间负载平衡。
此处的平衡操作间接是物理搬运,先通过一套平衡规定计算出须要从哪些节点移除,增加到哪些节点,而后将源节点的分区 detach
掉,而后通过 ssh
将分区数据传输给指标节点,attach
到指标节点上,并删除掉源节点的分区数据。
ckman
的 rebanlance
也是应用此工具实现的负载平衡。在搬运某表数据期间,针对该表的查问将可能失去不统一的后果。
参数阐明:
v
- 显示版本信息
ch-hosts
- ck 节点列表
ch-port
- ck 节点 tcp 端口,默认 9000
ch-user
- ck 用户名
ch-password
- ck 明码
ch-database
- ck 数据库,默认 default
ch-data-dir
- 数据寄存目录
os-user
- 节点主机用户名(须要有 root 权限)
os-password
- 节点主机明码
扩大 API
除了 ckman
页面上展现的性能外,ckman
还提供了一些扩大的 API,用户可应用 cURL
或Postman
等工具对这些 API
进行操作,从而实现一些扩大性能。
这些 API
次要有:
形容表
METHOD:GET
URL:/api/v1/ck/table/{clusterName}
调用 DESCRIBE TABLE database.table
语句进行查看表的构造信息。应用 tableName
指定表名,database
指定数据库名。
举例如下:
GET http://192.168.31.55:8808/api/v1/ck/table/test?tableName=tbtest&database=default
返回后果:
{
"code": 200,
"msg": "ok",
"data": [
{
"name": "service",
"type": "String",
"defaultType": "","defaultExpression":"",
"comment": "","codecExpression":"",
"ttlExpression": ""
},
{
"name": "ip",
"type": "String",
"defaultType": "","defaultExpression":"",
"comment": "","codecExpression":"",
"ttlExpression": ""
},
{
"name": "metric",
"type": "String",
"defaultType": "","defaultExpression":"",
"comment": "","codecExpression":"",
"ttlExpression": ""
},
{
"name": "value",
"type": "Int64",
"defaultType": "","defaultExpression":"",
"comment": "","codecExpression":"",
"ttlExpression": ""
},
{
"name": "timestamp",
"type": "DateTime",
"defaultType": "","defaultExpression":"",
"comment": "","codecExpression":"",
"ttlExpression": ""
}
]
}
留神:本操作要求表在集群的各节点存在,包含本地表和 dist_结尾的分布式表。
更新表
METHOD: PUT
URL: /api/v1/ck/table/{clusterName}
应用 ALTER
语句实现分布式表的更新。
反对的操作包含减少列、批改列、删除列。
批改实现后须要删除分布式表并重建。
举例如下:
PUT /api/v1/ck/table/test
{
"name":"t1", #表名
"database":"default", #数据库名
"add":[{
"name":"fieldNew", #在 field3 后减少一个 fieldNew,类型为 String
"type":"String",
"after":"field3"
},
{
"name":"filedLast", #在最初减少一个字段 fieldLast,类型为 Int32
"type":"Int32"
}],
"modify":[{
"name":"field6", #将 filed6 批改为 DateTime 类型
"type":"DateTime"
}],
"drop": ["field8", "field9"] #删除 field8,field9
}
留神:该操作只能针对集群中各节点的本地表,且表在各个节点存在。对 dist_结尾的分布式表无奈操作。
创立表
METHOD: POST
URL: /api/v1/ck/table/{clusterName}
创立表默认应用的是 MergeTree
引擎,如果指定了 distinct
为false
,示意反对去重,应用的引擎为ReplacingMergeTree
。
POST /api/v1/ck/table/test
{
"name": "t1", #要创立的表名
"database": "default", #数据库
"fields":[{ #字段信息
"name":"id",
"type":"Int32"
},{
"name":"birth",
"type":"Date"
},{
"name":"name",
"type":"String"
}],
"order": ["id"], #order by 的字段, 能够指定多个
"partition":"toMMMMYY(birth)", #partition by 的字段
"distinct": true
}
当然,最终的引擎还是要依据集群是否反对副原本决定,一共有以下几种状况:
distinct | isReplica | engine |
---|---|---|
true |
true |
ReplicatedReplacingMergeTree |
true |
false |
ReplacingMergeTree |
false |
true |
ReplicatedMergeTree |
false |
false |
MergeTree |
与此同时,还须要在集群里创立一张 dist_
结尾的分布式表。
删除表
METHOD: DELETE
URL: /api/v1/ck/table/{clusterName}
操作和形容表相似,通过 tableName
指定表名,database
指定数据库名。
举例如下:
DELETE http://192.168.31.55:8808/api/v1/ck/table/test?tableName=t1&database=default
通过以上操作就能删除掉表 t1
。删除时先删dist_
结尾的分布式表,再删表t1
。
留神:表必须在集群的各个节点存在且不能是 dist_结尾的分布式表。如果该本地表尽管在集群中各节点存在,但没有依据该本地表创立过分布式表,删除仍然会报错。这一点须要留神。
结语
千里之行,始于足下。ckman
的性能目前还只是初版,必定还存着着诸多有余和能够改良的中央,心愿大家多提意见,独特晋升 ckman
的应用体验。