关于数据库:ADBPGGreenplum成本优化之磁盘水位管理

简介：本文咱们将通过一个理论的磁盘空间优化案例来阐明，如何帮忙客户做老本优化。

作者 | 玉翮
起源 | 阿里技术公众号

目前，企业的外围数据个别都以二维表的形式存储在数据库中。在核心技术自主可控的大环境下，政企行业客户都在纷纷尝试应用国产数据库或开源数据库，尤其在数据仓库 OLAP 畛域的步调更快，Greenplum 的利用越来越宽泛，阿里云 ADB PG 的市场机会也越来越多。另外，随着近年来数据中台的价值被宽泛认可，企业建设数据中台的需要也十分迫切，数据中台的很多场景都会用到 Greenplum 或 ADB PG。因而，往年阿里云应用 ADB PG 帮忙很多客户降级了外围数仓。咱们发现，客户往往比拟关注应用云原生数仓的老本。到底如何帮忙客户节约老本，便值得咱们去摸索和落地。

ADB PG 全称云原生数据仓库 AnalyticDB PostgreSQL 版，它是一款大规模并行处理（MPP）架构的数据库，是阿里云基于开源 Greenplum 优化后的云原生数据仓库，因而本文探讨的老本优化办法也实用于 Greenplum 开源版。图 1 是 ADB PG 的架构示意图（Greenplum 亦如此），Master 负责承受连贯申请，SQL 解析、优化、事务等解决，并散发工作到 Segment 执行；并协调每一个 Segment 返回的后果以及把最终后果出现给客户端程序。Segment 是一个独立的 PostgreSQL 数据库，负责业务数据的存储和计算，每个 Segment 位于不同的独立物理机上，存储业务数据的不同局部，多个 Segment 组成计算集群；集群反对横向扩大。从架构上很分明，节约 Greenplum 的老本，最重要的是要尽可能节约 Segment 的服务器数，但既要保障整体 MPP 的算力，也要能满足数据对存储空间的需要。通常，数据仓库中的数据是从企业各个领域的上游生产零碎同步而来，这些数据在剖析畛域有生命周期，很多数据须要反馈历史变动，因而数据仓库中数据的特点是起源多、历史数据多、数据量比拟大。数据量大，必然耗费存储空间，在 MPP 架构下就是耗费服务器老本。帮客户优化老本，节约存储空间是首当其冲的。

图 1：ADB PG 的架构示意图

上面，咱们将通过一个理论的磁盘空间优化案例来阐明，如何帮忙客户做老本优化。

ADB PG 是基于 Greenplum（简称“GP”）内核批改的 MPP 数据库，对于磁盘空间治理来讲，有几个技术点与 Greenplum 是通用的：

（1）业务数据次要散布在 Segment 节点；

（2）Segment 有 Primary 和 Mirror 节点，因而，业务可用空间是服务器总空间的 1 /2；

（3）Greenplum 的 MVCC 机制，导致表数据产生 DML 后产生垃圾数据 dead tuples；

（4）复制表（全散布表）会在每个 Segment 上存储雷同的数据拷贝；散布表会依据散布键打散存储数据到各个 Segment。

（5）Greenplum 有 Append Only 类型的表，反对压缩存储，能够节约空间；当然用户拜访时，解压缩须要工夫，所以须要在性能和空间之间获得均衡。

云原生数据库的特点是不再独自提供数据库存储和计算的内核，也会配套运维治理平台，简称“数据库管控”。搞清楚 ADB PG 磁盘治理原理后，咱们须要理解数据库管控在磁盘水位治理方面的设计。

咱们看下某数仓试验环境的各个 Segment 节点的磁盘占用示意图。

图 2：Segment 维度的磁盘占用示意图

上图第一个百分比是 Segment 所在物理机的磁盘应用百分比；第二个百分比是数据库管控的磁盘应用百分比。管控的数据为啥要跟服务器理论占用不统一呢？其实就是水位治理中第一个很重要的预防性措施：空间预留。即，ADB 的管控在创立 Segment 实例时，依据服务器的空间，进行了肯定的预留，占比大略是 12%，即 20T 的服务器，管控认为业务最大可用 17.6T，这个逻辑会告诉监控零碎。所以计算磁盘占比时，监控零碎的分母不是 20T，而是 17.6T。这是第一级保护措施。

预留空间，还有重要的一点起因是数据库自身有 WAL 事务日志、谬误日志等也占用空间。因而，磁盘的空间有一部分须要给日志应用，客户的业务数据无奈应用 100% 的服务器空间，这就是为何图 2 中，会显示两个空间百分比的起因。

第二级保护措施是“磁盘满锁定写”。在 17.6T 的根底上，管控并不让业务齐全写满，写满容易造成数据文件损坏，带来数据库宕机及无奈复原的劫难。因而，这里有第二个阈值，即当磁盘写到 90% 时，数据库管控的主动巡检工作会启动“锁定写”的操作，此时所有申请 ADB 的 DML 都会失败。这是一个重要的爱护机制。如下图 3 所示，如果达到阈值，会提醒“need to lock”。阈值能够配置，如果磁盘空间缓和，能够依据理论状况适当调大阈值。

图 3：数据库管控的自动化锁盘日志示例

以上数据库管控的两个机制能够无效保障磁盘在平安水位下运行。这些设计，是咱们做老本优化的根底，磁盘的老本优化意味着服务器的磁盘尽可能物尽其用。节约磁盘空间，就必须要在绝对较高的磁盘水位运行（这里是指数据量的确很大的状况），因而，磁盘无效治理，及时的问题监控发现的机制十分重要。

上面咱们以某客户的案例来阐明磁盘空间优化办法。该客户数据仓库中的数据（含索引）大于 1.5PB，但客户一期为 ADB 数仓洽购了 40 台机器，约 800T 总容量。客户明确要求阿里云须要配合业务方做好数仓设计，帮其节约老本。客户把老本优化的 KPI 曾经定好了，须要阿里云通过技术去落实。咱们协同业务方在设计阶段做了一些预案，技术上次要从表压缩和冷热数据拆散的角度去做思考；业务上，让开发商从设计上，尽量缩减在 ADB 中的存量数据。最终，开发商预估大略有 360T 左右的热数据从旧的数仓迁徙到 ADB。上线前，开发商须要把必要的根底业务数据（比方贴源层，中间层），从 DB2 迁徙到 ADB PG。迁徙实现，业务进行试运行期，咱们发现空间简直占满（如图 2）。空间优化火烧眉毛，于是咱们发动了磁盘空间优化治理。图 4 是磁盘空间治理优化的框架。

图 4：磁盘水位优化框架

接下来，咱们开展做一下阐明。

表的压缩存储能够无效保障客户节约存储空间。Greenplum 反对行存、Append-only 行存、Append-only 列存等存储格局。若心愿节约存储空间，Append-only 列存表是较好的抉择，它较好的反对数据压缩，能够在建表时指定压缩算法和压缩级别。适合的压缩算法和级别，能够节约数倍存储空间。建示意例语句如下：

CREATE TABLE bar (id integer, name text)
    WITH(appendonly=true, orientation=column, COMPRESSTYPE=zstd, COMPRESSLEVEL=5)
    DISTRIBUTED BY (id);

列存表必须是 Append-only 类型，创立列存表时，用户能够通过指定 COMPRESSTYPE 字段来指定压缩的类型，如不指定则数据不会进行压缩。目前反对三种压缩类型：

zstd、zlib 和 lz4，zstd 算法在压缩速度、解压缩度和压缩率三个维度上比拟平衡，实际上举荐优先思考采纳 zstd 算法。zlib 算法次要是为了兼容一些已有的数据，个别新建的表不采纳 zlib 算法。lz4 算法的压缩速度和压缩率不如 zstd，然而解压速度显著优于 zstd 算法，因而对于查问性能要求严格的场景，举荐采纳 lz4 算法。

用户能够通过指定 COMPRESSLEVEL 字段来决定压缩等级，数值越大压缩率越高，取值范畴为 1 -19，具体压缩等级并不是数字越大越好，如上文所述，解压缩也耗费工夫，压缩率高，则解压缩会绝对更慢。因而，须要依据业务理论测试来选定，个别 5 - 9 都是有理论生产实践的压缩级别。

在大型企业的数据仓库设计中，MPP 数据库（ADB 属于 MPP）只是其中一种数据存储，而且是偏批处理、联机查问、adHoc 查问的场景应用较多；还有很多冷数据、归档数据，其实个别都会布局相似 Hadoop、MaxCompute 甚至 OSS 进行存储；另外，近年来衰亡的流数据的计算和存储，需要也十分强烈，能够通过 Kafka、Blink、Storm 来解决。因而，当 MPP 数据库空间告急时，咱们也能够做冷热数据分级存储的计划。ADB PG 的分级存储计划，大抵有两种：1 是业务方本人治理冷数据和热数据；2 是利用 ADB PG 冷热数据分层存储和转换性能。

业务方通过 PXF 表面拜访 HDFS 冷数据

业务方把局部冷数据以文件的形式存到 HDFS 或 Hive，能够在 ADB 创立 PXF 内部表进行拜访；内部表不占用 ADB PG 的磁盘空间。PXF 作为 Greenplum 与 Hadoop 集群数据交互的并行通道框架，在 Greenplum 中通过 PXF 能够并行加载和卸载 Hadoop 平台数据。具体应用办法如下：

（1）控制台开明 PXF 服务

· 登录 ADB 管控台，拜访 ADB PG 实例内部表页面，点击开明新服务

图 5：PXF 表面服务

填写具体的 Hadoop 的服务信息后（波及 kerberos 认证，非此文重点），PXF 服务会启动，启动胜利后如上图。

（2）创立 PXF 扩大

`– 管理员执行

create extension pxf_fdw;`

（3）创立 PXF 表面

CREATE EXTERNAL TABLE pxf_hdfs_textsimple(location text, month text, num_orders int, total_sales float8)

LOCATION ('pxf://data/pxf_examples/pxf_hdfs_simple.txt?PROFILE=hdfs:text&SERVER=23')

FORMAT 'TEXT' (delimiter=E',');

阐明：Location 是 hdfs 源文件信息，/data/pxf_examples/pxf_hdfs_simple.txt，即业务拜访的内部冷数据文件；SERVER=23 指明了 Hadoop 表面的地址信息，其中 23 是集群地址信息的寄存目录，在图 8 中能够依据 PXF 服务查到。

（4）拜访内部表

拜访内部表就和拜访一般表没有区别

图 6：内部表拜访示例

ADB PG 冷热数据分层存储计划

下面的 pxf 表面拜访，有一个弊病，是如果冷数据（表面）要和热数据 join，效率较差，起因是数据要从 HDFS 加载到 ADB，再和 ADB 的表进行 Join，徒增大量 IO。因而，ADB PG 在 Greenplum 的 PXF 表面的根底上，提供了冷热数据转换的性能，业务方能够在须要 Join 表面和一般表剖析时，把内部表先转换为 ADB 的一般表数据，再做业务查问，整体计划称为冷热数据分层存储。因为都是利用 PXF 表面服务，3.4.1 中的第 1 和第 2 步骤能够复用。额定的配置办法如下：

(1) 配置分层存储默认应用方才的 Foreign Server

用超级管理员执行

ALTER DATABASE postgres SET RDS_DEF_OPT_COLD_STORAGE TO 'server"23",resource"/cold_data", format"text",delimiter","';

留神，这里须要将 postgres 替换为理论的数据库名，并将 /cold_data 替换为理论在 HDFS 上须要用来存储冷数据的门路。

(2) 重启数据库实例后执行查看

SHOW RDS_DEF_OPT_COLD_STORAGE;
验证是否配置胜利。

(3) 创立测试表，并插入大量测试数据

create table t1(a serial) distributed by (a);

insert into t1 select nextval('t1_a_seq') from generate_series(1,100);

postgres=# select sum(a) from t1;

sum

------

5050

(1 row)

此时，t1 表的数据是存在 ADB 的本地存储中的，属于热数据。

(4) 将表数据迁徙到冷存 HDFS

alter table t1 set (storagepolicy=cold);

图 7：转换数据为冷数据

留神这个 NOTICE 在以后版本中是失常的，因为在冷存上是不存在所谓散布信息的，或者说散布信息是内部存储（HDFS）决定。

（5）验证冷数据表的应用

首先，通过查看表的定义，验证表曾经迁徙到冷存

图 8：冷存表的定义

而后失常查问表数据；

postgres=# select sum(a) from t1;

sum

------

5050

(1 row)

（6）将数据迁回热存

alter table t1 set (storagepolicy=hot);

图 9：数据迁回热存

留神：迁徙回热存后，distributed 信息失落了，这是以后版本的限度。如果表有索引，则索引在迁徙后会失落，须要补建索引。以上两个计划，都能肯定水平上把冷数据从 ADB PG 中迁徙到内部存储，节约 ADB PG 的空间。

计划 1，Join 效率低，不反对冷热数据转换，但不再占用 ADB 的空间；

计划 2，Join 效率高，反对冷热数据转换，局部工夫须要占用 ADB 的空间。

两个计划各有利弊，实际上我的项目中，依据业务利用来定。在该客户案例中，冷热数据分层存储计划，为整体 ADB 节约了数百 T 空间，这数百 T 空间中，大部分是设计阶段解决的，少部分是试运行期间进一步优化的。

因为 GP 内核的 MVCC 管理机制，一个表的 DML（t2 时刻）提交后的数据元组，实际上并没有立刻删除，而是始终与该表的失常元组存储在一起，被标记为 dead tuples；这会导致表收缩而占用额定空间。垃圾数据回收有两个办法：内核主动清理、SQL 手动清理。主动清理的机制是：表的 dead tuples 累积到肯定百分比，且所有查问该表的事务（t1 时刻 <t2 时刻）都曾经完结，内核会主动 auto vacuum 垃圾数据。这个机制，自身没有问题，然而在大库和大表场景下有肯定问题，一个大表上 T，数据变动 10G 才 1%，多个大表一起变动，就会累计给整体空间带来问题，因而必须辅以手动回收。

手动回收办法

（1）统计出零碎的 top 大表；

select *,pg_size_pretty(size) from 

(select oid,relname,pg_relation_size(oid) as size from pg_class where  relkind = 'r' order by 3 desc limit 100)t;

  -- limit 100 示意 top100

（2）查问大表的 dead tuple 占比和空间；

— 依据统计信息查问膨胀率大于 20% 的表

SELECT ((btdrelpages/btdexppages)-1)*100||'%', b.relname  FROM gp_toolkit.gp_bloat_expected_pages a  

join  pg_class b on  a.btdrelid=b.oid  

where btdrelpages/btdexppages>1.2;

（3）应用 pg_cron 定时工作帮忙业务回收垃圾数据

vacuum tablename;

或

vacuum analyze tablename;-- 先执行一个 VACUUM 而后是给每个选定的表执行一个 ANALYZE

或

vacuum full tablename;

这里须要与业务沟通分明执行工夫，具体 vacuum 时，尽管不影响读写，但还是有额定的 IO 耗费。vacuum full tablename 要谨慎应用，两者的区别要重点阐明一下：简略的 VACUUM(没有 FULL)只是回收表的空间并且令原表能够再次应用。这种模式的命令和表的一般读写能够并发操作，因为没有申请排他锁。然而，额定的空间并不返回给操作系统；仅放弃在雷同的表中可用。VACUUM FULL 将表的全部内容重写到一个没有任何垃圾数据的新文件中（占用新的磁盘空间，而后删除旧表的文件开释空间），相当于把未应用的空间返回到操作系统中。这种模式要慢许多并且在解决的时候须要在表上施加一个排它锁。因而影响业务应用该表。

（4）vacuum 退出业务代码的失当环节进行回收

如果某些表，更新频繁，每日都会收缩，则能够退出到业务的代码中进行 vacuum，在每次做完频繁 DML 变更后，立刻回收垃圾数据。

零碎表也须要回收

这是一个极其容易漠视的点。特地是在某些数据仓库须要频繁建表、改表（长期表也算）的场景下，很多存储元数据的零碎表也存在收缩的状况，而且膨胀率跟 DDL 频繁度正相干。某客户呈现过 pg_attribute 收缩到几百 GB，pg_class 收缩到 20 倍的状况。以下表，是依据理论总结进去比拟容易收缩的 pg 零碎表。

pg_attribute -- 存储表字段详情

pg_attribute_encoding -- 表字段的扩大信息

pg_class -- 存储 pg 的所有对象

pg_statistic  -- 存储 pg 的数据库内容的统计数

图 10：pg_class 膨胀率示例

手动 Vacuum 的限度

手动做 vacuum 有肯定的限度，也要留神。

（1）不要在 IO 使用率高的期间执行 vacuum；

（2）vacuum full 须要额定的磁盘空间能力实现。

如果磁盘水位高，残余空间少，可能不够 vacuum full 大表；能够采取先删除一些历史表，腾出磁盘空间，再 vacuum full 指标 table。

（3）必须先完结指标 table 上的大事务

有一次例行大表保护时，一个表做了一次 vacuum，收缩的空间并没有回收，认真一查 pg_stat_activity，发现这个表上有一个大事务（启动工夫比手动 vacuum 启动更早）还没完结，这个时候，内核认为旧的数据还可能被应用，因而还不能回收，手动也不能。

4 冗余索引清理

索引自身也占用空间，尤其大表的索引。索引是数据库进步查问效率比拟罕用又根底的形式，用好索引不等于尽可能多的创立索引，尤其在大库的大表上。空间缓和，能够试着查一下是否有冗余索引能够清理。

排查思路

（1）是否有蕴含“异样多”字段的复合索引；

（2）是否有存在前缀字段雷同的多个复合索引；

（3）是否存在优化器从来不走的索引。

排查办法与例子

首先，咱们从第 1 个思路开始，查问索引蕴含字段大于等于 4 个列的表。SQL 如下：

with t as (select indrelid, indkey,count(distinct unnest_idx) as unnest_idx_count 

       from pg_catalog.pg_index, unnest(indkey) as unnest_idx group by 1,2 

having count(distinct unnest_idx)>=4 order by 3 desc)

select relname tablename,t.unnest_idx_count idx_cnt from pg_class c ,t where c.oid=t.indrelid;

某个客户，就建了很多 10 个字段以上的复合索引，如下图所示：

图 11：按索引列数排序的复合索引

个别超过 6 个字段的复合索引，在生产上都很少见，因而咱们初步判断是建表时，业务方创立了冗余的索引；接下来，能够依照索引的大小排序后输入冗余索引列表。SQL 如下：

with t as (select indrelid,indexrelid, indkey,count(distinct unnest_idx) as unnest_idx_count 

from pg_catalog.pg_index, unnest(indkey) as unnest_idx group by 1,2,3 

having count(distinct unnest_idx)>=3 order by 3 desc

)

select relname tablename,(pg_relation_size(indexrelid))/1024/1024/1024 indexsize,

t.unnest_idx_count idx_cnt from pg_class c ,t where c.oid=t.indrelid order by 2 desc;

图 12：按大小排序的复合索引

这里，咱们很分明发现，局部索引的大小都在 500G 以上，有 10 多个索引的 size 超过 1TB，看到这些信息时，咱们震惊又开心，开心的是应该能够回收很多空间。接下来，须要跟业务方去沟通，通过业务方确认不须要再删除。

在这个客户案例中，咱们删除了 200 多个冗余索引，大小达 24T，间接开释了 7% 的业务空间！十分可观的空间优化成果。这次优化也十分及时，我记得优化在 11 月底实现；接着正好 12 月初顶峰降临，业务方又写入了 20TB 新数据，如果没有这次索引优化，毫不夸大：12 月初该客户的 ADB 集群撑不住了！

第（2）个思路（是否有存在前缀字段雷同的多个复合索引），排查 SQL 如下。最好把索引及蕴含的字段元数据导出到其余 GP 库去剖析，因为波及到索引数据的剖析比照（波及向量转字符数组，以及子集与超集的计算），比拟耗费性能；

select idx1.indrelid::regclass,idx1.indexrelid::regclass, string_to_array(idx1.indkey::text, '') as multi_index1,string_to_array(idx2.indkey::text,' ') as multi_index2,idx2.indexrelid::regclass 

from pg_index idx1 , pg_index idx2  where idx1.indrelid= idx2.indrelid 

and idx1.indexrelid!=idx2.indexrelid and idx1.indnatts > 1

and string_to_array(idx1.indkey::text, '') <@ string_to_array(idx2.indkey::text,' ');

以下是排查例子 user_t 上复合第 2 个问题的索引，如下：

以下是查问后果

以上例子后果解释：multi_index1 是 multi_index2 的子集，前者的索引列曾经在后者中做了索引，因而，multi_index1 属于冗余索引。

第（3）个思路：是否存在优化器从来不走的索引，排查的 SQL 如下：

SELECT

    PSUI.indexrelid::regclass AS IndexName

    ,PSUI.relid::regclass AS TableName

FROM pg_stat_user_indexes AS PSUI    

JOIN pg_index AS PI 

    ON PSUI.IndexRelid = PI.IndexRelid

WHERE PSUI.idx_scan = 0 

    AND PI.indisunique IS FALSE;

上面以一个测试表，讲述排查例子

执行 SQL 能够查到 idx_scan= 0 的索引 idx_b

另外，有一个很重要的知识点，Append-Only 列存表上的索引扫描只反对 bitmap scan 形式，如果 Greenplum 敞开了 bitmap scan 的索引扫描形式，那么所有 AO 列存表的拜访都会全表扫描，即实践上 AO 列存表上的所有非惟一索引都无奈应用，能够全副 drop 掉。当然，这个操作危险很高，要求整个 database 里应用 AO 列存表的业务简直都只做批处理，不存在点查或范畴查找的业务。综上，删除冗余索引，能够帮忙客户节约磁盘空间。

家喻户晓，ADB PG 的表散布策略有 DISTRIBUTED BY（哈希散布），DISTRIBUTED RANDOMLY（随机散布），或 DISTRIBUTED REPLICATED（全散布或复制表）。前两种的表会依据指定的散布键，把数据依照 hash 算法，打散散布到各个 Segment 上；复制表，则会在每个 Segment 上寄存残缺的数据拷贝。复制表散布策略 (DISTRIBUTED REPLICATED) 应该在小表上应用。将大表数据复制到每个节点上无论在存储还是保护上都是有很高代价的。查问全散布表的 SQL 如下：

select n.nspname AS "schemaname",c.relname AS "tablename",case when p.policytype='p' then 'parted' when p.policytype='r' then 'replicated' else 'normal' end  as "distrb_type", pg_size_pretty(pg_relation_size(c.oid))

from pg_class c

left join gp_distribution_policy p on c.oid=p.localoid

left join pg_namespace n on c.relnamespace=n.oid

where n.nspname='public'

and c.relkind='r'

and p.policytype='r'

order by 4 desc;

查问后果如下图，找到了大略 10TB 的全散布表，前 3 个表较大能够批改为哈希散布表，大略能够节约 7T 空间。

图 13：业务库中的复制表

咱们晓得，Greenplum 的默认表空间有两个

如果建表不指定表空间，默认会放到 pg_default 表空间，蕴含堆表、AO 表、列存表、长期表等。具体到 Segment 的文件目录，则是每个 Segment 服务器上的~/data/Segment/${Segment_id}/base/${database_oid}目录下。同时，Greenplum 在多种场景都会产生长期表，如：

（1）sql 中 order by、group by 等操作；

（2）GP 引擎因为数据读取或 shuffle 的须要，创立的长期表；

（3）业务方在 ETL 工作中创立的长期表。

这样存在一个问题，就是业务运行产生的长期表也会占用空间，但这部分不是业务表的数据占用，不不便准确治理大库的磁盘空间；因而咱们把长期表的表空间独立进去，在服务器文件层面也独立进去，不便与业务数据进行别离精细化治理。益处还有：咱们能够别离监控长期表空间、数据表空间、wal 日志、谬误日志，晓得各个局部占用状况，如果磁盘空间告警，能够针对性采取措施。Greenplum 创立长期表空间的办法，比拟规范，如下：

postgres=# select * from pg_relation_filepath('tmp_jc');

 pg_relation_filepath

----------------------

base/13333/t_845345

#查问实例的 Segment 的所有 hosts，用于创立长期表空间目录

psql -d postgres -c 'select distinct address from gp_Segment_configuration order by 1' -t > sheng_seg_hosts

#创立长期表空间的文件目录

gpssh -f sheng_seg_hosts -e "ls -l /home/adbpgadmin/tmptblspace"

gpssh -f sheng_seg_hosts -e "mkdir -p /home/adbpgadmin/tmptblspace"

~$ gpssh -f dg_seg_hosts -e "ls -l /home/adbpgadmin/tmptblspace"

# 创立长期表空间

postgres=# create tablespace tmp_tblspace location '/home/adbpgadmin/tmptblspace';

postgres=# select * from pg_tablespace;

   spcname    | spcowner | spcacl | spcoptions

--------------+----------+--------+------------

 pg_default   |       10 |        |

 pg_global    |       10 |        |

 tmp_tblspace |       10 |        |

(3 rows)

#批改角色的长期表空间

postgres=# alter role all set temp_tablespaces='tmp_tblspace';

#退出 psql，而后从新登录

#创立长期表进行验证

create temp table tmp_jc2(id int);

insert into tmp_jc2 select generate_series(1,10000);

#查看表的 filepath，发现长期表空间的文件门路不是 base 目录了

select * from pg_relation_filepath('tmp_jc2');

---------------------------------------------------

 pg_tblspc/2014382/GPDB_6_301908232/13333/t_845369

表空间独立后，监控能够辨别长期表空间、数据表空间、WAL 日志、谬误日志进行独立监控和告警，以下是监控采集输入的样例：

~$ sh check_disk_data_size.sh

usage: sh check_disk_data_size.sh param1 param2, param1 is file recording Segment hosts; param2 data, xlog, log or temp

监控输入的成果如下

图 14：监控采集输入示意图

这样能够很分明的理解业务数据或长期表数据在每个节点上的理论 size，以及是否存在数据歪斜状况（超过平均值的 10%）独自揭示，十分实用。

除了下面详述的优化计划，一般来讲，Greenplum 还有一些通用的解决办法：扩容 Segment 计算节点、业务数据裁剪、备份文件清理。计算节点扩容是最无效的。一般来讲，不论是阿里本人的业务，还是内部客户的业务，数据库的磁盘占用达到 60%，思考业务增量便会布局扩容，这些“根本实际”咱们须要通知客户。

业务数据裁剪，除了冷数据外，有一些两头表和历史表，咱们也能够推动业务方做好数据生命周期治理，及时删除或转存归档。另外，对于长期运维操作，留下的备份文件，在操作完后须要及时进行清理，这个简略的习惯是非常容易疏忽的，须要留神。在大库的磁盘治理中，任何小问题都会放大。

本案例，客户原 DB2 的数据量大于 1PB，而咱们通过上述办法综合优化，在 ADB 中只保留了 300 多 T 的数据，就让整体业务残缺的运行起来。为客户节约了大略 100 台服务器及相干软件 license 费用，约合金额千万级别。

磁盘水位高会带来很多问题，通过磁盘空间优化计划，能够防止这些问题的产生。包含：

1. 业务略微增长，可能导致磁盘占满，产生“写锁定”，数据库长期罢工；

2. 磁盘空间有余时，运维人员定位问题无奈创立长期表；

3.ADB 的大表保护，例如 vacuum full，无空余磁盘空间应用。

以上磁盘空间优化办法不肯定十分全面，心愿对读者有所帮忙。如果文中有疏漏或读者有补充，欢送多多交换，一起探讨上云老本优化。

名词解释

业务方：指应用 Greenplum 做业务开发或数据分析的用户，通常是客户或客户的开发商。

OLAP：指联机剖析解决型零碎，是数据仓库零碎最次要的利用，专门设计用于反对简单的大数据量的剖析查询处理，并疾速返回直观易懂的后果。

DML：指减少、删除、批改、合并表数据的 SQL，在数据库畛域叫 DML 型 SQL。

PB：1PB=1024TB=1024 * 1024 GB

原文链接
本文为阿里云原创内容，未经容许不得转载。

关于数据库:ADBPGGreenplum成本优化之磁盘水位管理

一背景形容

二 ADB PG & Greenplum 的磁盘治理简介

1 ADB PG 磁盘治理的关键技术点

2 数据库管控的磁盘预留机制

3 数据库管控的“锁定写”爱护机制

三磁盘空间优化计划

1 表的存储格局及压缩

2 冷热数据分层存储

3 垃圾数据 vacuum

5 复制表批改为散布表

6 长期表空间独立寄存

查看长期表的表空间现状，发现都在 base 目录下，即与数据目录共用

7 其余优化计划

四优化收益

1 为客户节约服务器老本

2 防止磁盘水位过高造成次生灾祸

一 背景形容