近期,騰訊雲資料庫在文章「騰訊雲TDSQL-C重磅升級,效能全面領跑雲原生資料庫市場」中提到,某些場景下效能有非常大的提升,且超過國內某橙色雲廠商。恰好,在5月份,我們對各個廠商的雲原生資料庫進行過一次壓測,所以,看到文章,我們第一時間做了驗證。具體的,驗證內容包括:
當前的TDSQL-C效能與五月份相比,是否有明顯增強
不同廠商的雲原生資料庫效能是否有明顯變化
具體的資訊檢視:「再測雲原生資料庫效能:PolarDB依舊最強,TDSQL-C、GaussDB變化不大」,該內容同步釋出於微信公眾號:「雲資料庫技術」,歡迎訂閱,第一時間獲取資訊。
測試下來,暫時沒有感受到TDSQL-C 「重磅升級」 。針對這個問題也通過工單方式諮詢了騰訊雲的服務人員,得到的答覆是:TDSQL-C 的全面升級還沒有覆蓋所有的地域,目前只在指定地域上線,且還需要開通白名單。
事實證明,白興奮一場,只能等後續新版本更大範圍開放後再測試了。另外,也希望廠商在宣傳的時候,說得更清楚一些,否則會讓客戶困惑。
這裡對我們的測試方式做一個詳細說明。本次測試選擇了各個廠商的4c16g的規格進行橫向對比,使用了工具sysbench 1.0.20版本進行測試。具體的,在「讀寫」、「唯讀」、「只寫」3個場景下進行2~512個執行緒的壓測, 獲取每秒執行事務數TPS(Transactions Per Second)、每秒執行請求數QPS(Queries Per Second)來作為效能對比指標。
測試的資料庫規格:
各個雲廠商的雲原生資料庫都使用預設設定引數(開箱即用)。
使用者端規格:
測試命令:
-- 準備資料 sysbench --db-driver=mysql --mysql-host=XXX --mysql-port=XXX --mysql-user=XXX --mysql-password=XXX --mysql-db=sbtest --table_size=10000000 --tables=10 --events=0 --time=300 --threads={2~512} oltp_read_write prepare -- 執行workload # OLTP讀寫混合 sysbench --db-driver=mysql --mysql-host=XXX --mysql-port=XXX --mysql-user=XXX --mysql-password=XXX --mysql-db=sbtest --table_size=10000000 --tables=10 --events=0 --time=300 --threads={2~512} --percentile=95 --report-interval=1 oltp_read_write run # OLTP唯讀場景 sysbench --db-driver=mysql --mysql-host=XXX --mysql-port=XXX --mysql-user=XXX --mysql-password=XXX --mysql-db=sbtest --table_size=10000000 --tables=10 --events=0 --time=300 --threads={2~512} --percentile=95 --report-interval=1 oltp_read_only run # OLTP只寫場景 sysbench --db-driver=mysql --mysql-host=XXX --mysql-port=XXX --mysql-user=XXX --mysql-password=XXX --mysql-db=sbtest --table_size=10000000 --tables=10 --events=0 --time=300 --threads={2~512} --percentile=95 --report-interval=1 oltp_write_only run -- 清理資料 sysbench --db-driver=mysql --mysql-host=XXX --mysql-port=XXX --mysql-user=XXX --mysql-password=XXX --mysql-db=sbtest --table_size=10000000 --tables=10 --events=0 --time=300 --threads={2~512} --percentile=95 oltp_read_write/oltp_read_only/oltp_write_only cleanup
說明:10張表,每張表1000萬資料,資料集約25G,2~512個執行緒進行壓測。
補充說明:阿里雲使用:主地址(高可用地址,用RW表示)和 叢集地址(自動讀寫分離地址,用Proxy表示)
騰訊雲使用:讀寫內網地址(高可用地址,用RW表示)和 唯讀內網地址(高可用地址,用RO表示)
華為雲使用:讀寫內網地址(高可用地址,用RW表示)和 資料庫代理地址(自動讀寫分離地址,用Proxy表示),還有直連後端Server節點(單點)地址(用SRW和SRO表示)。
使用Proxy時需要注意:
Proxy有一定的鏈路開銷,在沒有使用到讀寫分離的情況下,效能會降低。
騰訊雲暫不支援自動讀寫分離Proxy;阿里雲的Porxy在自動讀寫分離上支援的最好;華為雲的Proxy需要開啟引數--skip-trx(非事務模式)才能使用從節點,支援的不友好(本文測試沒有開啟該引數)。
華為雲Proxy受CPU和寬頻限制:
CPU個數小於"16":50MB CPU個數小於"32":100MB, CPU個數小於"64":200MB, CPU個數小於"128":400MB CPU個數小於"256":1000MB, 最大2000MB
4.1 TDSQL-C 升級之後是否有提升?
從表中資料的對比看到:2次壓測資料效能差距不大,TDSQL-C效能沒有提升,原因見「測試結果」中的說明。
4.2 TDSQL-C效能有沒有超越業內其他雲原生資料庫產品?
讀寫場景:
讀寫場景結論
不算Proxy的情況下,效能上「阿里雲-RW」比「華為雲-RW」高12%,比「騰訊雲-RW」高37%。
算上Proxy的情況下,效能上「阿里雲-Proxy」比「阿里雲-RW」高47%;「華為雲-Proxy」比「華為雲-RW」低24%,「阿里雲-Proxy」比「華為雲-Proxy」高61%。
華為雲Proxy效能低的原因是其Proxy不支援事務拆分,雖然通過Proxy地址,但也只在主節點上執行(未開啟--skip-trx引數:是否跳過SQL語句開頭的begin和結尾的commit)。
從QPS和TPS的平均值之和,效能從高到低依次排序為:「阿里雲-Proxy」> 「阿里雲-RW」> 「華為雲-RW」 > 「騰訊雲-RW」 > 「華為雲-Proxy」
唯讀場景:
唯讀場景結論:
不算Proxy的情況下,效能上「阿里雲-RW」比「華為雲-RW」高11%,比「騰訊雲-RW」高56%。
算上Proxy的情況下,效能上「阿里雲-Proxy」比「阿里雲-RW」高14%;「華為雲-Proxy」比「華為雲-RW」低27%;「阿里雲-Proxy」比「華為雲-Proxy」高100%。
華為雲Proxy效能低的原因是其Proxy不支援事務拆分,雖然通過Proxy地址,但也只在主節點上執行(未開啟--skip-trx引數:是否跳過SQL語句開頭的begin和結尾的commit)。
從QPS和TPS的平均值之和,效能從高到低依次排序為:「阿里雲-Proxy」> 「阿里雲-RW」> 「華為雲-RW」 > 「華為雲-Proxy」>「騰訊雲-RW」
只寫場景:
只寫場景結論:
不算Proxy的情況下,效能上「阿里雲-RW」比「華為雲-RW」高21%,比「騰訊雲-RW」高60%。
算上Proxy的情況下,效能上「阿里雲-RW」比「阿里雲-Proxy」高7%;「華為雲-RW」比「華為雲-Proxy」高18%;「阿里雲-Proxy」比「華為雲-Proxy」高35%。
Proxy效能低的原因是代理在增加了鏈路的前提下,寫都在主節點。
從QPS和TPS的平均值之和,效能從高到低依次排序為:「阿里雲-RW」> 「阿里雲-Proxy」> 「華為雲-RW」 > 「華為雲-Proxy」 > 「騰訊雲-RW」
通過以上三個場景的壓測對比,可以看到TDSQL-C效能沒有超越業內其他雲原生資料庫產品,原因見本文「測試結果」中的說明。
得到的資料是在TDSQL-C還沒有升級的情況下壓測的,通過各場景得出的QPS、TPS 的平均值之和來對比,結果如下:
讀寫場景下:「阿里雲-Proxy」> 「阿里雲-RW」> 「華為雲-RW」 > 「華為雲-Proxy」>「騰訊雲-RW」
唯讀場景下:「阿里雲-Proxy」> 「阿里雲-RW」> 「華為雲-RW」 > 「華為雲-Proxy」>「騰訊雲-RW」
只寫場景下:「阿里雲-RW」> 「阿里雲-Proxy」> 「華為雲-RW」 > 「華為雲-Proxy」 > 「騰訊雲-RW」
通過壓測資料,看到當前效能最好的依舊是PolarDB。特別在自動讀寫分離(Proxy)的功能上,阿里雲優勢大於華為雲(不支援事務拆分)和騰訊雲(不支援讀寫分離地址)。也非常期待TDSQL-C 在「重磅升級」 之後帶來的效能提升。
後續等TDSQL-C升級覆蓋到更多地域之後,再進行測試驗證。希望通過本文,對大家在選擇雲廠商的雲原生資料庫產品時有幫助。