資料庫拆分案例

杭州湖畔網路技術有限公司是一家專業提供SaaS化電商ERP服務的創業公司，主要用戶群體為經營淘寶、天貓、京東等主流電商平臺、自建商城、線下渠道的商家及中小企業。作為SaaS服務提供商，服務數萬乃至數十萬級用戶是業務架構初期就必須考慮的問題。龐大的用戶群以及海量的用戶數據意味著基礎設施的構建必須兼顧高效與穩定，而按照通用的基礎設施建設方案的話，需要面對成本過高、實現複雜、需要投入太多精力等問題，這對當時的湖畔網路這樣的初創公司來說，完全不能承受。因此，更經濟、更方便擴展的雲服務平臺成為首選。在對比現有各家雲服務後，我們選擇了穩定性與成熟度都經過大量用戶檢驗的阿裡雲。

但要構建高性能的SaaS應用，僅憑雲服務基礎設施是不夠的。如何基於雲服務平臺設計並實施符合自身業務特點的系統架構，也是決定產品性能的關鍵。本文將講述我們如何利用雲服務，使用相對經濟的方案，解決海量用戶的資料庫使用問題。

架構

我們的SaaS化電商ERP服務的整體架構是基於阿裡雲服務平臺實施的，如圖1所示。

圖1  系統架構精簡示意圖

通過該方案，不僅發揮了阿裡雲的優勢（不涉及物理機器的維護和折損，靈活地配置升級，成熟的備份與快照方案），而且通過集群，避免了系統可能會遇到的單點故障，提高了系統彈性擴容的靈活性和可用性。

作為一個SaaS化、數據更集中、數據體量龐大的企業應用，資料庫是我們整體架構中的關鍵節點，如何保證其穩定與性能，是本文講述的重點。

當用戶進入快速增長期後，隨著業務量迅速增加，核心業務表的存量數據和增長速度絕對不是單個DB所能承受的（幾乎所有單DB配置都存在性能物理上限瓶頸，即使選擇升級配置也會受到成本和資源上限的約束）。因此，我們一開始就將資料庫分庫分片（Sharding）作為一個可行方案優先考慮，主要分析如下。

考慮到業務特性，我們最終採用了行業比較通用的水平拆分+垂直拆分策略，並自主完成DAO與JDBC之間的數據訪問封裝層開發工作。

水平拆分：按用戶將數據拆分到多個庫的相同表中

水平拆分的思路，就是將原本存放在單個RDS資料庫中的數據，根據業務ID不同，拆分到多個資料庫中（參見圖2）。拆分後，各庫的表數量及表結構都保持一致。水平拆分首先需要確立唯一的業務主表，即其他所有表的數據都與主表ID（前文所說的業務ID）存在直接或間接的主從關係，可以通過主表ID對全部數據做很好的切分。我們選擇的業務主表為用戶表，其他業務表或表的父表都包含一個用戶ID。因此，我們切分的目標就是將不同用戶數據存放到不同的資料庫中。

圖2  水平拆分示意圖

確定了拆分規則後，下一步是著手封裝Sping數據訪問封裝層（DBWrapper）。DBWrapper介於DAO與JDBC之間，每個業務DAO進行資料庫基本操作，都會經過DBWrapper。它的主要作用是將資料庫架構的變化對業務層透明，業務層可以如同操作單個DB一樣，調用DBWrapper提供的資料庫操作介面，而判斷操作哪個資料庫的邏輯，則全部交由DBWrapper封裝完成（參見圖3）。 

圖3  水平拆分架構示意圖

DBWrapper主要提供新用戶初始化和資料庫操作介面。在新增用戶初始化到系統時，需先動態判斷系統各庫的負載分佈情況。粗略一點的演算法就是判斷各庫的用戶數，如共有4個庫，可以根據user_id%4的情況決定目標庫；再精細一點可以挖掘下核心業務數據的分佈情況，具體分配演算法需要基於業務設定（如考慮不同用戶的平均訂單量）。通過各庫壓力綜合計算後，分析出壓力最小的目標資料庫，並將該新增用戶數據存放到指定的目標庫，同時更新路由信息（Router）。

當用戶完成初始化進行業務操作時，則需由業務層調用DBWrapper的操作介面。DBWrapper接收到請求後，會根據業務層傳入的User_id匹配Router，判斷最終需要操作的RDS實例和資料庫。判斷完成後，只需要按部就班地開連接執行就可以了。具體的代碼實現，需要結合自身的持久層框架，找一名研究過持久層框架實現的開發人員即可完成。

這樣就將系統用戶整體數據壓力，相對均勻地分佈到多個RDS實例與資料庫上。事實證明，這確實是一個非常有效的方案，尤其是對於數據量大、增長迅猛的表。只是在後續實施過程中，我們發現有時會有單個用戶的業務壓力比較突出，針對這種情況，我們可以通過一些人工干預（如遷移數據到單獨的庫）進行微調，當然最終的解決方案還是要不斷調優路由演算法。

切分後，不可避免地需要考慮數據字典（DD）和數據路由（Router）的處理。暫時我們採用的方法是將所有數據字典與路由放入獨立的庫，這也是後文中垂直拆分的一種應用。需要說明的是，資料庫僅是這兩個業務的一種實現方式，一般還可以通過或結合分散式緩存來處理這些業務（我們選用了OCS）。而對於可能出現的單點障礙，預留的擴展方案為水平拆分或創建只讀節點（只讀節點可以使用RDS最新提供的只讀實例，目前還在內測階段）。

垂直拆分：按業務將表分組拆分到多個庫中

與水平拆分相比，垂直拆分要更簡單一些。其基本思路就是將存放在單個資料庫的表分組，把其中業務耦合度較高、聯繫緊密的表分為一組，拆分到其他DB中（參見圖4）。拆分後，各庫的表結構及其業務意義將完全不同。雖然規則簡單、實施方便，但垂直拆分總是需打斷些關聯，因為實際操作中，基礎資源常常出現在各個業務場景，在切分時又不得不切分到兩個庫中，此時就需要業務層多次查詢後，在記憶體處理數據，實現資料庫Join的效果。

圖4  垂直拆分示意圖

垂直拆分同樣需要DBWrapper，但封裝規則與水平拆分略有不同，需要針對不同的業務，建立不同的DBWrapper。此時不再是完全業務層無感知，需要業務層根據業務場景有針對性使用。單個DBWrapper的實現與水平拆分一致。

垂直拆分的好處在於，將整體業務數據切分成相對獨立的幾塊，隔離了不同業務之間的性能影響。而由於拆分後的資料庫業務比較集中，也更容易找到業務主表，更有利於水平拆分。

對於垂直拆分，目前我們主要用於解決數據路由（包含了用戶的基本信息）、數據字典模塊，以及常見的冷數據問題。冷數據的處理一直是行業的常見問題（其實對於冷數據的劃分，也是水平拆分），目前我們採用的方案是集中存儲，即按自己的冷數據切分方式，通過自行開發的遷移程式將判定的冷數據增量遷移到一個庫中。這個方案既能夠分離冷數據對熱點數據的操作影響，也可以為大數據的挖掘提供比較便利的條件。使用相對獨立的冷數據存儲結構，能方便以後採用更高效、成本更低廉的存儲介質。當然該方案存在一些潛在問題，如果冷資料庫滿了該怎麼辦？目前我們預留的設計方案是，歷史庫的水平拆分，也可以考慮其他存儲形式。

水平拆分與垂直拆分組合使用

拆分一直是資料庫優化的關鍵詞（無論是庫表結構還是SQL寫法），它是每個高併發產品最終都要經歷的一步。拆分方案的核心主要在於可以通過添加更多RDS實例和資料庫（常常為了節約成本，多個資料庫可以部署在一個RDS實例上），靈活擴容系統的負載能力。在資料庫架構中，水平拆分和垂直拆分一般都是搭配使用的，兩者的先後順序視具體情況而定。一般而言，垂直拆分更容易，也可以為水平拆分做鋪墊，一是業務集中，便於提取主表，二是垂直拆分後，可以只水平拆分壓力高的表，而業務增長緩慢的表則可以保留單DB，從而提高拆分效率以及降低實施成本（參見圖5）。

圖5  資料庫Sharding方案示意圖 

我們之所以優先水平拆分，主要原因還是成本和效率及當時的一些局限性。只按業務ID（用戶）做好路由配置，這樣各個庫中的結構完全一致，保留了原本的業務邏輯與實現，避免了跨庫關聯，能大大節省實現成本。

儘管拆分有種種好處，但由於分散式事務及跨庫Join的實現複雜度較高及可用性較差，所以分散式事務一般都通過業務層使用樂觀鎖控制。而跨庫的表間關聯一定要打斷，否則性能和實現複雜度都會超出可接受範圍。對於跨庫的Join、Group by等問題，都需要在業務層處理。目前我們採用的是分批查詢，在業務層組裝結果的方式。

有些遺憾的是，由於我們早期使用RDS時，阿裡雲尚未推出DRDS（分散式資料庫）產品，所以上述拆分的資料庫底層架構均是由我們自行研發的，投入了大量的精力。而現在有了DRDS，正準備做拆分的團隊，則無需再自己造輪子，直接拿來用即可，這樣團隊可以將更多的精力放在業務上。

小處大有可為

雖然我們在架構上做了優化，但在產品發展過程中還是會出現性能不太理想的情況。在阿裡雲支持中心和論壇上，也可以看到其他業務型團隊反饋使用RDS時遇到類似的情況。最初大家都懷疑是不是RDS的底層資源隔離有問題，多個用戶共用資源時發生爭搶，導致RDS的性能問題。但在阿裡雲DBA的指導和協助下，發現是由於產品設計時對資料庫的使用太“不拘小節”，而隨著併發壓力與數據量增加，大量細小的性能問題被放大，集中暴露出來。

解決燈下黑：修正業務層的資料庫操作陋習

在資料庫的優化過程中，研發團隊最容易忽視的往往是業務層中的資料庫使用。一些優化方案可以作為開發的常態化準則。下麵僅列舉幾個常用的優化方案。

擠掉海綿里的水：優化資料庫執行計劃

由於執行計劃的優化往往涉及到資料庫的運行機制與底層設計，此處實難三言兩語說清。所以下麵僅列舉幾個我們受益頗深的優化方案。建議大家優化執行計劃時，多關註、分析iDB Cloud控制臺中的性能報告和建議，也儘量多向阿裡雲DBA們請教，一般可以通過提工單的方式。有條件或興趣的話，DBA可以通過預約到阿裡雲現場學習。另外，執行計劃的優化需要大量的調試工作，通過在阿裡雲控制台創建生產資料庫的臨時實例，可以準確模擬當前系統的數據結構、分佈與壓力。

欄位類型選擇

選擇合理的欄位，往往可以大大減少資料庫行數據的大小，並提高索引匹配的效率，進而大大提升資料庫性能。使用更小的數據類型，如日期採用date代替datetime、類型或標記使用tinyint代替smallint和int、使用定長欄位代替非定長欄位（如char代替varchar），都能或多或少減少數據行大小，提高資料庫緩衝池的命中率。而作為表欄位中特殊的一員—主鍵，其選型更會對錶索引的穩定和效率帶來很大的影響，一般建議考慮資料庫自增或自主維護的唯一數值。

高分離度欄位建立索引

對於查詢來講，高分離度欄位往往意味著精準或部分精準的條件。相對來講是最好優化的一種場景，只需要對分離度較高的欄位單獨建立索引即可。當然實際使用中會有更多細節需要摸索。精確條件在各業務中基本都會用到，在越複雜的業務場景中，精確條件優先的原則，將是最有效的優化方案。需要註意的是，儘管高分離度欄位單獨建立索引效率很高，但過多的索引會影響表寫入的效率，所以需要謹慎添加。這一點iDB Cloud中有大表索引的建議可以參考。

覆蓋索引（Covering Index）

通俗一點理解，就是執行計劃可以通過索引完成數據查找和結果集獲取，而無需回表（去緩衝池或磁碟查找數據）。而由於MySQL的索引機制限制，一次查詢時，將只用到一個索引或將兩個索引聚合（index_merge）起來使用，所以意味著複雜的業務場景中，單獨對每個欄位建立索引可能沒有什麼用處。所以對於一些特定的查詢場景，建立合適的組合索引，應用覆蓋索引方法可以避免大量隨機I/O，是更為推薦的優化方案（如果執行計劃Explain的Extra中有Using Index，就說明使用了覆蓋索引）。但實際業務總是會比索引本身更複雜，業務中需要查找或者獲取的欄位信息往往是很多的，而組合索引並不能涵蓋所有的欄位（否則我們將擁有一個比數據還要龐大的索引）。此時，為了應用覆蓋索引，就需要使用主鍵延遲關聯（Deferred Join），即先通過組合索引中包含的欄位條件，初步查詢出相對較小的結果集（面向結果集原則），該結果集只包含主鍵欄位；然後通過獲取到的這個主鍵隊列，再對數據表做關聯。

適當妥協

見招拆招：升配置

一般業務型的研發團隊，很難有額外的精力投入到資料庫方面，也沒有專業的DBA來不斷調優資料庫配置、優化資料庫伺服器性能。所以早期團隊可以選擇的方案不多，也很難在技術上深挖下去，只能用成本換時間：性能配置不夠，那就升級伺服器配置。

那麼問題來了：自己部署的資料庫要升級配置，除了調整資料庫配置參數，還會受到物理機的限制，因此就要考慮更加複雜的資料庫備份和同步策略。但這是業務團隊所不能接受，甚至短期內無法實現的，升配置也就變成了一個複雜的問題。不過我們使用了RDS，其彈性升級策略，正是這個問題的最佳解決方案。

二八原則

在長期的資料庫乃至整個產品的優化過程中，我感受最深刻的就是：完美的方案可遇不可求。選擇方案時，如果能解決80%的問題，並規避或保留剩下的20%，則將大大提升團隊的整體效率。產品與架構都是在不斷優化演變的，我們要循序漸進、不斷努力，將今天的終點留作明天的起點。

總結與展望

作為一位創業公司的技術開發人員，通過實際使用阿裡雲產品，我總結了幾點關於使用雲計算產品的優勢。

1. 便利的伺服器彈性升級功能，可隨時應付像“雙十一”這樣的大促。而通過使用傳統IDC托管模式，物理機的維護、升級以及升級後的數據遷移都是比較頭疼的。

2. 成熟可靠的數據備份與快照、資料庫主從分離與同步的底層方案。創業團隊無須承受自己造輪子的代價，可專註於業務開發。

3. 雲計算產品經過檢驗、值得信賴的安全防護。

4. 精簡了創業團隊人員規模。雲計算平臺具備專業的技術支持與服務，使得創業團隊不再需要資料庫和伺服器管理員。

除了使用雲產品的心得，資料庫調優實踐是本文的重點。在資料庫的架構設計與性能優化方面，我秉承的原則是解決主要問題，按先分而擊之、再挖掘細節的步驟，周返往複不斷進行，同時系統架構也在這個過程中不斷演變。相信隨著時間推移，會有更多優秀的方案出現。尤其隨著雲服務不斷發展，業務研發團隊投入到基礎設施的精力與成本，將會無限減少。會有越來越多專註於業務研發的團隊，推出更多優秀的互聯網產品，用互聯網服務推動企業創新，重塑中小企業信息化形態。 

• 採用SLB（Server Load Balance，負載均衡）作為Web集群訪問入口，負責為Web端的多台伺服器進行流量分發。SLB是基於集群建設的，並且可以隨時變配，按量付費。它不僅為我們實現了成熟的負載均衡方案，其穩定性與靈活性也為Web集群提供了更多可能。
• 後端配置多台ECS（Elastic Compute Service，雲伺服器）實例，將主要應用服務都部署在ECS上。除了可彈性擴容這一特性，ECS提供的安全防護和快照備份為伺服器安全和容災提供了非常成熟的解決方案，這恰恰是我們這種業務型創業團隊積累相對最薄弱的方面。另外，ECS多線接入骨幹網路能保證網路的穩定和性能，使得任何網路的用戶訪問應用服務都非常順暢。
• DB集群由多台RDS（Relational Database Service，關係型資料庫服務）實例組成。RDS是雲資料庫，簡單易用，使用方法與自行部署的資料庫完全一樣。其成熟的雙機熱備與底層資源隔離，保證了我們這兩年來資料庫的平穩運行。另外，強大的iDB Cloud控制台、專業的DBA團隊支持，為我們監控資料庫運行狀況、定位和解決資料庫問題，提供了非常多的建議和幫助。
• 集群之間的共用資源統一存放在OCS（Open Cache Service，開放緩存服務）中。我們用OCS來存放數據路由和實時性不高的業務數據。緩存作為我們架構性能中非常重要的一個環節，在承受了來自整個集群各方面壓力的同時，還要保證響應穩定高速。

• 場景：業務熱點數據持續增加，團隊有一定的資料庫架構積累能支撐獨立研發或熟悉成熟的中間件（如Cobar）。
• 優點：成本低（可以利用開源免費的資料庫集群替代大型商業DB）；可靈活擴容（不斷增加新的資料庫切片即可）；相對均勻分佈的數據讀寫，避免單點障礙。
• 缺點：需要研發團隊在資料庫架構上投入大量精力；資料庫集群維護需要成本投入。

• 場景：資料庫性能有問題，應優先從業務層分析。
• 優點：減輕資料庫的直接壓力，比執行資料庫優化方案更加迅速有效。
• 缺點：業務研發需要關註一些資料庫操作內容；有時會犧牲一些業務；產品規模越大實施越困難。

• 延遲載入。很多頁面展現時，單個實體實際只展現部分內容，因此可按需載入，減輕資料庫壓力，又節省網路流量。延遲載入也可體現在資料庫表的拆分設計上。
• 適當緩存，以空間換時間。對於很多實時性較低或乾脆就是數據字典的內容，無需實時到資料庫中載入，只需在使用前載入到記憶體中，實際使用時到記憶體中獲取即可。
• 減少不必要的開連接（連接池、批量查詢及提交）。對於大部分的Web應用，連接池大大減少了系統因開資料庫連接產生的開銷。而在查詢和提交中，將多個任務合併到一次資料庫操作中，也可以大大提高資料庫使用效率。
• 樂觀鎖是高併發下不錯的解決方式。相比於資料庫的悲觀鎖，業務層實現的樂觀鎖，不僅能減少鎖爭搶，還可以減少資料庫的鎖開銷，進而提高資料庫使用效率。
• 分解大事務。資料庫對於大事務的原子性保證，也是不容忽視的開銷。業務使用時，儘量將大事務切分為小事務，或者適當利用非同步提交，精簡事務體積。
• 合理使用Join。資料庫執行計劃中，有一條準則是越簡單越快速。所以通過適當冗餘數據設計或業務層分批查詢後記憶體組裝數據，減少資料庫Join語句及SQL複雜度，對於資料庫執行效率和執行計劃的優化都有不可忽視的好處。

• 場景：併發不多、數據量並不很大，或系統整體壓力較低，只有某幾個業務點性能較差。
• 優點：在不改變基本條件的情況下，挖掘資料庫更大潛力。
• 缺點：需要DBA協助或研發團隊對資料庫執行計劃做研究。

• 場景：性能問題緊迫，團隊時間資源有限。
• 優點：簡單粗暴見效快，基本適用於任何優化階段。
• 缺點：增加成本；治標不治本，只是延遲問題再次爆發時間；資源總有上限，遲早升無可升。

轉載：http://blog.sina.com.cn/l1pe1