Sqlserver 高并發(fā)和大數(shù)據(jù)存儲方案

2024-08-31 01:04:35

字體：大中小

供稿：網(wǎng)友

隨著用戶的日益遞增，日活和峰值的暴漲，數(shù)據(jù)庫處理性能面臨著巨大的挑戰(zhàn)。下面分享下對實際10萬+峰值的平臺的數(shù)據(jù)庫優(yōu)化方案。與大家一起討論，互相學習提高！

案例：游戲平臺.

1、解決高并發(fā)

當客戶端連接數(shù)達到峰值的時候，服務端對連接的維護與處理這里暫時不做討論。當多個寫請求到數(shù)據(jù)庫的時候，這時候需要對多張表進行插入，尤其一些表達到每天千萬+的存儲，隨著時間的積累，傳統(tǒng)的同步寫入數(shù)據(jù)的方式顯然不可取，經(jīng)過試驗，通過異步插入的方式改善了許多，但與此同時，對讀取數(shù)據(jù)的實時性也需要做一定的犧牲。

異步的方式有很多，目前采取的方式是通過作業(yè)每隔一段時間（5min、10min..看需求設定）將臨時表的數(shù)據(jù)轉(zhuǎn)到真實表。

1. 已有原始表A 也是在讀取的時候真正用到的表。

2. 建立與原始表A同結構的B和C,用來作數(shù)據(jù)的中轉(zhuǎn)處理，同步流程是C->B->A。

3. 建立同步數(shù)據(jù)的作業(yè)Job1和記錄Job1運行狀態(tài)的表，在同步的時候比較關鍵的是需要檢查Job1的當前狀態(tài)，如果當前正在將B的數(shù)據(jù)同步到A，則把服務端過來的數(shù)據(jù)存到C，然后再把數(shù)據(jù)導入到B，等到下一次Job執(zhí)行的時候再將這批數(shù)據(jù)轉(zhuǎn)到A。如圖1：

Sqlserver,高并發(fā),大數(shù)據(jù),存儲

圖1

同時，為保萬無一失和便于排查問題，應該用一個記錄整個數(shù)據(jù)庫實例的存儲過程，在較短的時間檢查作業(yè)執(zhí)行結果，如果遇到異常失敗的，應該及時通過其他方式通知到相關人員。如寫入到發(fā)郵件和短信表，讓一個Tcp的通知程序定時讀取發(fā)送等等。

注：如果一天的數(shù)據(jù)達到幾十個G，如果又對這個表有查詢要求（分區(qū)下面會提到），下策之一：

可將B同時同步到多臺服務器分擔下查詢壓力，減少資源的競爭。因為整個數(shù)據(jù)庫的資源是有限的，如插入操作，會先獲得一個共享鎖，然后通過聚集索引定位到某一行數(shù)據(jù)，再升級為意向鎖，而sqlserver對鎖的維護根據(jù)數(shù)據(jù)的大小需要申請不同的內(nèi)存，造成了資源的競爭。所以應該盡可能的將讀和寫分開，可根據(jù)業(yè)務模型分，可根據(jù)設定的規(guī)則分；在平臺性的項目中應該優(yōu)先保證數(shù)據(jù)能有效的插入。

在不可避免的查詢大數(shù)據(jù)肯定會耗用大量的資源，如遇到批量刪除的時候，可以換成以循環(huán)分批次（如一次2000條）的方式，這樣不至于這個進程導致整個庫掛掉，衍生出一些無法預計的bug。經(jīng)實踐，有效可行，只是犧牲了存儲空間。也可根據(jù)查詢需求將表里數(shù)據(jù)量大的字段拆分出來到新表，當然這些也要根據(jù)每個業(yè)務場景結合需求來設定，設計出適合而并不需要華麗的方案即可。

2、解決存儲問題

如果每天單表的數(shù)據(jù)都達到了幾十個G，改善存儲方案自然迫不及待了。現(xiàn)分享下自有的方案，在暴漲的數(shù)據(jù)摧殘之下，仍堅守在一線！現(xiàn)舉例對自有環(huán)境分享拙見：

現(xiàn)有數(shù)據(jù)表A，單表每天新增數(shù)據(jù)30G，在存儲的時候采用異步將數(shù)據(jù)同步的方式，有的不能清除數(shù)據(jù)的表，在分區(qū)后還可分文件組，將文件組分配到不同的磁盤中，減少IO資源的競爭，保障現(xiàn)有資源的正常運行。現(xiàn)結合需求保留歷史數(shù)據(jù)5天：

1. 這時需要通過作業(yè)job根據(jù)分區(qū)函數(shù)去生成分區(qū)方案，如根據(jù)userid或者時間字段來分區(qū)；

2. 將表分區(qū)后，查詢可以通過對應的索引，快速定位到某一段分區(qū)；

3. 通過作業(yè)合并分區(qū)將不要的分區(qū)數(shù)據(jù)轉(zhuǎn)移到相同結構和索引的表，然后清除這個表的數(shù)據(jù)。

如圖2：

Sqlserver,高并發(fā),大數(shù)據(jù),存儲