公交车上荫蒂添的好舒服的电影-公用玩物(np双xing总受)-公用小荡货芊芊-公与妇仑乱hd-攻把受做哭边走边肉楼梯play-古装一级淫片a免费播放口

本內(nèi)容是對(duì)知名性能評(píng)測(cè)博主 Anton Putra MySQL vs PostgreSQL Performance Benchmark (Latency - Throughput - Saturation)^[1] 內(nèi)容的翻譯與整理, 有適當(dāng)刪減, 相關(guān)指標(biāo)和結(jié)論以原作為準(zhǔn)

MySQL vs PostgreSQL 數(shù)據(jù)庫(kù)性能對(duì)比

在本內(nèi)容中，我們將對(duì)比 MySQL 和 PostgreSQL 關(guān)系型數(shù)據(jù)庫(kù)的性能。我們將運(yùn)行一系列測(cè)試，其中 第一項(xiàng)測(cè)試 重點(diǎn)關(guān)注 數(shù)據(jù)寫(xiě)入（ingestion）效率。

首先，我們會(huì)測(cè)量：

• 數(shù)據(jù)插入請(qǐng)求的延遲，使用 p99 百分位數(shù) 進(jìn)行評(píng)估
• 數(shù)據(jù)庫(kù)的吞吐量，即每秒可處理的 請(qǐng)求數(shù)和插入數(shù)
• 數(shù)據(jù)庫(kù)的飽和度（saturation），即數(shù)據(jù)庫(kù)的負(fù)載情況，在這里我們主要關(guān)注：
• CPU 使用率
• 內(nèi)存使用率

此外，我們還會(huì)測(cè)量：

• 磁盤(pán)寫(xiě)入操作數(shù)
• 數(shù)據(jù)庫(kù)在磁盤(pán)上的存儲(chǔ)效率

值得一提的是，這兩種數(shù)據(jù)庫(kù)在這些方面的差異 非常大。

最后，我們將評(píng)估 數(shù)據(jù)庫(kù)的連接池（connection pool），觀察它們?nèi)绾喂芾聿迦霐?shù)據(jù)的連接。

在 第二項(xiàng)測(cè)試 中，我們將測(cè)量 數(shù)據(jù)讀取（retrieval） 的效率。

我使用的是當(dāng)前最新版本：

• PostgreSQL 17.0
• MySQL 9.0

測(cè)試設(shè)計(jì)

為了進(jìn)行測(cè)試，我在 兩個(gè)數(shù)據(jù)庫(kù) 中分別創(chuàng)建了 兩張表，具體的 SQL 語(yǔ)句如下。

假設(shè)我們有一個(gè) 分析系統(tǒng)（analytics backend），用于記錄 用戶(hù)在網(wǎng)站上的行為，例如：

• 登錄
• 登出
• 搜索
• 將商品加入購(gòu)物車(chē)

數(shù)據(jù)庫(kù)中有兩張表：

1. Customer 表
• 存儲(chǔ)用戶(hù)的 姓名、地址
• 設(shè)有 主鍵 ID
2. Event 表
• 設(shè)有 主鍵 ID
• 外鍵 指向 Customer 表的主鍵
• 記錄 用戶(hù)執(zhí)行的操作類(lèi)型（action type）

第一項(xiàng)測(cè)試：
我們將使用以下 SQL 語(yǔ)句插入數(shù)據(jù)，隨機(jī)生成客戶(hù) ID 和操作類(lèi)型。

第二項(xiàng)測(cè)試：
我們將在包含 約 7000 萬(wàn)條記錄 的數(shù)據(jù)庫(kù)上執(zhí)行 簡(jiǎn)單的 JOIN 查詢(xún)：

• 隨機(jī)生成一個(gè) event ID
• 查詢(xún)并連接 customer 表
• 返回用戶(hù)的姓名、地址和操作類(lèi)型

如果你有任何關(guān)于 改進(jìn)測(cè)試設(shè)計(jì) 的建議，請(qǐng)告訴我！

代碼概覽

在客戶(hù)端編寫(xiě)方面，我選擇使用 Golang，因?yàn)椋?/span>

• Golang 是一門(mén)流行的編程語(yǔ)言
• 它擁有成熟的數(shù)據(jù)庫(kù)驅(qū)動(dòng)庫(kù)

為了讓 MySQL 和 PostgreSQL 的測(cè)試盡可能公平，我使用 database/sql 接口 進(jìn)行數(shù)據(jù)庫(kù)操作，而不是直接使用 pgx 驅(qū)動(dòng)（盡管 pgx 可能會(huì)降低查詢(xún)延遲）。
但本次測(cè)試的重點(diǎn)是 對(duì)比數(shù)據(jù)庫(kù)本身的性能，而不是不同的驅(qū)動(dòng)實(shí)現(xiàn)。

此外，我確保：

• 執(zhí)行相同的 SQL 查詢(xún)
• 使用相同的數(shù)據(jù)庫(kù)連接配置

如果你有任何改進(jìn)建議，請(qǐng)告訴我，或者更好的是，提交一個(gè) Pull Request！

第一項(xiàng)測(cè)試：數(shù)據(jù)寫(xiě)入

現(xiàn)在，我們開(kāi)始 第一項(xiàng)測(cè)試。

這次測(cè)試 總共持續(xù)了近 3 小時(shí)，但我會(huì)將其壓縮至 幾分鐘 展示。
測(cè)試過(guò)程中，我們會(huì)：

• 部署多個(gè)客戶(hù)端
• 逐步增加負(fù)載
• 持續(xù)向數(shù)據(jù)庫(kù)發(fā)送請(qǐng)求
• 每 60 秒增加一個(gè)虛擬客戶(hù)端

你可以在 右上方的圖表 看到 每秒查詢(xún)數(shù)（QPS），而 左側(cè)圖表 顯示的是 從客戶(hù)端測(cè)量的插入延遲。

測(cè)試結(jié)果：

• 從一開(kāi)始，PostgreSQL 的插入延遲明顯低于 MySQL
• MySQL 插入數(shù)據(jù)的時(shí)間幾乎是 PostgreSQL 的兩倍
• PostgreSQL 的 CPU 使用率更低，意味著它有更大的吞吐能力
• PostgreSQL 占用的內(nèi)存也更少

最大區(qū)別：

• MySQL 需要更多的磁盤(pán)操作來(lái)存儲(chǔ)相同數(shù)量的記錄
• PostgreSQL 在磁盤(pán)上的存儲(chǔ)效率更高
• PostgreSQL 執(zhí)行的磁盤(pán)操作更少，數(shù)據(jù)占用空間也更小

連接池情況：

• 兩個(gè)數(shù)據(jù)庫(kù)的連接池最終都達(dá)到了 80 個(gè)連接
• 每個(gè)客戶(hù)端的最大連接數(shù)設(shè)置為 40
• 每個(gè)數(shù)據(jù)庫(kù)有 2 個(gè)客戶(hù)端在不斷生成負(fù)載

臨界點(diǎn)：

• 當(dāng) QPS 達(dá)到 5,500 時(shí)，MySQL 開(kāi)始跟不上 PostgreSQL
• MySQL 的延遲和 CPU 使用率激增，導(dǎo)致整體性能下降
• 當(dāng) QPS 達(dá)到 12,000 時(shí)，我為 PostgreSQL 額外添加了一個(gè)客戶(hù)端
• 最終，PostgreSQL 最高可處理 19,000 QPS（4 核 CPU + 直連 SSD）
• MySQL 最高只能處理 10,000 QPS，約為 PostgreSQL 的一半

第一項(xiàng)測(cè)試：數(shù)據(jù)分析

現(xiàn)在，我們查看 整個(gè)測(cè)試期間的數(shù)據(jù)：

1. 每秒查詢(xún)數(shù)（QPS）

1. 插入延遲（客戶(hù)端測(cè)量）

1. CPU 使用率

1. 總插入記錄數(shù)

• PostgreSQL 插入 約 6500 萬(wàn)條記錄
• MySQL 插入 約 5000 萬(wàn)條記錄
• 在第二項(xiàng)測(cè)試前，我會(huì)為 MySQL 增加一些記錄，使數(shù)據(jù)量一致

1. 內(nèi)存使用

1. 磁盤(pán)寫(xiě)入操作

1. 連接池大小

1. 數(shù)據(jù)庫(kù)大小
• PostgreSQL 存儲(chǔ)數(shù)據(jù)的 磁盤(pán)效率更高
• CPU 和磁盤(pán)操作占用更少
• PostgreSQL 在數(shù)據(jù)寫(xiě)入方面明顯優(yōu)于 MySQL

第二項(xiàng)測(cè)試：數(shù)據(jù)讀取

在運(yùn)行 第二項(xiàng)測(cè)試 之前，我為 MySQL 額外添加了一些記錄，使其與 PostgreSQL 的數(shù)據(jù)量保持一致。

測(cè)試內(nèi)容：

• 查詢(xún) event 表中的數(shù)據(jù)
• 通過(guò) event ID 進(jìn)行 JOIN
• 返回用戶(hù)的姓名、地址和操作類(lèi)型
• 測(cè)試前，重啟兩個(gè)數(shù)據(jù)庫(kù)，以清除緩存

磁盤(pán)讀取數(shù)據(jù)問(wèn)題：

• 由于可能的配置錯(cuò)誤，我沒(méi)有獲取到 PostgreSQL 的磁盤(pán)讀取數(shù)據(jù)
• 但我仍然有 MySQL 的磁盤(pán)操作數(shù)據(jù)

測(cè)試結(jié)果：

• 延遲差距不像第一項(xiàng)測(cè)試那么大
• 但 PostgreSQL 仍然比 MySQL 低延遲
• MySQL 的 CPU 使用率 顯著高于 PostgreSQL
• 這個(gè)趨勢(shì)一直持續(xù)，直到 MySQL 達(dá)到 CPU 使用瓶頸，性能下降

臨界點(diǎn)：

• 當(dāng) QPS 達(dá)到 18,000 時(shí)，MySQL 的性能下降更明顯
• MySQL 的延遲出現(xiàn)波動(dòng)，而 PostgreSQL 仍然保持穩(wěn)定
• 當(dāng) QPS 達(dá)到 20,000 時(shí)，MySQL 無(wú)法再處理更多查詢(xún)
• 我為 PostgreSQL 額外增加了一個(gè)客戶(hù)端，加速測(cè)試
• 最終，PostgreSQL 在 32,000 QPS 時(shí)達(dá)到 90% CPU 使用率，開(kāi)始下降

結(jié)論：

• 在數(shù)據(jù)寫(xiě)入和讀取方面，PostgreSQL 都比 MySQL 更高效
• 如果你有任何改進(jìn)建議，例如更改客戶(hù)端代碼或測(cè)試設(shè)計(jì)，請(qǐng)告訴我！

第二項(xiàng)測(cè)試：數(shù)據(jù)分析

現(xiàn)在，我們查看 整個(gè)測(cè)試期間的數(shù)據(jù)：

1. 每秒查詢(xún)數(shù)（QPS）

1. 數(shù)據(jù)讀取延遲

1. CPU 使用率

1. 內(nèi)存使用

1. 數(shù)據(jù)庫(kù)連接數(shù)

1. 磁盤(pán)讀取操作