我们来谈谈性能数据， PostgreSQL 有多强大？

terry 2年前 (2023-09-26) 阅读数 50 #数据库

用性能数据说话，讨论最有效的PostgreSQL威力，帮助大家“知己知彼”。

太长，无法阅读

如果您对这些问题感兴趣，这篇文章将帮助您：

PostgreSQL 有多强大？
检查60万+ QPS，最高可达200万。读写TPS每秒7万+，最高可达14万。
PostgreSQL 与 MySQL 性能对比
在极端条件下，PgSQL 的查询性能优于 MySQL，其他性能与 MySQL 类似。
PostgreSQL与其他数据库的性能对比
“分布式数据库”的性能在同等硬件参数下远远落后于常规数据库。
TPC-H PostgreSQL 性能等分析数据。
PostgreSQL 是一个 HATP 数据库，具有独特的分析功能。
云数据和云服务器的成本有优势吗？
c5d.metal 只需 1 年的价格，您就可以购买服务器并托管 5 年。以一年云数据的价格和相应的条款，您可以购买相同的EC2云服务器并使用20年。

发布于：https://github.com/Vonng/pgtpc

PGBENCH

软件和硬件技术每天都在变化。虽然关于绩效考核的文章很多，但能够表达出来的并不多。种类。在本实验中，我们选择了两种新的硬件规格，并使用PGBENCH来测试PostgreSQL ⓻⓻14的性能。

测试对象包括四种规格、两台Apple笔记本电脑和三台AWS EC2云服务器。分别是2018年采用Intel 6核i9芯片的顶级15英寸Macbook Pro、2021年采用M1 MAX芯片的顶级16英寸Macbook Pro、AWS z1d.2xlarge（8C 64G）、以及AWS c5d.metal，这些都是市售的商业设备。

PGBENCH是PostgreSQL自己的压力测试工具。它使用与TPC-B相同的问题，可用于评估PostgreSQL及其相应版本的性能。有两种类型的测试：RO只读问题和RW读写问题。

只读查询由一条SQL语句组成，该SQL语句是从1亿个数据文件中随机选择的；如果一个读写事务由5条SQL语句组成，1条查询，1条插入，3条更新。

测试基于数据大小 s=1000。使用PGBENCH逐步增加客户连接数，找到QPS TPS的最高点，连续测试3-5分钟后记录长期平均值。结果如下：

读写

图：各硬件配置下TPS读写上限

图：各硬件配置下TPS读写-并发曲线

只读

图：各种硬件配置下的QPS上限

图：各种硬件配置下的QPS查询点-并发曲线

答案很震撼。在 Apple M1 Max 10C 笔记本上，PG 运行了 32K 读写、240K 点，在 AWS c5d.metal 生产物理机上，PG 运行了 72K 读写和 630K 查询。通过极限压缩，您可以实现每台机器 137K 的读取和写入以及2M 个数字。

个人参考，探探作为前端互联网App，PostgreSQL全球TPS在40万左右。这意味着几十台新笔记本电脑或几台高端服务器（10W以下）就有能力支持大规模互联网应用中的数据服务，这在以前是不可想象的。

关于价格

以宁夏地区C5D.METAL型号为例。该机型是目前算力最全的物理机，并配备3.6TB本地NVME SSD存储。有 7 个选项可供选择。付费模式：

等值年费11万到15万，年零售价38万。如果单独购买机器，五年的IDC托管和网络电源维护费用应该在10万以内。尽管云设备每年的成本似乎是自己构建的五倍，但考虑到可用性、折扣和优惠券，价格仍然在合理范围内。 AWS EC2 云服务器。使用此类云工具构建自己的数据库也具有出色的性能。

但 RDS for PostgreSQL 却是一个完全不同的故事。如果要使用类似需求的云数据，最接近的规格是db.m5.24xlarge，96C，384G，配置存储3.6T 80000 IOPS io1（c5d .metal 3.6T NVME SSD 8K RW IOPS约为95K，最大标准io1存储的IOPS为80K），每月费用为24万日元，每年费用为2,867,630日元，几乎是同条件自建EC2的20倍❀。

AWS价格计算器：https://calculator.amazonaws.cn/

SYSBENCH

PostgreSQL非常强大，但是它与其他数据库系统相比如何？ PGBENCH主要用于评估PostgreSQL和提取/一致性数据库的性能，但如果我们需要横向比较不同数据库的性能，我们将使用SYSBENCH。

SYSBENCH 是一款开源、跨平台的数据库性能测试工具。测试的结果可以代表数据库系统的性能。 SYSBENCH包含10个标准测试用例，例如用于测试点显示的oltp_point_select
，用于更新显示的oltp_update_index
和。（一笔交易 16 个问题）、oltp_read_write
（一笔交易 20 个混合问题）和 oltp_write_only）等 (s)

SYSBENCH 可用于测试的性能优于MySQL或PgSQL（包括两者兼容的衍生品），因此具有良好的横向比较。首先我们来看看最流行的开源关系型数据库大战：世界上“最有名”的开源关系型数据库MySQL和关系型数据库世界上最先进的开源的性能并列对比，PostgreSQL。

`Dirty Hack`

MySQL 未提供官方 SYSBENCH 测试结果。它只在官网发布了图片和第三方评测结果的链接，没有任何解释意味着MySQL可以达到1M查询QPS。 240K索引键更新，约39K复合读写TPS。

图片：https://www.mysql.com/why-mysql/benchmarks/mysql/

非常不道德行为。因为如果你阅读连接评估文章，你会发现这是关闭所有 MySQL 安全功能的结果：关闭 Binlog、运行磁盘刷新、FSYNC、性能监控、DoubleWrite、校验和以及强制使用 Latin- 1 个字符集。此类数据永远不能在生产环境中使用，只能用于评分目的。

但另一方面，我们也可以利用这些Dirty Hacks来禁用相应的PostgreSQL安全功能，看看PostgreSQL的最终极限在哪里？结果令人震惊。 PGSQL QPS达到每秒233万次查询，峰值是MySQL的两倍多。

照片：没有军事道德的Benchmar：PgSQL vs MySQL

配置极限下的PostgreSQL点检现场测试压力

必须注意的是MySQL bench使用的是48C 2.7GHz 6GHz机器，而使用It Post的s3S3GHz aQL MySQL 桌面。机器。不过，由于 PG 使用进程模型，我们可以使用测试值 c=48 作为 48C 机器上 PG 性能的较低估计：对于只读请求，QPS 的峰值通常在客户数量达到时达到。略大于CPU核心数。然而，当c=48时，PG QPS请求（150万）仍然比MySQL的峰值高43%。

由于我不是MySQL专家，所以也希望MYSQL专家能提供基于相同工具的评估报告，并提供更多对比测试结果。

图：MySQL有四个SYSBENCH结果，c=48

在其他测试中，MySQL也有出色的表现，otlp_read_only❀ 索引

两者都接近PostgreSQL (c=48)，而且 PostgreSQL 甚至比 oltp_read_write
还要好一些。
总的来说，极端条件下，除了计算上PG碾压MySQL外，其他测试中PG的表现与MySQL差不多。
公平竞争
虽然在功能丰富度上并没有完全不同，但在极限 OLTP 性能方面 MySQL 与 PostgreSQL 类似。那么其他数据库实现呢，尤其是新一代的 NewSQL？
能够在官网提供SYSBENCH测试报告的数据库被视为符合Fair Play资格的玩家。我们相信它们都是基于真实生产环境中使用的配置进行测试的，因此我们不能像MySQL那样使用Dirty Hack。这里我们仍然使用AWS模型c5d.metal，但是我们完全使用生产环境进行性能测试。相比上次的表现，这次的表现几乎是共识的一半，但却更加有力，信心也更加坚定。对面的。
从NewSQL数据库官网收集官方SYSBENCH评测报告。并非所有数据库都提供完整的 SYSBENCH 10 测试结果，并且设备描述和表格各不相同。但考虑到几个数据库采用相同的硬件参数（约100核算力，除PolarDB-X和YugaBytes外），且数据大小一般为160M（除OB和YB外），整体规模还是比较大的。对比足以让我们看到豹子并产生直观的认识。
图：SYSBENCH 10测试结果（QPS，越高越好）
数据库分类中归一化性能对比除以核心数
让笔者惊讶的是新一代分布式数据库（NewSQL）将胯部拉过板子。在相似的硬件规格下，与 PostgreSQL 存在许多重要差异。新数据库中最好的是PolarDB，它仍然基于经典的主从架构。这样的性能结果不可避免地让人们重新考虑分布式数据库和NewSQL的概念。
一般来说，分布式数据的优缺点之间的主要权衡是规模质量，但人们没有想到的是，不仅牺牲了功能和稳定性，而且展示效果也同样出色。高德纳说：“过早进步是万恶之源”。为了不必要的规模（万亿+、数百TB+TP）而牺牲大量性能（以及功能和稳定性）无疑是一个不成熟的改进。一个功能，但拥有需要共享数据的 Google 数据的业务场景数量仍然是一个问号。
TPC-H 分析显示
如果 TP 不起作用，AP 会帮忙。虽然分布式数据在TP领域非常流行，但AP数据分析才是分布式数据的主要驱动力，所以很多分布式数据喜欢调侃HTAP的概念。为了衡量AP系统的性能，我们将使用TPC-H测试。
TPC-H 这是一个创建的数据仓库，有8张数据表和22条复杂的分析SQL，衡量分析性能的标准通常是在指定数量下执行这22条SQL语句所需的时间。（通常是100个仓库，大约100GB数据作为基准）
我们在本地笔记本电脑和云服务器上测试了1、10、50、100个TPC-H仓库和一点AWS，并完成了全部22个问题。耗时结果如下：
为了横向比较，我们选择了其他官网或更详细的第三方评测结果。不过在比较之前，有几点需要注意：第一，有的产品数据不是100，第二，硬件规格也不同，第三，不是所有的文档都是答案评估是来自原公司的，所以可以只能是。用作比较和严格参考。
为了简化测量，我们可以标准化核心和 bin 的数量，并使用 QPH（即每个核心每个 bin 每小时可以执行多少轮 TPC-H 查询）来评估相关性。数据性能分析。
QPH = (1周期) * (仓库数量核心数量) * 3600
查询22的时间消耗与仓库数量完全不同，所以请注意。
一般情况下，即使是运行 PostgreSQL 的 10 核笔记本也能取得非常可观的分析结果（注：任务内存超过 50C，所以使用了 SWAP 和 IO 磁盘）。
图：《how good is my HTAP system》论文提出的评估HTAP系统容量的方法——吞吐量极限，画出了AP/TP平面混合负载的极值。
至少对于数百GB的表来说，PostgreSQL可以称为性能良好的分析型数据库。如果单个表大于几TB，则可以轻松配置与PostgreSQL兼容的MPP数据仓库，例如Greenplum MatrixDB DeepGreen。。 PostgreSQL通过主从复制可以通过从数据库容纳几乎无限的读取负载。 PostgreSQL使用逻辑复制可以完成内置/同步AP ETL模式。可以说是真实的HTAP数据。
总之，PostgreSQL在TP域表现非常好，在AP域表现也很突出。毫不奇怪，在近年来的年度 StackOverflow 开发者调查中，PostgreSQL 成为专业开发者中最常用、最喜欢、最想要的皇冠数据库。
StackOverflow 近六年数据库开发者调查结果：为什么 PostgreSQL 是最高效的数据库？
参考
[1]: https://github.com/Vonng/pgtpc "Vonng: PGTPC" [2]: https://www.mysql.com/cn/why-mysql/benchmarks/mysql/ "WHY MYSQL" [3]: http://dimitrik.free.fr/blog/posts/mysql-performance-1m-iobound-qps-with-80-ga-on-intel-optane-ssd.html "MySQL Performance : 1M *IO-bound* QPS with 8.0 GA on Intel Optane SSD !" [4]: http://dimitrik.free.fr/blog/posts/mysql-performance-80-and-sysbench-oltp_rw-updatenokey.html "MySQL Performance : 8.0 and Sysbench OLTP_RW Update-NoKEY" [5]: http://dimitrik.free.fr/blog/posts/mysql-80-perf-new-dblwr.html "MySQL Performance : The New InnoDB Double Write Buffer in Action" [6]: https://docs.pingcap.com/tidb/stable/benchmark-sysbench-v6.1.0-vs-v6.0.0 "TiDB Sysbench Performance Test Report -- v6.1.0 vs. v6.0.0" [7]: https://www.oceanbase.com/docs/community/observer-cn/V3.1.4/10000000000450311 "OceanBase 3.1 Sysbench 性能测试报告" [8]: https://www.cockroachlabs.com/docs/stable/performance.html "Cockroach 22.15 Benchmarking Overview" [9]: https://docs.yugabyte.com/preview/benchmark/sysbench-ysql/ "Benchmark YSQL performance using sysbench (v2.15)" [10]: https://help.aliyun.com/document_detail/139562.html "PolarDB-X 1.0 Sysbench 测试说明" [11]: https://stonedb.io/zh/docs/performance-tuning/performance-tests/OLAP/tcph-test-report/ "StoneDB OLAP TCP-H测试报告" [12]: https://dl.acm.org/doi/10.1145/3514221.3526148 "Elena Milkai: "How Good is My HTAP System?",SIGMOD ’22 Session 25"
[13]：https://calculator.amazonaws.cn/ “AWS计算器”