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

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

案例：游戲平臺(tái).

1、解決高并發(fā)

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

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

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

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

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

圖1

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

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

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

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

 2、解決存儲(chǔ)問(wèn)題

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

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

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

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

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

如圖2：

圖2

通過(guò)sql查詢跟蹤捕捉到查詢耗時(shí)長(zhǎng)的，以及通過(guò)sql自帶的存儲(chǔ)過(guò)程sp_lock或視圖dm_tran_locks、dblockinfo查看當(dāng)前實(shí)例存在的鎖的類型和粒度。

定位到具體的查詢語(yǔ)句或者存儲(chǔ)過(guò)程之后，對(duì)癥下藥！藥到病除！

以上就是本文的全部?jī)?nèi)容，希望本文的內(nèi)容對(duì)大家的學(xué)習(xí)或者工作能帶來(lái)一定的幫助，同時(shí)也希望多多支持腳本之家！