數據庫架構演變概要

一．背景

爲了適應業務增加,數據庫數據量快速增加，性能日趨降低，穩定性不佳的實際狀況，急需架構逐步演變適應將來的業務發展。

二．現狀

【穩定性】數據庫爲單點，沒有高可用和穩定性方案。

【數據量大】數據庫目前400G左右，每月大約100G的增量；

單表數據只增不刪，數據持續增加;

【業務優化，剝離難】業務比較複雜，單純的業務梳理剝離和優化，涉及業務方溝通及方案確立週期太長;

【查詢慢】單機性能已出現過cpu瓶頸致使響應緩慢，大量的慢查詢。

三．架構升級方案概要

數據庫架構演變順序:

1) 大表表級拆分多表方案【風險:中 效果:不會特別明顯】

優勢:經過拆分大表，拆分冷熱數據，從而減小單表的數據掃描，進而優化數據庫性能。

缺點:只能緩解大表的數據增量，可是不能完全解決快速增加數據的本質問題。以目前的業務增量，即使作了冷熱數據分離，也最多多支持幾個月時間。

總結:只能緩解增量的症狀[避免全表掃描的沒必要要的數據篩選]，但不能解決本質問題。

2) UUID轉int方案【風險:高 效果:應該比較明顯】

優勢:保守估計性能大約有6倍左右的提高（連表操做），索引及內存存儲量下降爲原來的1/4左右，表大小，數據庫大小都會有相應的減小。

缺點:現有的數據庫太大約400g，總體遷移過程和步驟相對很是複雜，須要自行經過編碼實現遷移，難度很高。

總結:在cpu運算上和內存上會有明顯優化，可是解決不了數據量（磁盤）本質問題。

3) 用戶維度拆分方案【風險:高 效果:最好】

優勢:經過用戶維度拆分多個用戶庫和主庫（這裏的主庫不必定是一個庫，也能夠是垂直拆分的多庫），從而分散數據量，增長多個表和庫鎖的粒度，數據庫的鏈接池，硬件資源等；用戶維度性能提高n倍,主庫能夠經過讀寫分離提高性能；足夠業務n年的數據發展和平滑擴展。

缺點:拆分多庫，可用性和服務器穩定性降低（可是理論上出問題僅影響部分用戶，能夠保證整體可用性不會下降）。後期維護索引和更新，運維工做量加大多倍。業務代碼基本大部分稍微調整（須要選擇分庫），部分業務代碼須要分佈式事務支持（基本現有代碼的全部一致性事務須要調整）。

總結:全維度（cpu，內存，磁盤）優化數據庫，較完全解決數據庫平行擴展和性能問題（除主庫外）。相應的業務運維和運營的工做量加大和調整，但外圍業務用戶基本無感知架構變化。

4) 業務下降事務化方案【風險:中，效果：高併發下面效果好】

優勢:經過下降事務等級，減小讀共享鎖，避免部分業務更新操做的阻塞；從而提高併發處理的性能（相似java讀寫鎖原理，如今讓數據庫讀不加鎖或者部分加鎖）。

缺點:部分數據會出現髒讀（可是用戶基本無感知）(資金財務相關的不得下降事務等級),但去鎖並不會加快單條數據查詢的速度。業務代碼基本大部分須要根據業務場景，進行細粒度的事務等級控制（原則上一些查詢校驗，能不用事務就不用事務；大塊事務儘可能拆開多個事務；能經過Tcc或者最終一致性的業務冪等解決就不用強事務）（相似java方法級的鎖，修改爲方法內的多條代碼級鎖，減小鎖粒度，保證儘快釋放事務和鎖）。

總結:有效的下降鎖競爭致使的阻塞問題，可以有效提高業務高併發下面的整體併發能力，可是對無高併發下面的單筆業務處理耗時不會有明顯提高，同時業務代碼改動和梳理時間略費時間，但可根據狀況自行取捨。mysql和sqlserver事務鎖處理可能略有不一樣，可是整體下降事務等級思路不變。

5) 數據庫讀寫分離方案【風險:中 效果:比較好】

優勢:基於用戶維度拆分後，特別是針對主庫進行讀寫分離（根據用戶維度讀指定的讀庫）; 將一些報表性查詢，根據業務的實際狀況選擇讀庫或者寫庫(再加上低事務等級)，極大的提高數據庫的性能（主庫中一些全局的配置能夠作讀寫分離，用戶維度考慮硬件層面讀備熱切換和讀寫分離）。

缺點:須要代碼級別支持讀庫宕機，移除節點，平滑故障（須要分庫分表中間件支持配置中心和數據庫故障檢測信息打通，自動故障轉移）。要梳理業務邏輯，使一部分業務代碼的查詢切換到讀庫。

總結:讀寫分離主要解決用戶維度拆分後，主庫的讀壓力(也能夠部分分佈式緩存解決)和穩定性。從二八理論上講，能分擔大部分的性能到從庫，可是從庫會有數據延遲的可能性，故在業務讀寫分離處理時需考慮。

6) 絕對低耦合(獨立性)服務數據庫垂直拆分【風險:中 效果：未知】

優勢:低耦合的服務化數據庫拆分紅獨立服務或者功能，此服務化數據庫又能夠按照多維和技術特性進行更細粒度的服務化拆分和高性能，能夠提供服務複用性和獨立穩定性規劃。進一步下降業務數據量，提升業務的純性能。（通常獨立服務拆分有個特色: 要麼是共性業務，要麼不帶業務屬性的功能，並且這種服務數據量很多或穩定性要求極高）

缺點:將來業務確保不會出現耦合度粘性的發展，細粒度服務會更多，可是開發穩定後通常不會更改。

總結:只拆絕對低耦合的業務爲服務(如沒把握，寧肯不拆)

四．架構簡單示意圖

 by 車江毅