这篇文章比较了 Percona 为 PostgreSQL 提供的 pg_tde 扩展与未修改的 PostgreSQL 的性能。Percona 的 pg_tde 扩展为磁盘上的数据页和 WAL 文件提供了加密功能，即“静态数据加密”。该扩展目前处于发布候选（rc）阶段。此次测试并未将 pg_tde 与其他产品进行比较，而是测试该扩展的性能，并与未修改的 PostgreSQL 进行对比，展示静态数据加密以及 WAL 加密所带来的性能开销。
执行摘要
在所有测试中，Percona 的 pg_tde 对加密数据页的性能影响是可测量的，但并不大。对于写入密集型测试，加密 WAL 页面的性能影响约为 20%。此次测试使用的是扩展的发布候选（RC）版本，然而 WAL 加密功能目前仍处于测试阶段。
什么是透明数据加密
透明数据加密（TDE）是一种加密机制，用于加密存储在存储系统（“磁盘上”）的“静态”数据，从而保护存储在数据库中的敏感数据。
如今，数据在传输过程中进行加密（使用传输层安全协议 - TLS）已非常普遍，不仅 PostgreSQL 如此，许多网站也采用这种方式，通过使用 https 协议而非 http 协议来实现。如今大部分电子邮件的传输也采用 TLS。简而言之，TLS 非常常见。PostgreSQL 至少从 7.1 版本开始就支持加密连接。
然而，PostgreSQL 并未内置存储在数据库中的数据加密功能。数据库可以存储在加密磁盘或加密文件系统上，这在一定程度上可以防止磁盘被盗或丢失。但这并不能阻止在操作系统已解密文件系统或磁盘时访问数据。pgcrypto 扩展为磁盘上部分数据的加密和解密提供了基本支持和数字签名，但操作较为复杂，且数据无法安全索引。
任何形式的加密都不是免费的，它需要消耗 CPU 资源，无论是加密还是解密都需要额外的 CPU 周期。根据加密的实现方式，这种额外开销可能会很大。
测试方法
测试使用 pgbench，并运行了一系列测试：
- 事务数量始终为 1000（pgbench 的默认值为 10）。
- 测试以仅选择模式以及读/写模式运行。
- 客户端数量从 1 到 70（1、2、5、10、20、30、40、50、60、70）。
- 缩放因子范围从 5 到 5000（5、10、50、100、400、600、1000、2000、4000、5000）。
- 每次测试重复 5 次，选取最佳值。
测试的详细内容在博客文章《TDE 性能测试的测试方法》中有详细说明。该博客文章还包含了更多带有详细信息的图表。
所有测试的事务数量均从默认的 10 增加到 1000。初步结果显示，当该数字增加时，数值的波动会减少。
性能测试总结
从实际应用角度来看，与原生 PostgreSQL 相比，Percona 的 pg_tde 对数据页的性能几乎相当。数字和图表显示，没有加密的原生 PostgreSQL 性能略好一些，但差异通常可以忽略不计。这种模式在大量客户端以及不同测试数据大小下均保持一致。
这可以通过加密和未加密数据页所需的 I/O 相等，以及 CPU 中使用硬件加速加密来解释。Percona 的 pg_tde 使用 OpenSSL（版本为“3.0.13”）进行加密操作。此次测试中使用的 CPU 设置了“aes”标志。
只读测试，缩放因子为 5000
在重读/写测试中，WAL 加密的开销是可测量的，最高可达 20%。这可以通过在将 WAL 块写入磁盘之前，即使是小数据块也需要不断加密来解释。只读工作负载不受 WAL 加密的影响。此次测试未对在副本上解密 WAL 数据或在恢复期间的性能影响进行测试。
读/写测试，缩放因子为 5000
作为 DBA 使用 Percona 的 pg_tde
在测试过程中，我特别关注使用 Percona 的 pg_tde 是容易还是复杂。
首先，如果你想使用 Percona 的 pg_tde，目前你必须使用 Percona PostgreSQL 软件包。这很容易使用，对于我的 Debian/Ubuntu 系统，一个仓库允许选择分发渠道（实验性、测试性、发布性），并安装软件包。该软件包的使用方式类似于原生 APT 软件包。目前无法在未修改的 PostgreSQL 中将 Percona 的 pg_tde 作为扩展使用。
密钥处理允许使用本地密钥，但这仅用于测试。将密钥保留在数据库服务器上是不安全的——任何能够访问服务器的人都可以访问密钥，并使用这些密钥解密数据。密钥处理也可以通过使用密钥管理存储来管理。推荐采用这种方法。测试中我使用了本地密钥。
一旦激活密钥处理，数据库管理员或用户只需使用 tde_heap 访问方法创建表即可。或者更改表并设置访问方法，表将被重写，从而启用加密：
ALTER TABLE <表名> SET access method tde_heap;
最好在将任何数据写入磁盘之前完成此操作。PostgreSQL 自 15 版本起支持 SET ACCESS METHOD 语法，但特定的 tde_heap 方法在常规 PostgreSQL 中不可用。这是 Percona 的 pg_tde 版本的一部分。
除此之外，在我的测试中，Percona 的 pg_tde 表现得就像一个普通的 PostgreSQL 数据库。
TDE 的未来
布鲁斯（Bruce）不久前曾就 PostgreSQL 中的 TDE 发表过博客文章。短期内甚至中期内，TDE 本身成为核心功能的可能性不大。存在太多未解决的问题。然而，出于合规性原因，这是一个经常被要求的功能，要求敏感数据在静态时加密。
目前，如果你需要 PostgreSQL 中的 TDE 以满足合规性要求，选择其中一家供应商是你的最佳选择。
透明性
去年，Percona 找到我，希望我对他们的 PostgreSQL 的 pg_tde 扩展进行独立的性能评估。我同意了，但前提是：
我对测试和由此产生的博客文章（即这篇文章）拥有完全的自主权。
Percona 对测试和这篇文章的内容没有影响力。
Percona 有权取消测试，但合同仍然视为履行。
Percona 为测试期间的测试系统付费。
这是一次性能评估，而非安全评估。
在测试阶段，我发现了一些问题，并已反馈给 Percona。详细内容可以在博客文章的末尾找到。
原文地址：https://andreas.scherbaum.la/post/2025-06-30_performance-test-for-percona-transparent-data-encryption-tde/
原文作者：Andreas
