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

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

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

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

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

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

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

基準規(guī)范與完整的基準測試套件

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

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

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

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

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

基準規(guī)范與完整的基準套件

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

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

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

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

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

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

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

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

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

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

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

• 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 吞吐量（每秒事務數(shù)）

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

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

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

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

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

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

去年最暢銷的 10 款產(chǎn)品是什么？

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

回頭客產(chǎn)生了多少收入？

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

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

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

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

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 基準測試可以為您提供兩種不同的結(jié)果：

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

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

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

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

對 HTAP 工作負載進行基準測試的挑戰(zhàn)

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

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

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

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

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

比較您在網(wǎng)上找到的基準結(jié)果的 Dangers

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

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

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

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

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

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

我已經(jīng)向 HammerDB 提交了幾個 PR 以改進基準測試套件。這些 PR 之一使 HammerDB TPROC-C 與 Citus 對 Postgres 的擴展一起工作（因此與分布式 PostgreSQL 一起工作）。另外兩個大大提高了將基準數(shù)據(jù)加載到 Postgres 的速度。我所有的 PR 都已被接受并在 HammerDB 4.4 中發(fā)布。因此，從 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 為您提供的用于比較基準運行的主要數(shù)字稱為 NOPM（每分鐘新訂單數(shù)）。HammerDB 使用 NOPM 而不是 TPS（每秒事務數(shù)），以使 HammerDB 支持的不同數(shù)據(jù)庫之間的數(shù)量具有可比性。測量 NOPM 的方式是基于官方 TPC-C 規(guī)范中的 tpmC 指標——盡管在 HammerDB 中，它被稱為 NOPM 而不是 tpmC，因為 tpmC 在技術(shù)上用于官方的、經(jīng)過全面審核的基準測試結(jié)果。

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

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

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

因此，我圍繞 HammerDB 創(chuàng)建了開源基準測試工具(GitHub repo)，以使運行基準測試更加容易—尤其是對于在 Azure 上運行的 Postgres 的 Citus 擴展。當您使用 Postgres 擴展時，涉及到兩層數(shù)據(jù)庫軟件：您既在 Postgres 數(shù)據(jù)庫上運行，也在 Postgres 擴展上運行。因此，我為 Citus 創(chuàng)建的開源基準測試自動化在 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/??

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

Bicep 格式的 ARM 模板用于預配基準測試所需的所有 Azure 資源。 它預配了您需要的主要內(nèi)容：Citus 數(shù)據(jù)庫集群，特別是 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 小時基準測試更糟糕的了，只是因為您的互聯(lián)網(wǎng)連接中斷了。Tmux 通過保持基準應用程序在后臺運行來解決這個問題，即使您斷開連接也是如此。

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

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

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

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

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

關(guān)于 Citus 數(shù)據(jù)庫配置的提示

除了自動化你的基準測試之外，還有一些與 Citus 和 Postgres 相關(guān)的事情，在運行基準測試時你應該記?。?/p>

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

構(gòu)建數(shù)據(jù)集后，在所有表上運行 VACUUM ANALYZE。否則，Postgres 統(tǒng)計信息可能完全錯誤，您可能會得到非常慢的查詢計劃。

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

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

就像我說的，我試圖讓運行基準測試盡可能簡單。因此，您需要做的就是運行這個簡單的命令（有關(guān)詳細說明，請查看“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) 的生產(chǎn)基礎(chǔ)架構(gòu)上的幾個不同集群大小上運行 HammerDB TPROC-C，這是 Azure Database for PostgreSQL 托管服務中的一個部署選項。這些基準運行的結(jié)果都收集在 results.csv 文件。

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

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

集群中存在的內(nèi)核總數(shù)也顯示在括號中。

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

在 Azure 上使用更大的 Citus 數(shù)據(jù)庫集群達到 200 萬 NOPM

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

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

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

有關(guān)此 2M NOPM HammerDB 結(jié)果的更多詳細信息：

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

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

享受對數(shù)據(jù)庫性能進行基準測試的樂趣

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

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

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

• ??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 上的托管數(shù)據(jù)庫服務上運行應用程序，使用 Citus 擴展 Postgres 都很容易。

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