使用 HammerDB 對(duì) Citus 和 Postgres 進(jìn)行 Benchmark，每分鐘200萬新訂單處理測試

作者：為少 2022-10-08 00:05:00

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

在為 Postgres 運(yùn)行性能基準(zhǔn)測試時(shí)，主要建議是：“自動(dòng)化！”

如果您正在測量數(shù)據(jù)庫性能，您可能不得不一遍又一遍地運(yùn)行相同的基準(zhǔn)測試。要么是因?yàn)槟阆胍粋€(gè)稍微不同的配置，要么是因?yàn)槟阋庾R(shí)到你使用了一些錯(cuò)誤的設(shè)置，或者可能是其他一些原因。通過自動(dòng)化運(yùn)行性能基準(zhǔn)測試的方式，當(dāng)發(fā)生這種情況時(shí)您不會(huì)太煩惱，因?yàn)橹匦逻\(yùn)行基準(zhǔn)測試將花費(fèi)很少的精力（它只會(huì)花費(fèi)一些時(shí)間）。

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

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

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

為什么要先深入了解不同工作負(fù)載和數(shù)據(jù)庫基準(zhǔn)測試的背景？因?yàn)橛斜茸詣?dòng)化運(yùn)行性能基準(zhǔn)的方式更重要的事情：為您選擇正確的基準(zhǔn)！

針對(duì)不同工作負(fù)載的不同基準(zhǔn)

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

OLTP 工作負(fù)載
OLAP 工作負(fù)載
HTAP 工作負(fù)載

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

針對(duì)不同類型工作負(fù)載的不同類型基準(zhǔn)測試

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

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

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

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

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

很明顯，完整的基準(zhǔn)測試套件通常是您想要的，因?yàn)槟梢院唵蔚貑?dòng)基準(zhǔn)測試應(yīng)用程序并獲得結(jié)果。如果您只有一個(gè)基準(zhǔn)測試規(guī)范，那么您首先需要編寫工具來針對(duì)數(shù)據(jù)庫運(yùn)行該規(guī)范。

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

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

OLTP 工作負(fù)載的一些特征是：

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

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

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

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

屬于 OLTP 類別的知名數(shù)據(jù)庫基準(zhǔn)是 YCSB (full suite)、TPC-C (specification) 和 HammerDB TPROC-C (full suite)。人們通常感興趣的這些 OLTP 基準(zhǔn)測試中有兩種類型的數(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 吞吐量（每秒事務(wù)數(shù)）

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

OLAP（在線分析處理）工作負(fù)載

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

OLAP 工作負(fù)載的一些特征是：

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

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

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

上個(gè)月有多少新客戶加入？

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

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

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

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

屬于 OLAP 類別的知名基準(zhǔn)是 TPC-H (specification)、TPC-DS(specification) 和 HammerDB TPROC-H(full suite)。這些基準(zhǔn)具有一組使用各種 SQL 功能的查詢，并且具有不同級(jí)別的復(fù)雜性和 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 基準(zhǔn)測試可以為您提供兩種不同的結(jié)果：

運(yùn)行作為基準(zhǔn)測試一部分的所有查詢需要多長時(shí)間

運(yùn)行每個(gè)查詢需要多長時(shí)間，每個(gè)查詢單獨(dú)測量

HTAP（混合事務(wù)/分析處理）工作負(fù)載

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

對(duì) HTAP 工作負(fù)載進(jìn)行基準(zhǔn)測試的挑戰(zhàn)

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

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

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

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

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

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

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

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

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

用于 OLTP 工作負(fù)載的 HammerDB TPROC-C

HammerDB 是一個(gè)易于使用的開源數(shù)據(jù)庫基準(zhǔn)測試套件。 HammerDB 可用于運(yùn)行 OLTP 或 OLAP 基準(zhǔn)測試。 OLTP 稱為 TPROC-C1，基于 TPC-C 規(guī)范。OLAP 基準(zhǔn)稱為 TPROC-H，它基于 TPC-H 規(guī)范。 HammerDB 為許多不同的數(shù)據(jù)庫實(shí)現(xiàn)了這些基準(zhǔ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 提交了幾個(gè) PR 以改進(jìn)基準(zhǔn)測試套件。這些 PR 之一使 HammerDB TPROC-C 與 Citus 對(duì) Postgres 的擴(kuò)展一起工作（因此與分布式 PostgreSQL 一起工作）。另外兩個(gè)大大提高了將基準(zhǔn)數(shù)據(jù)加載到 Postgres 的速度。我所有的 PR 都已被接受并在 HammerDB 4.4 中發(fā)布。因此，從 HammerDB 4.4 開始，您可以針對(duì) Citus 運(yùn)行 HammerDB TPROC-C 基準(zhǔn)測試。

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

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

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

如何使用 HammerDB、ARM、Bicep、tmux 和 cloud-init 在 Azure 上對(duì) Citus 和 Postgres 進(jìn)行基準(zhǔn)測試

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

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

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

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

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

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

Tmux 用于在后臺(tái)運(yùn)行基準(zhǔn)測試。沒有什么比在 5 小時(shí)后重新啟動(dòng) 6 小時(shí)基準(zhǔn)測試更糟糕的了，只是因?yàn)槟幕ヂ?lián)網(wǎng)連接中斷了。Tmux 通過保持基準(zhǔn)應(yīng)用程序在后臺(tái)運(yùn)行來解決這個(gè)問題，即使您斷開連接也是如此。

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

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

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

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

??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ù)庫配置的提示

除了自動(dòng)化你的基準(zhǔn)測試之外，還有一些與 Citus 和 Postgres 相關(guān)的事情，在運(yùn)行基準(zhǔn)測試時(shí)你應(yīng)該記住：

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

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

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

如何使用 citus-benchmark 工具運(yùn)行 HammerDB 基準(zhǔn)測試

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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