背景信息

在業(yè)務(wù)架構(gòu)設(shè)計(jì)中，數(shù)據(jù)庫模型設(shè)計(jì)是至關(guān)重要的一環(huán)。由于單機(jī)計(jì)算和存儲能力的限制，許多業(yè)務(wù)架構(gòu)師不得不考慮對大表進(jìn)行拆分，通過中間件或其他手段實(shí)現(xiàn)分庫分表，以便提升資源的擴(kuò)展能力。因此，在MySQL生態(tài)中流傳著一個經(jīng)驗(yàn)法則：單表行數(shù)建議不要超過500萬行。一般來說，分庫分表方案解決了以下幾個主要問題：本地存儲不足、計(jì)算能力不足以及大表的運(yùn)維復(fù)雜性。

隨著數(shù)據(jù)量的日益增長，運(yùn)維團(tuán)隊(duì)為了確保業(yè)務(wù)的穩(wěn)定性，不得不開始考慮數(shù)據(jù)拆分的問題。由于分庫分表帶來的兼容性挑戰(zhàn)，業(yè)務(wù)代碼也需進(jìn)行相應(yīng)的修改，這意味著開發(fā)團(tuán)隊(duì)需要參與架構(gòu)改造，并重寫SQL語句以適應(yīng)新的分庫分表結(jié)構(gòu)。業(yè)務(wù)團(tuán)隊(duì)往往將重點(diǎn)放在業(yè)務(wù)發(fā)展上，在此期間難以抽出精力進(jìn)行系統(tǒng)的拆分。這導(dǎo)致拆分工作只能不斷推遲，直到最終不得不執(zhí)行。在此期間，整體系統(tǒng)的穩(wěn)定性始終面臨風(fēng)險。

在MySQL生態(tài)中，通常建議單表的行數(shù)不超過500萬行，這一準(zhǔn)則背后有其深厚的歷史背景。這一限制主要源于性能優(yōu)化和管理維護(hù)的考慮。從資源的角度來看，早期服務(wù)器的IO能力較低，較大的單表會增加B-tree索引的高度，進(jìn)而導(dǎo)致IO性能問題。同時，磁盤容量也相對有限。因此，需要考慮存儲上限和備份空間的問題。從運(yùn)維角度來看，舊版本的MySQL（5.5之前）基本不支持在線DDL。在對大表進(jìn)行維護(hù)時，這可能會導(dǎo)致業(yè)務(wù)出現(xiàn)異常。

PolarDB采用共享分布式存儲架構(gòu)，與傳統(tǒng)MySQL數(shù)據(jù)庫相比，提供了顯著更強(qiáng)的大表處理能力。許多傳統(tǒng)的分庫分表場景變得不再必要。目前，PolarDB公有云已有大量用戶的單表數(shù)據(jù)超過10 TB或10億行。分庫分表相較于單表會帶來極大的復(fù)雜性提升，因此，在非必要的情況下，不應(yīng)過早進(jìn)行過度優(yōu)化。

本地存儲能力優(yōu)化

海量彈性存儲空間

在許多業(yè)務(wù)快速發(fā)展的階段，面對海量數(shù)據(jù)的存儲需求，企業(yè)往往會考慮進(jìn)行數(shù)據(jù)拆分。然而，這種考慮并不是計(jì)算能力遇到瓶頸，更多時候是因?yàn)閱我患旱拇鎯θ萘窟_(dá)到了上限。最初設(shè)計(jì)時，如果未能充分考慮數(shù)據(jù)的海量存儲方式，或者是在業(yè)務(wù)邏輯中無法進(jìn)行有效的清理或歸檔，那么就可能面臨存儲瓶頸。

PolarDB采用了計(jì)算存儲分離和共享分布式存儲架構(gòu)。與傳統(tǒng)數(shù)據(jù)庫MySQL相比，PolarDB的分布式存儲設(shè)計(jì)使其集群最大支持1 PB的存儲空間。PolarDB存儲架構(gòu)是由一組通過RDMA硬件連接的Chunk Server（PFS 技術(shù)），為上層提供塊設(shè)備接口。計(jì)算節(jié)點(diǎn)則通過RDMA網(wǎng)絡(luò)將存儲掛載到計(jì)算節(jié)點(diǎn)中，底層的Chunk對計(jì)算過程是完全透明。

這一近乎海量的存儲空間，使您不用再為磁盤容量限制和擴(kuò)縮容問題苦惱，只需專注于業(yè)務(wù)的需求設(shè)計(jì)。無需進(jìn)行復(fù)雜的數(shù)據(jù)拆分（如分庫分表），這大大降低了業(yè)務(wù)系統(tǒng)的復(fù)雜程度。

計(jì)算能力優(yōu)化

索引并發(fā)控制的優(yōu)化

限制單集群性能的一個主要因素是大表性能問題。為了有效解決這一問題，PolarDB進(jìn)行了深入的探索和驗(yàn)證。針對大表的插入場景的痛點(diǎn)，仔細(xì)研究了各個模塊機(jī)制中的瓶頸，并進(jìn)行了相應(yīng)的優(yōu)化。經(jīng)過基準(zhǔn)測試和實(shí)踐業(yè)務(wù)場景的驗(yàn)證，實(shí)現(xiàn)了最高可達(dá)10倍的性能提升。

PolarDB對單集群的索引大鎖進(jìn)行了優(yōu)化，創(chuàng)新性地引入了支持并發(fā)分裂的Polar Index，從而顯著降低了大量并發(fā)訪問時的沖突開銷。在公有云線上業(yè)務(wù)的實(shí)際場景中，性能提升達(dá)到了3倍，而在高并發(fā)TPC-C場景下，性能更是提升了11倍。

表文件擴(kuò)展優(yōu)化

隨著數(shù)據(jù)的不斷寫入，數(shù)據(jù)表文件的擴(kuò)展是不可避免的。高頻的數(shù)據(jù)插入會增加表空間擴(kuò)展的頻率。在MySQL中，表空間的擴(kuò)展是一個比較消耗系統(tǒng)資源的操作，因此，高頻的擴(kuò)展操作會直接影響事務(wù)的執(zhí)行性能。為優(yōu)化大表插入場景中的文件擴(kuò)展開銷，PolarDB基于自研的分布式文件系統(tǒng)，在表文件擴(kuò)展過程中，減少對文件系統(tǒng)元信息的修改。這一設(shè)計(jì)使得文件擴(kuò)展時鎖的開銷不再成為瓶頸，從而顯著提升了PolarDB在大批量數(shù)據(jù)寫入場景下的性能。

Redo日志寫入優(yōu)化

高負(fù)載的插入操作必然會產(chǎn)生大量的Redo日志。為了確保事務(wù)的持久性，事務(wù)必須在所有Redo日志成功寫入磁盤后才能返回。因此，Redo日志的寫入延遲和吞吐量直接影響著數(shù)據(jù)庫的性能。PolarDB創(chuàng)新性地推出了Redo并行寫入機(jī)制，有效地解決了大表日志落盤的痛點(diǎn)。目前，Redo日志的最高吞吐量已達(dá)到4 GB/s，而單集群的IO吞吐極限更是高達(dá)5.2 GB/s。

邏輯預(yù)讀、IO調(diào)度、并行二級索引插入優(yōu)化

整體而言，針對云上數(shù)據(jù)庫的痛點(diǎn)（結(jié)合線上經(jīng)驗(yàn)與系統(tǒng)實(shí)驗(yàn)），PolarDB在單集群處理大表時的性能能夠滿足絕大多數(shù)業(yè)務(wù)需求。

性能測試

作為對照，我們分別使用Sysbench工具向PolarDB插入400億行數(shù)據(jù)（10 TB）和40億行數(shù)據(jù)（1 TB）、500萬行數(shù)據(jù)（125 GB）的測試實(shí)驗(yàn)。整體來看，在高并發(fā)場景下，單個大表的性能與單個小表的性能基本相當(dāng)。此外，真實(shí)生產(chǎn)環(huán)境中不會像壓測場景出現(xiàn)如此密集的寫入導(dǎo)致臟頁一直維持在非常高的水位。完全可以承載一般業(yè)務(wù)流量。