使用 HammerDB 對 Citus 和 Postgres 進行 Benchmark，每分鐘200萬新訂單處理測試(官方部落格)

  • 2022 年 10 月 4 日
  • 筆記

image

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

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

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

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

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

  • 針對不同工作負載的不同基準
  • 基準規範與完整的基準測試套件
  • OLTP 工作負載
  • OLAP 工作負載
  • HTAP 工作負載
  • 比較基準測試結果的 Dangers
  • HammerDB TPROC-C
  • 如何使用 HammerDB、ARM、Bicep 和 cloud-init 對 Citus 進行基準測試
  • 在 Azure 上使用更大的 Citus 資料庫集群達到 200 萬 NOPM
  • 享受對資料庫性能進行基準測試的樂趣

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

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

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

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

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

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

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

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

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

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

  • 插入、更新和刪除隻影響一行。 示例：將商品添加到用戶的購物車。
  • 讀取操作僅從資料庫中讀取少數項目。 示例：為用戶列出購物車中的商品。
  • 很少使用聚合， 當它們被使用時，它們僅用於小數據集。 示例：獲取用戶購物車中所有商品的總價格。

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

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

  1. TPS 吞吐量（每秒事務數）
  2. 查詢延遲，通常在不同的百分位數（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 數量。

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

  1. 運行作為基準測試一部分的所有查詢需要多長時間
  2. 運行每個查詢需要多長時間，每個查詢單獨測量

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

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

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

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

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

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

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

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

image

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

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

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

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

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

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

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

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

如何使用 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) 選項上運行基準測試。

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

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

關於 Citus 資料庫配置的提示

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

  1. 不要忘記分發 Postgres 表！ 大多數基準測試工具沒有內置支援使用 Citus 擴展分發 Postgres 表，因此您需要添加一些分發表的步驟。 如果可能，最好在載入數據之前執行此操作，這樣載入數據會更快。
  2. 選擇正確的分布列。 使用 Citus 分布表時，選擇正確的分布列很重要，否則性能會受到影響。 什麼是正確的分布列取決於基準中的查詢。 幸運的是，我們提供了有關為您選擇正確分布列的建議的文檔。
  3. 構建數據集後，在所有表上運行 VACUUM ANALYZE。否則，Postgres 統計資訊可能完全錯誤，您可能會得到非常慢的查詢計劃。
  4. 確保您的 shard_count 是您擁有的 worker 數量的倍數。否則，分片無法在您的 worker 之間平均分配，並且一些 worker 會比其他 worker 獲得更多的負載。一個好的默認 shard_count 是 48，因為數字 48 可以被很多數字整除。

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

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

# 重要說明：運行此命令將在您的 Azure 訂閱中配置 4 個新的 Citus 集群
# 和 4 個 64-vCore driver VM。 
# 因此，運行以下命令將花費您（或您的僱主）的錢！
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。

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

image

如您所見，當您向 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) 的資料庫性能進行基準測試應該會容易得多。 在自己運行任何性能基準測試時，請確保：

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

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

Tags:

VirMach 便宜 VPS