PostgreSQL 到底有多強？

用性能數據說話，爲什麼 PostgreSQL 是世界上最先進的開源關係型數據庫，暨世界上最成功的數據庫。

太長不看

如果您對這些問題感興趣，本文會對您有所幫助：

詳細測試過程與原始數據放置於：https://github.com/Vonng/pgtpc

PGBENCH

軟件與硬件的技術日新月異，儘管性能評測的文章汗牛充棟，卻沒有多少能反映這些變化。在本次測試中，我們選擇了兩種新規格硬件，使用 PGBENCH 測試了最新的 PostgreSQL 14.5 在這些硬件上的性能表現。

測試主體包括四種規格，兩臺 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，隨機從 1 億條數據庫中挑選一條查出；而讀寫事務包含 5 條 SQL 語句，一條查詢、1 條插入與三條更新。

測試基於 s=1000 的數據集規模，使用 PGBENCH 逐步增加客戶端連接數，找到 QPS / TPS 的極大值點，並記錄持續測試 3-5 分鐘後的穩定均值，結果如下：

Read Write

圖：各硬件配置下讀寫 TPS 上限

圖：各硬件配置下讀寫 TPS - 併發曲線

Read Only

圖：各硬件配置下點查 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.6 TB 的本地 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，綜合讀寫事務性能的 oltp_read_only (16 條查詢一個事務)，oltp_read_write （20 條混合查詢一個事務）與oltp_write_only （6 條寫入 SQL）等…。

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 Hack，把對應的 PostgreSQL 安全特性也關閉，也看看 PostgreSQL 的最終極限在哪裏？結果相當震撼，PGSQL 點查 QPS 幹到了 233 萬每秒，峯值遠遠甩開 MySQL 一倍還多。

圖：不講武德的 Benchmar：PgSQL vs MySQL

PostgreSQL 極限配置下點查壓測現場

必須說明的是，MySQL 的 bench 使用的是 48C 2.7GHz 的機器，而 PostgreSQL 使用的是 96C 3.6GHz 的機器。不過因爲 PG 使用進程模型，我們可以使用 c=48 的測試值作爲 PG 在 48C 機器上表現的一個下限近似：對於只讀請求，QPS 峯值通常在客戶端數略大於 CPU 核數時達到。即便如此，c=48 時 PG 的點查 QPS（ 150 萬）仍然比 MySQL 峯值高了 43%。

因爲我並不是 MySQL 專家，在此也期待 MYSQL 專家基於完全相同的硬件給出測評報告，提出更具對比性的測試結果。

圖：MySQL 有結果的四項 SYSBENCH 結果，c=48

在其他測試上，MySQL 也有不錯的極限表現，otlp_read_only, oltp_update_non_index 都與 PostgreSQL （c=48）接近持平，甚至在 oltp_read_write 上還略微超過 PostgreSQL。

總體來說在極限條件下，PG 除了點查上碾壓了 MySQL，其他測試上性能與 MySQL 基本持平。

Fair Play

儘管在功能豐富度上判若雲泥，但 MySQL 在 OLTP 極限性能上基本能與 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 的理念。

通常來說，分佈式數據庫的核心利弊權衡是質量換規模，但讓人沒想到的是犧牲掉的不僅僅是功能與穩定性，還有如此可觀的性能。高德納曰：“過早優化是萬惡之源”，爲了不需要的規模（萬億級 +，TP 百 TB+）犧牲如此大的性能（以及功能與穩定性）毫無疑問是過早優化的一種形式，而能有多少業務場景會有 Google 量級的數據非要分佈式數據庫不可，仍然是一個問號。

TPC-H 分析性能

TP 不行，AP 來湊。儘管分佈式數據庫在 TP 領域如此拉胯，但數據分析 AP 纔是分佈式數據庫的基本盤，因此很多分佈式數據庫喜歡炒作 HTAP 的概念。而衡量 AP 系統的能力，我們會用到 TPC-H 測試。

TPC-H 這是一個模擬數倉，包含 8 張數據表，與 22 條複雜分析類 SQL。衡量分析性能的標準通常是在指定倉數下執行這 22 條 SQL 的耗時。（通常使用 100 倉，約 100GB 數據作爲基準）

我們在本地筆記本和小型 AWS 雲服務器進行了 TPC-H 1,10,50,100 倉的測試，完成全部 22 個查詢，耗時結果如下：

作爲橫向對比，我們選取了一些其他數據庫官網或比較詳細的第三方測評結果。不過在對比前，有幾點需要注意：一是有一些數據庫產品倉數並非 100，二來硬件規格也不盡相同，三來並不是所有數據庫評測結果都來自原廠，因此只能作爲大致的對照和參考。

爲了便於衡量，我們可以歸一化核數與倉數，用 QPH ，即每小時，每核，執行 1 倉 TPC-H 查詢可以執行多少輪，來近似評估數據庫的相對分析性能。

QPH = (1 / 時長) * (倉數 / 核數) * 3600

22 個查詢耗時對於不同倉數來說並非完全線性關係，需要注意。

總體來說，即使是 10 核的筆記本跑 PostgreSQL，也可以有相當亮眼的分析成績來（注：50C 以上工作集已經超過內存，走 SWAP 與磁盤 IO 了）。

圖：論文《how good is my HTAP system》提出的評測 HTAP 系統能力的方法 —— 吞吐量前沿，在 AP/TP 二維平面上畫出混合負載的吞吐量極值。

至少在百 GB 級的表上，PostgreSQL 足以稱得上是一款表現優秀的分析數據庫。如果單表超過幾 TB 量級，也可以平滑升級至 Greenplum / MatrixDB / DeepGreen 等 PostgreSQL 兼容 MPP 數倉。。採用主從複製的 PostgreSQL 可以通過級聯從庫的方式近乎無限地 Scale 讀負載，採用邏輯複製的 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 Calculator"
本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/651zXDKGwFy8i0Owrmm-Xg

猜你喜歡