数据存储策略对 PostgreSQL 性能的影响
PostgreSQL 在其 100% 免费和开源版本中继续巩固其作为企业级数据库的有效性。数据团队应该对 OS PostgreSQL 充满信心，而不是被不太通用且成本更高的开放式核心 Postgres 重新打包所吸引。
也就是说，用正确的补充技术策略支持开源PostgreSQL可以对古老的关系数据库提供的价值产生深远的影响。例如，支持具有快速存储策略的 PostgreSQL 数据库实施的企业可以实现高端性能优势，包括服务器可以处理的 TPS 工作负载的大幅增加。
在我们最近使用相对较小的集群（8 核）进行的实验中，在 Azure NetApp 文件 (ANF) 上运行 Instaclustr Managed PostgreSQL 导致性能提升高达 270%。对于在 Azure 上拥有 PostgreSQL 用例的企业，这些发现为将 PostgreSQL 与有益的文件存储技术相结合提供了一个令人信服的案例。
以下部分详细介绍了我们应用的数据库测试方法以及证明此性能优势的结果。
测试方法
我们使用pgbench来运行我们的测试。我们在与 PostgreSQL 实例相同的网络中创建了一个运行 pgbench 的单独 VM，以模拟客户应用程序通过网络与数据库对话。
我们测试了两个实例以收集比较。DS13 实例在 Microsoft Premium SSD 上运行，而 E8s_v4 在 ANF 高级存储上运行。
-
InstaclustrPGS-PRD-Standard_DS13_v2-2000(8vCPU56GBRAM2TBStorage)
-
InstaclustrPGS-PRD-Standard_E8s_v4-2048-ANF(8vCPU64GBRAM2TBStorage)
注意：作为Postgres-ANF最新版本的一部分，我们将 VM 硬件从旧的 Dsv2 升级到更现代的 Esv4。这稍微更经济一些，我们的测试表明它不会影响高级磁盘比较的性能。在 E8s_v4 硬件上运行的“其他托管 postgres”的结果显示 TPS 与 DS13_v2 硬件极为相似。
在测试之前，我们为数据库加载了 域名 的数据，以确保这是对生产工作负载的良好模拟。我们过去发现，如果我们在基准测试之前只加载少量数据，那么这些数据可以缓存在 RAM 中，并且不能准确代表真实世界的性能。
测试由 bash 脚本驱动，循环遍历不同的客户端数量以研究可扩展性。我们对每种配置执行了三次测试，并对结果取平均值。
在重复运行之间看到最小的差异。在我们的 pgbench 配置中，比例设置为 10,000。客户端在 4、8、16、32、64 和 96 之间循环。我们用于测试的完整脚本可以在我们的 GitHub 上找到。
性能调优
初步测试表明，当 clients=cores 时，Postgres-ANF 服务器的性能非常好，但性能会意外下降。调查和度量日志记录表明在 WAL 压缩和 bgwriter_delay 中产生了瓶颈。调整这些参数使我们能够远远超过八个客户端的数量并获得您在下面看到的结果。这些调整优化现在默认在 Instaclustr Managed PostgreSQL 中实现，下面的结果是基于当前的默认配置。
结果
读/写工作负载
ANF 存储上可用的 IOPS 增加表明 PostgreSQL 应用程序的性能得到了显着改善。在 8 个客户端时，TPS 的最高增幅比同等的基于 Azure 高级磁盘的 Instaclustr 服务器快 167%，我们看到的最差是在 32 个客户端时增幅 127%。ANF 存储始终如一地提供更高的TPS，在所有测试的客户端数量上都持续更快，并且这一结果在几天内的多次重复运行中是一致的。
只读工作负载
ANF 存储上可用的 IOPS 增加对 PostgreSQL 应用程序的只读性能产生了更为显着的影响。在 64 个客户端时，TPS 的最高增幅比基于 Azure 高级磁盘的 Instaclustr 服务器快 325%，而我们看到的最差是在 16 个客户端时增加 193%。再一次，TPS 在所有测试的客户端数量上始终保持较高水平，这一结果在几天内的多次重复运行中得到了证明。
存储显着影响 PostgreSQL 性能
对于读取要求高或读/写繁重工作负载的数据团队，我们建议使用高性能数据存储来支持您的 PostgreSQL 集群。工作负载较小、要求较低的企业也将从基于 Azure 高级磁盘的 PostgreSQL 节点中获益。
对于企业通过利用 100% 开源 PostgreSQL 获得的所有优势，引入支持性数据存储策略可以进一步发挥这些优势。
