在為 Postgres 運行性能基準測試時，主要建議是：“自動化！”

如果您正在測量數據庫性能，您可能不得不一遍又一遍地運行相同的基準測試。要么是因為你想要一個稍微不同的配置，要么是因為你意識到你使用了一些錯誤的設置，或者可能是其他一些原因。通過自動化運行性能基準測試的方式，當發生這種情況時您不會太煩惱，因為重新運行基準測試將花費很少的精力（它只會花費一些時間）。

但是，為數據庫基準測試構建這種自動化也可能非常耗時。因此，在這篇文章中，我將分享我構建的工具，以便輕松運行針對 Postgres 的基準測試 — 特別是針對在 Azure Database for PostgreSQL 中名為 Hyperscale (Citus) 的 Azure 托管數據庫服務中運行的 Postgres 的 Citus 擴展。

• ??https://docs.microsoft.com/azure/postgresql/hyperscale/??
• ??https://github.com/citusdata/citus??

第一部分探討了不同類型的應用程序工作負載及其特征，以及每種常用的現成基準。之后，您可以深入了解如何在 Azure 上將 HammerDB 與 Citus 和 Postgres 一起使用。是的，您還會看到一些示例基準測試結果。

為什么要先深入了解不同工作負載和數據庫基準測試的背景？因為有比自動化運行性能基準的方式更重要的事情：為您選擇正確的基準！

針對不同工作負載的不同基準

基準規范與完整的基準測試套件

• OLTP 工作負載
• OLAP 工作負載
• HTAP 工作負載

比較基準測試結果的Dangers HammerDB TPROC-C 如何使用HammerDB、ARM、Bicep 和 cloud-init 對 Citus 進行基準測試在Azure 上使用更大的 Citus 數據庫集群達到 200 萬 NOPM享受對數據庫性能進行基準測試的樂趣

針對不同類型工作負載的不同類型基準測試

每個使用數據庫的人都將它用于不同的工作負載，因為每個人都有不同的數據集并運行不同的查詢。因此，在比較數據庫性能時，您將通過運行基于您自己的工作負載的基準來獲得最準確的結果。然而，準備一個完全自定義的基準測試可能需要相當多的工作。

因此，您可能希望使用與您自己的工作負載非常相似的工作負載運行現成的基準測試。

基準規范與完整的基準套件

可以通過兩種不同的方式為您提供現成的基準：

• 基準測試規范。 在這種情況下，描述了如何在文檔中運行基準測試。它將告訴您如何準備表、如何加載數據以及要運行哪些查詢。但是您需要手動完成所有這些操作。
• 完整的基準測試套件。 在這種情況下，將向您提供一個應用程序，它將運行基準測試。您將基準測試應用程序配置為針對您的數據庫服務器運行 — 一旦運行完成，它會吐出一些數字來指示運行的好壞。

很明顯，完整的基準測試套件通常是您想要的，因為您可以簡單地啟動基準測試應用程序并獲得結果。如果您只有一個基準測試規范，那么您首先需要編寫工具來針對數據庫運行該規范。

OLTP (在線事務處理)工作負載

數據庫的一個常見工作負載類別稱為 OLTP（在線事務處理）。屬于 OLTP 類別的工作負載會向數據庫發送大量小型、短時間運行的查詢（或事務）。

OLTP 工作負載的一些特征是：

插入、更新和刪除只影響一行。 示例：將商品添加到用戶的購物車。

讀取操作僅從數據庫中讀取少數項目。 示例：為用戶列出購物車中的商品。

很少使用聚合， 當它們被使用時，它們僅用于小數據集。示例：獲取用戶購物車中所有商品的總價格。

創建此類工作負載的應用程序類型通常具有許多并發用戶，這些用戶每秒總共執行許多請求。因此，對于 OLTP 工作負載，數據庫能夠同時處理大量此類查詢非常重要。應用程序的響應時間通常也很重要，因此數據庫查詢不應該花費很長時間來運行。查詢應始終在不到 5 秒內完成，大多數查詢應在 100 毫秒內完成，甚至可能更快。

屬于 OLTP 類別的知名數據庫基準是 YCSB (full suite)、TPC-C (specification) 和 HammerDB TPROC-C (full suite)。人們通常感興趣的這些 OLTP 基準測試中有兩種類型的數字：

• YCSB: https://github.com/brianfrankcooper/YCSB/
• TPC-C: http://tpc.org/tpcc/default5.asp
• HammerDB TPROC-C: https://www.hammerdb.com/docs/ch03.html

TPS 吞吐量（每秒事務數）

查詢延遲，通常在不同的百分位數（p95 等）

OLAP（在線分析處理）工作負載

另一種常見的數據庫工作負載稱為 OLAP（在線分析處理）。這是經常在數據倉庫上運行的工作負載類型。

OLAP 工作負載的一些特征是：

定期批量插入數據。 新數據通常是從其他系統批量添加到數據庫中的。這通常在用戶不使用數據庫的一天中的特定時間完成，例如本地時區的午夜。

讀操作通常會讀取數據庫的大部分內容。 這樣做的常見原因是回答業務分析師的問題，或者有可以在季度股東大會上展示的結果。一些需要的問題示例：

去年最暢銷的 10 款產品是什么？

上個月有多少新客戶加入？

回頭客產生了多少收入？

幾乎每個查詢都使用聚合。 鑒于讀取操作讀取大部分數據庫聚合對于使這些數據易于被人類消化是必要的。

查詢量大且復雜。 要回答查詢，通常需要從多個不同的表中收集數據，或者需要將數據與同一個表中的不同數據進行比較。收集和組合這些數據的查詢通常在單個查詢中使用 SQL 的許多特性，例如 JOINs、CTEs、subqueries 和 window 函數。因為它們結合了如此多的特性，OLAP 查詢通常變得非常龐大和復雜。

與 OLTP 不同，OLAP 系統中的并發用戶通常并不多。通常一次只運行一個查詢（或幾個查詢）。這些查詢的響應時間也遠高于 OLTP 工作負載。OLAP 查詢通常需要幾秒鐘甚至幾分鐘才能完成。但當然，數據庫響應時間在 OLAP 工作負載中仍然很重要，并且等待超過 20 分鐘的查詢結果通常是不可接受的。

屬于 OLAP 類別的知名基準是 TPC-H (specification)、TPC-DS(specification) 和 HammerDB TPROC-H(full suite)。這些基準具有一組使用各種 SQL 功能的查詢，并且具有不同級別的復雜性和 JOIN 數量。

TPC-H: http://tpc.org/tpch/default5.asp

TPC-DS: http://tpc.org/tpcds/default5.asp

HammerDB TPROC-H: https://www.hammerdb.com/docs/ch11.html

OLAP 基準測試可以為您提供兩種不同的結果：

運行作為基準測試一部分的所有查詢需要多長時間

運行每個查詢需要多長時間，每個查詢單獨測量

HTAP（混合事務/分析處理）工作負載

另一個數據庫工作負載類別稱為 HTAP（混合事務/分析處理）。此類別包含結合了 OLTP 和 OLAP 工作負載方面的工作負載。因此，會有很多活躍用戶在做小事務，同時運行一些繁重的長時間運行的查詢。

對 HTAP 工作負載進行基準測試的挑戰

在不同的運行中比較 HTAP 基準測試得出的數據是非常困難的。這源于這樣一個事實: 每次運行基準測試，你會得到兩個數字，這些數字通常顯示出相反的相關性:

• OLTP? 部分的 TPS 吞吐量（每秒事務數）
• OLAP 部分運行分析查詢所需的時間（以秒為單位）

問題是隨著每秒事務數量的增加，分析查詢將需要更長的時間來運行。換句話說，當 TPS 增加時 (good)，OLAP 查詢需要更長的時間(bad)。有兩個原因：

• 更多的TPS 通常意味著機器的資源（cpu/disk）更忙于處理 OLTP 查詢。這樣做的副作用是這些資源不經常可供 OLAP 查詢使用。
• 一定比例的OLTP 事務會將數據插入到數據庫中。所以更高的 TPS，意味著數據庫中的數據量會增長得更快。這反過來意味著 OLAP 查詢將不得不讀取更多數據，從而變得更慢。

這些數字之間的反向相關性使得很難最終確定一個 HTAP 基準測試運行是否比另一個具有更好的結果。只有當且僅當兩個數字都更好時，您才能得出一個更好的結論。如果其中一個數字更好，而另一個數字更差，那么這就成為一個權衡問題：您可以決定您認為工作負載最重要的因素是什么：每秒 OLTP 事務的數量，或者運行 OLAP 查詢所需的時間。

比較您在網上找到的基準結果的 Dangers

與其自己運行基準測試，不如比較其他人在網上發布的數據。在比較其他人運行的基準時要小心一點：配置基準有很多不同的方法。所以，比較它們通常是蘋果和橙子。重要的幾個差異是：

• 它是否在生產基礎架構上運行？ 當關鍵的生產功能被禁用時，通常可以實現更多的性能。備份、高可用性 (HA) 或安全功能（如 TLS）等都會影響性能。
• 使用的數據集有多大？它是否適合RAM？ 從磁盤讀取比從 RAM 讀取慢得多。因此，如果所有數據都適合 RAM，那么對于基準測試的結果非常重要。
• 硬件是否過于昂貴？ 顯然，每月花費 500 美元的數據庫的性能預計會比每月花費 50,000 美元的數據庫差。
• 使用了什么基準實現？ 許多供應商發布了 TPC 基準規范的結果，其中基準是使用規范的自定義實現運行的。這些實現通常未經驗證，因此可能無法正確實現規范。

因此，雖然比較您在網上找到的數據庫基準數字是最容易的，但您可能也想用自己的數據運行自己的基準。

用于 OLTP 工作負載的 HammerDB TPROC-C

HammerDB 是一個易于使用的開源數據庫基準測試套件。 HammerDB 可用于運行 OLTP 或 OLAP 基準測試。 OLTP 稱為 TPROC-C1，基于 TPC-C 規范。OLAP 基準稱為 TPROC-H，它基于 TPC-H 規范。 HammerDB 為許多不同的數據庫實現了這些基準測試，這使得比較不同數據庫類型的結果變得容易。

HammerDB: https://www.hammerdb.com/

TPC-C: http://tpc.org/tpcc/default5.asp

TPC-H: http://tpc.org/tpch/default5.asphttp://tpc.org/tpch/default5.asp

我已經向 HammerDB 提交了幾個 PR 以改進基準測試套件。這些 PR 之一使 HammerDB TPROC-C 與 Citus 對 Postgres 的擴展一起工作（因此與分布式 PostgreSQL 一起工作）。另外兩個大大提高了將基準數據加載到 Postgres 的速度。我所有的 PR 都已被接受并在 HammerDB 4.4 中發布。因此，從 HammerDB 4.4 開始，您可以針對 Citus 運行 HammerDB TPROC-C 基準測試。

• ??https://github.com/TPC-Council/HammerDB/pulls?q=is%3Apr+author%3AJelteF??
• ??https://github.com/TPC-Council/HammerDB/releases/tag/v4.4??

HammerDB 為您提供的用于比較基準運行的主要數字稱為 NOPM（每分鐘新訂單數）。HammerDB 使用 NOPM 而不是 TPS（每秒事務數），以使 HammerDB 支持的不同數據庫之間的數量具有可比性。測量 NOPM 的方式是基于官方 TPC-C 規范中的 tpmC 指標——盡管在 HammerDB 中，它被稱為 NOPM 而不是 tpmC，因為 tpmC 在技術上用于官方的、經過全面審核的基準測試結果。

• ??https://www.hammerdb.com/blog/uncategorized/why-both-tpm-and-nopm-performance-metrics/??

如何使用 HammerDB、ARM、Bicep、tmux 和 cloud-init 在 Azure 上對 Citus 和 Postgres 進行基準測試

就像我在開頭提到的那樣，運行基準測試時最重要的是自動運行它們。根據我的經驗，您將（幾乎）重新運行相同的基準測試！

因此，我圍繞 HammerDB 創建了開源基準測試工具(GitHub repo)，以使運行基準測試更加容易—尤其是對于在 Azure 上運行的 Postgres 的 Citus 擴展。當您使用 Postgres 擴展時，涉及到兩層數據庫軟件：您既在 Postgres 數據庫上運行，也在 Postgres 擴展上運行。因此，我為 Citus 創建的開源基準測試自動化在 Azure Database for PostgreSQL 托管服務中的 Hyperscale (Citus) 選項上運行基準測試。

• ??https://github.com/citusdata/citus-benchmark/tree/master/azure??
• ??https://docs.microsoft.com/azure/postgresql/??
• ??https://docs.microsoft.com/azure/postgresql/hyperscale/??

我創建的基準測試工具使用各種東西使運行基準測試盡可能簡單：

Bicep 格式的 ARM 模板用于預配基準測試所需的所有 Azure 資源。 它預配了您需要的主要內容：Citus 數據庫集群，特別是 Azure Database for PostgreSQL 中的 Hyperscale (Citus) 服務器組。但它還提供了一個單獨的 VM，用于在其上運行基準測試程序 — 該 VM 也稱為“driver VM”。

• ??https://docs.microsoft.com/azure/azure-resource-manager/bicep/overview??
• ??https://docs.microsoft.com/azure/azure-resource-manager/templates/overview??

Tmux 用于在后臺運行基準測試。 沒有什么比在 5 小時后重新啟動 6 小時基準測試更糟糕的了，只是因為您的互聯網連接中斷了。Tmux 通過保持基準應用程序在后臺運行來解決這個問題，即使您斷開連接也是如此。

• ??https://github.com/tmux/tmux/wiki??

cloud-init 腳本用于啟動基準測試。 驅動程序 VM 的 ARM 模板包含一個 cloud-init 腳本，該腳本會在 Postgres 變得可訪問時自動啟動基準測試。這樣，您可以在開始配置過程后高枕無憂。配置數據庫和驅動程序 VM 后，基準測試將自動開始在后臺運行。

??https://docs.microsoft.com/azure/virtual-machines/linux/using-cloud-init??

在撰寫本文時，我創建的開源基準測試工具支持運行 HammerDB TPROC-C (OLTP) 和 CH-benCHmark 規范 (HTAP) 的自定義實現。但是，即使您想運行不同的基準測試，我創建的工具可能仍然對您非常有用。運行另一個基準測試時唯一需要更改的應該是 cloud-init 腳本中安裝和啟動基準測試的部分。隨時向存儲庫發送 PR 以添加對另一個基準測試的支持。

• ??https://github.com/citusdata/citus-benchmark/tree/master/azure??
• ??https://github.com/citusdata/citus-benchmark/blob/6052801fad5c360acfee203342bbe3c25f1d54b0/azure/driver-vm.bicep#L75-L81??

關于 Citus 數據庫配置的提示

除了自動化你的基準測試之外，還有一些與 Citus 和 Postgres 相關的事情，在運行基準測試時你應該記住：

• 不要忘記分發 Postgres 表！ 大多數基準測試工具沒有內置支持使用 Citus 擴展分發 Postgres 表，因此您需要添加一些分發表的步驟。如果可能，最好在加載數據之前執行此操作，這樣加載數據會更快。
• 選擇正確的分布列。 使用 Citus 分布表時，選擇正確的分布列很重要，否則性能會受到影響。什么是正確的分布列取決于基準中的查詢。幸運的是，我們提供了有關為您選擇正確分布列的建議的文檔。
• ??https://docs.citusdata.com/en/v10.2/sharding/data_modeling.html??

構建數據集后，在所有表上運行 VACUUM ANALYZE。否則，Postgres 統計信息可能完全錯誤，您可能會得到非常慢的查詢計劃。

確保您的 shard_count 是您擁有的 worker 數量的倍數。否則，分片無法在您的 worker 之間平均分配，并且一些 worker 會比其他 worker 獲得更多的負載。一個好的默認 shard_count 是 48，因為數字 48 可以被很多數字整除。

如何使用 citus-benchmark 工具運行 HammerDB 基準測試

就像我說的，我試圖讓運行基準測試盡可能簡單。因此，您需要做的就是運行這個簡單的命令（有關詳細說明，請查看“azure”目錄中的自述文件）：

• ??https://github.com/citusdata/ch-benchmark/tree/master/azure??

azure/bulk-run.sh azure/how-to-benchmark-blog.runs | tee -a results.csv

上面的命令將開始在 Hyperscale (Citus) 的生產基礎架構上的幾個不同集群大小上運行 HammerDB TPROC-C，這是 Azure Database for PostgreSQL 托管服務中的一個部署選項。這些基準運行的結果都收集在 results.csv 文件。

當您查看新創建的 results.csv 文件時，您會看到類似于 “c4+2w8” 的字符串：

• c4+2w8: 這只是一個簡短的說法，即該運行的集群有一個 4 vCore 協調器 (“c”) 和 2 個工作器 (“2w”)，兩者都有 8 vCore。

集群中存在的內核總數也顯示在括號中。

如您所見，當您向 Citus 集群添加更多 worker 時，NOPM 會不斷增加。這表明 Citus 兌現了橫向擴展的承諾：只需向 Azure Database for PostgreSQL 中的集群添加更多 Citus 節點，我們的性能就會提高。

在 Azure 上使用更大的 Citus 數據庫集群達到 200 萬 NOPM

上圖中的數字是使用相對較小的 Citus 集群收集的。該圖表的主要目的是向您展示使用 HammerDB 和我創建的開源基準測試工具獲取這些數字是多么容易。

如果增加每個數據庫節點上的 vCore 數量和/或增加 Citus 集群中的 worker 節點總數，則可能會在 Azure 上觀察到更高的 Citus 基準測試結果。我們在 SIGMOD ‘21 接受的論文中可以看到具有更多 vCore 的更高性能。我們使用了一個協調器和 8 個 16 核的 worker，那篇論文中的 NOPM 高得多。

最近，我們還在一個非常大的 Citus 數據庫集群上運行了 HammerDB TPROC-C，并使用我們在 Azure 上的常規托管服務基礎架構獲得了高達 200 萬的 NOPM。

有關此 2M NOPM HammerDB 結果的更多詳細信息：

• 用于此基準測試的 Azure Database for PostgreSQL - Hyperscale (Citus) 數據庫集群有 64 個核協調器和 20 個工作節點，每個節點有 32 個核（因此總共 704 個核。）
• 除了使用比本文前面討論的示例運行更多的工作節點和每個節點更多的 vCore 之外(詳情見上面的圖2)，為了實現 2M NOPM，還需要修改另一件事: 需要配置HammerDB 以使用更多的并發連接。上面圖2所示的較早的示例基準測試運行使用了 250 個連接，但為了使這個大集群始終處于繁忙狀態，我將 HammerDB 配置為使用 5000 個連接。

Azure Database for PostgreSQL 中的 Hyperscale (Citus) 服務器組默認提供的連接數取決于協調器大小，系統將最大用戶連接數設置為 1000。要增加它，您只需聯系 Azure 支持并請求將 Postgres 14 上的最大用戶連接數增加到至少 5000 個——為了安全起見，多一點更好——對于您的超大規模 (Citus) 服務器組。因此，創建一個可以重現 2M NOPM 結果的超大規模 (Citus) 集群只需一張支持票即可。之后，您可以簡單地使用我的基準測試工具對該集群運行基準測試。

享受對數據庫性能進行基準測試的樂趣

比較數據庫或云提供商的性能似乎令人生畏。但是借助本博客中提供的知識和工具，在 Azure Database for PostgreSQL 中對 Hyperscale (Citus) 的數據庫性能進行基準測試應該會容易得多。在自己運行任何性能基準測試時，請確保：

• ??https://docs.microsoft.com/azure/postgresql/hyperscale/??

1. 選擇與您的工作負載相匹配的基準測試。 您的工作負載是否屬于 OLTP、OLAP 或 HTAP 類別？
2. 自動化運行基準測試。 ARM、Bicep、tmux 和 cloud-init 可以讓運行數據庫性能基準測試變得輕而易舉。您甚至可以重用我編寫的開源工具！

• ??https://docs.microsoft.com/en-gb/azure/azure-resource-manager/templates/overview??
• ??https://docs.microsoft.com/en-gb/azure/azure-resource-manager/bicep/overview?tabs=bicep??
• ??https://github.com/tmux/tmux/wiki??
• ??https://docs.microsoft.com/en-gb/azure/virtual-machines/linux/using-cloud-init??
• ??https://github.com/citusdata/citus-benchmark/tree/master/azure??

無論您是希望以自我管理的方式在 Citus 開源上運行您的應用程序，還是希望在 Azure 上的托管數據庫服務上運行應用程序，使用 Citus 擴展 Postgres 都很容易。

• ??https://www.citusdata.com/getting-started/??