最佳實務 - - 阿里雲

適用情境

需要對接分散式資料庫的使用者的應用情境總是多種多樣的。PolarDB-X 2.0結合新老應用的庫表使用、SQL複雜情況以及對效能吞吐的要求，將使用者的應用情境大體上劃分為四種典型類型，如下表所示：

應用類型	樣本	總體概況	SQL 特點
大量存量業務的應用	某醫學公司或醫院已使用10+年的業務系統，系統存在大量舊業務。	存量業務的庫表非常多。庫數目≥10或表數目≥100。業務SQL查詢的種類複雜多樣。應用遇到單機資源瓶頸，業務查詢回應時間的越來越慢，需要最佳化。	資料庫要服務大量的老舊應用，存在眾多歷史業務的資料庫或業務表，並且庫表數量很大。存在大量業務老舊複雜SQL，且不能修改。
混合存量業務與新業務的應用	某經營多年的商家訂單管理系統，且系統要開發新功能。	存量業務庫表眾多。庫數目≥2或表數目≥10。新業務：業務有大表且資料增長快，單機資源即將不足，需要擴充。	業務庫表數目偏多。存在大量存量業務SQL，且大部分不能修改。新業務的部分大表及SQL接受改造及最佳化。
基於單機MySQL 開發的新業務應用	某攝影公司新開發的業務系統，需要快速上線。	庫表數目較少，業務規模較小。庫數目<2或表數目<10。預期未來的資料增量較大，需要擴充性。	業務初期追求快速上線，後期會快速迭代最佳化。新業務的庫表及SQL能接受改造及調整最佳化。
高效能高吞吐的業務應用	某大型電商的核心交易系統。	庫表數目不多，但資料規模大，高並發。應用對SQL查詢RT極為敏感。非常重視業務整體的吞吐效能。	SQL查詢種類不多，且相對固定。 SQL查詢的並發高，且要求查詢效能穩定。

上述不同應用類型的使用者所面對的業務情境及挑戰各有不同，因此，他們在給改造應用並對接分散式資料庫時各種取捨就自然不同。

為了讓上述幾種典型應用類型的使用者更便捷高效地利用分散式資料庫的紅利解決來業務的問題， PolarDB-X的透明分布式功能便提供不同的工作模式，供初次對接PolarDB-X資料庫的使用者根據自己應用的特點進行合理選擇。

各情境下推薦模式

PolarDB-X的透明分布式所提供的幾種工作模式及其能帶來的效果，如下表所示：

應用類型	最佳化目標	改造挑戰點	推薦工作模式	給應用帶來的業務效果
大量存量老業務的應用	突破單機資源瓶頸（主要是CPU/IO）。最佳化SQL查詢RT。	歷史存量業務的庫表數目過多（庫表數目可能達百級或千級），庫表的JOIN關係錯綜複雜。業務原來的SQL查詢複雜多樣，不允許修改，對分散式資料庫的SQL相容性高。	單表打散	最大限度地保持對原有從多存量業務庫表及其 SQL的相容性與查詢效能。眾多單表被打散到不同的DN節點，突破單機資源瓶頸，實現負載平衡與效能提升。
混合存量業務與新業務的應用	突破單機資源瓶頸（主要是CPU/IO/DISK瓶頸）。業務SQL查詢效能盡量不回退。大表的磁碟空間擴充。	歷史存量業務的庫表很多，庫表JOIN關係錯綜複雜。存量業務原有SQL查詢複雜多樣，大部分不允許修改。部分新業務庫表，尤其是大表，資料量增長迅速。	單表打散+手動分區說明設定單表打散後，需要使用`ALTER TABLE <table_name> PARTITION BY KEY(<column_name>) locality='';`陳述式完成手動分區操作。更多資訊，請參見Locality。	最大限度地保持對原有從多存量業務庫表及SQL 的相容性與查詢效能。眾多單表被打散到不同的DN節點，突破單機資源瓶頸，實現負載平衡與效能提升。業務大表手動分區，在解決擴充性的同時，保證讀寫效能。
基於單機 MySQL開發的新業務應用	需要擴充性。業務效能要求不高。	業務要盡量減少改造成本，需要快速上線。	自動分區	所有表自動分區，能突破單機資源瓶頸。所有索引預設全域索引，保證非主鍵維度查詢的基本效能。
高效能高吞吐的業務應用	需要線性擴充。高效能。	業務並發量大（幾萬或幾十萬QPS），並要求線性擴充。業務對效能敏感，SQL查詢要求快且穩定。	手動分區	所有表均按業務情境，手動選擇最合理的資料分割配置。業務查詢SQL能改造，滿足線性擴充性。