GBase 8a 目前版本都是采用一个库一个目录,表是库下面的子目录的方式保存数据,本文提供了一些查看一个库或schema占用磁盘空间方法以供参考。
目录导航
文件系统级估算
直接从文件系统,找到该库所在的目录,计算其占有的空间。该才做仍然会消耗大量的磁盘资源,表越多,列越多,消耗越大。
du -sh 安装目录/gnode/userdata/gbase/库名
影响程度建议在实际环境测试后,再决定是否使用。比如100万个表,预计可能要几分钟到几十分钟的磁盘消耗,换SSD等高速盘会极大改善影响程度。
需要计算每个节点的空间,然后累加后为占用的总空间。 如果各个节点磁盘占用接近,也可以用单个节点统计结果*计算节点数量来估算。
自定义表空间
V95版本支持自定义表空间,并支持配额管理。 详情和注意事项,请参考 GBase 8a V95版本表空间配额使用样例
通过查询元素据表 information_schema.tablespaces ,获得表空间的磁盘占用。
该使用空间,在每次数据有变动是自动修正,无需每次都扫描所有子目录,故性能好。
如下是一个库,配置了2个表空间的例子。将每个节点的每个表空间,累加后就是总空间占用。
gbase> select * from information_schema.tablespaces where db_name='ab';
+-----------+---------+---------------+-----------------+----------------------------+------------+-----------+-----------+-----------+----------+
| NODE_NAME | DB_NAME | TABLESPACE_ID | TABLESPACE_NAME | TABLESPACE_PATH | IS_DEFAULT | MAX_SIZE | USED_SIZE | FREE_SIZE | SEG_SIZE |
+-----------+---------+---------------+-----------------+----------------------------+------------+-----------+-----------+-----------+----------+
| node1 | ab | 1 | sys_tablespace | /opt/gbase/tablespace_100m | yes | 104857600 | 160042004 | 0 | 16777216 |
| node1 | ab | 2 | ts_1 | /opt/gbase/tablespace_1 | no | 52428800 | 80020808 | 0 | 10485760 |
| node2 | ab | 1 | sys_tablespace | /opt/gbase/tablespace_100m | yes | 104857600 | 160042004 | 0 | 16777216 |
| node2 | ab | 2 | ts_1 | /opt/gbase/tablespace_1 | no | 52428800 | 80020808 | 0 | 10485760 |
+-----------+---------+---------------+-----------------+----------------------------+------------+-----------+-----------+-----------+----------+
4 rows in set (Elapsed: 00:00:00.00)
累计每个表的空间
通过元数据,获得每个表占用的空间。 详情和注意事项,请参考 GBase8a 集群查看某张表占用的磁盘空间大小
好处是可以通过SQL获得,且循环调度可以控制;缺点是要扫描每个表,系统消耗大。
总结
如果是V9版本,且要控制一些大表占用的空间,建议用自定义表空间。
其它2个方案,都会占用较大的系统资源,建议在测试影响后再考虑是否使用。 另外建议降低频率,比如每天一次,且选择在对业务影响最小的时间操作,比如凌晨4-5点。