PostgreSQL 安全管理 数据脱敏 Anonymizer 性能

1 背景知识

任何脱敏的过程都是有代价的，它会消耗CPU、内存、还可能占用大量的磁盘I/O 。具体取决于使用的策略

脱敏性能主要取决于两个方面：

1. 数据库大小。
2. 屏蔽规则的数量。

2 静态脱敏 性能

静态脱敏将会重写脱敏表的所有数据。这个过程很缓慢，并且在此过程中，表将会被锁定。

在 AWS EC2 上使用29 条规则对 44GB 数据进行脱敏大约需要25 分钟。

在静态脱敏的情况下，脱敏的成本是一次性的。

3 动态脱敏性能

动态脱敏底层原理其实就是使用视图。所以要比直接从表中查询数据要慢。

如果对一张表应用3 或4 条规则，脱敏用户响应时间慢约 20% 至 30%。

如果脱敏用户被用于数据分析业务，使用动态脱敏是比较合适的。例如，数据分析师每个月生成业务报告。

如果脱敏用户使用脱敏数据非常活跃，则应该在另外一台服务器上导出脱敏数据，并让这些用户连接到这台服务器上。

在这种情况下，脱敏的成本是算在脱敏账户中的。

4 导出脱敏性能

通过 benchmark 基准测试 pg_dump_anon 工具导出的速率是 pg_dump 工具的两倍。

5 如何加快脱敏速率

5.1 尽可能选择“MASKED WITH VALUE

用静态值脱敏要比调用脱敏函数快一些。

5.2 尽量使用抽样脱敏

如果仅仅是为了测试，那么只需要对数据库某个部分子集进行脱敏即可。在这种情况下，你可以缩小数据量加快脱敏速度。

请参考抽样脱敏章节了解更多信息。

5.3 使用物化视图

动态脱敏可能不是特别适合的场景时，使用PostgreSQL 物化视图 更有效。
例如，简历物化视图并对敏感字段进行随机化脱敏。

CREATE MATERIALIZED VIEW masked_customer AS
SELECT
    id,
    anon.random_last_name() AS name,
    anon.random_date_betweenDATE,now() AS birth,
    fk_last_order,
    store_id
FROM customer;