歡迎光臨
每天分享高質量文章

我是如何在SQLServer中處理每天四億三千萬記錄的


首先宣告,我只是個程式員,不是專業的DBA,以下這篇文章是從一個問題的解決過程去寫的,而不是一開始就給大家一個正確的結果,如果文中有不對的地方,請各位資料庫大牛給予指正,以便我能夠更好的處理此次業務。

專案背景

這是給某資料中心做的一個專案,專案難度之大令人髮指,這個專案真正的讓我感覺到了,商場如戰場,而我只是其中的一個小兵,太多的戰術,太多的高層之間的較量,太多的內幕了。具體這個專案的情況,我有空再寫相關的博文出來。

這個專案是要求做環境監控,我們暫且把受監控的設備稱為採集設備,採集設備的屬性稱為監控指標。專案要求:系統支持不少於10w個監控指標,每個監控指標的資料更新不大於20秒,儲存延遲不超過120秒。那麼,我們可以通過簡單的計算得出較理想的狀態——要儲存的資料為:每分鐘30w,每個小時1800w,也就是每天4億3千兩百萬。而實際,資料量會比這個大5%左右。(實際上大部分是信息垃圾,可以通過資料壓縮進行處理的,但是別人就是要搞你,能咋辦)

上面是專案要求的指標,我想很多有不少大資料處理經驗的同學都會呲之以鼻,就這麼點?嗯,我也看了很多大資料處理的東西,但是之前沒處理過,看別人是頭頭是道,什麼分佈式,什麼讀寫分離,看起來確實很容易解決。但是,問題沒這麼簡單,上面我說了,這是一個非常惡劣的專案,是一個行業惡性競爭典型的專案。

1.沒有更多的服務器,而是這個服務器除了搭配資料庫、集中採集器(就是資料解析、告警、儲存的程式),還要支持30w點的北向接口(SNMP),在程式沒有優化之前CPU常年占用80%以上。因為專案要求要使用雙機熱備,為了省事,減少不必要的麻煩,我們把相關的服務放在一起,以便能夠充分利用HA的特性(外部購買的HA系統)

2.系統資料正確性要求極其變態,要求從底層採集系統到最上層的監控系統,一條資料都不能差
我們的系統架構如下,可以看到,其中資料庫壓力非常之大,尤其在LevelA節點:

3.硬體配置如下:
CPU:英特爾® 至強® 處理器 E5-2609 (4核, 2.40GHz, 10MB, 6.4 GT/s)
記憶體:4GB (2x2GB) DDR3 RDIMM Memory, 1333MHz,ECC
硬碟:500GB 7200 RPM 3.5” SATA3 硬碟,Raid5.

寫入瓶頸

首先遇到的第一個攔路虎就是,我們發現現有的程式下,SQLServer根本處理不了這麼多的資料量,具體情況是怎樣的呢?

我們的儲存結構

一般為了儲存大量的歷史資料,我們都會進行一個物理的分表,否則每天上百萬條的記錄,一年下來就是幾億條。因此,原來我們的表結構是這樣的:

CREATE TABLE [dbo].[His20140822](
[No] [bigint] IDENTITY(1,1) NOT NULL,
[Dtime] [datetime] NOT NULL,
[MgrObjId] [varchar](36) NOT NULL,
[Id] [varchar](50) NOT NULL,
[Value] [varchar](50) NOT NULL,
CONSTRAINT [PK_His20140822] PRIMARY KEY CLUSTERED
(
[No] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
) ON [PRIMARY]

No作為唯一的標識、採集設備Id(Guid)、監控指標Id(varchar(50))、記錄時間、記錄值。並以採集設備Id和監控指標Id作為索引,以便快速查找。

批量寫入

寫入當時是用BulKCopy,沒錯,就是它,號稱寫入百萬條記錄都是秒級的

public static int BatchInert(string connectionString, string desTable, DataTable dt, int batchSize = 500)
{
using (var sbc = new SqlBulkCopy(connectionString, SqlBulkCopyOptions.UseInternalTransaction)
{
BulkCopyTimeout = 300,
NotifyAfter = dt.Rows.Count,
BatchSize = batchSize,
DestinationTableName = desTable
})
{
foreach (DataColumn column in dt.Columns)
sbc.ColumnMappings.Add(column.ColumnName, column.ColumnName);
sbc.WriteToServer(dt);
}

return dt.Rows.Count;
}

存在什麼問題?

上面的架構,在每天4千萬的資料都是OK的。但是,調整為上述背景下的配置時,集中監控程式就記憶體上限溢位了,分析得知,接收的太多資料,放在了記憶體中,但是沒有來得及寫入到資料庫中,最終導致了生成的資料大於消費的資料,導致記憶體上限溢位,程式無法工作。

瓶頸到底在哪裡?

是因為RAID磁盤的問題?是資料結構的問題?是硬體的問題?是SQLServer版本的問題?是沒有分割槽表的問題?還是程式的問題?

當時時間只有一個星期,一個星期搞不好,專案監管就要我們滾蛋了,於是,有了連續工作48小時的壯舉,有了到處打電話求人的抓雞……

但是,這個時候需要的是冷靜,再冷靜……SQLServer版本?硬體?目前都不大可能換的。RAID磁盤陣列,應該不是。那麼到底是什麼,真TM的冷靜不下來。

大家可能體會不到現場那種緊張的氣氛,其實過了這麼久,我自己也都很難再回到那種情境。但是可以這麼說,或許我們現在有了各種方法,或者處於局外人我們有更多思考,但是當一個專案壓迫你快到放棄的時候,你那時的想法、考慮在現場環境因素的制約下,都可能出現重大的偏差。有可能讓你快速的思考,也有可能思維停滯。有些同事在這種高壓的環境下,甚至出現了更多的低級錯誤,思維已經完全亂了,效率更低了……36小時沒有合眼,或者只在工地上(下雨天到處都是泥巴,幹了的話到時都是泥灰)眯兩三個小時,然後繼續乾,連續這麼一個星期!或者還要繼續!

很多人給了很多想法,但是好像有用,又好像沒用。等等,為什麼是“好像有用,又好像沒用”?我隱隱約約中,好像抓住了一絲方向,到底是什麼?對了,驗證,我們現在是跑在現場環境下,之前沒有問題,不代表現在的壓力下沒有問題,要在一個大型系統中分析這麼個小功能,影響太大了,我們應該分解它。是的,是“單元測試”,就是單個方法的測試,我們需要驗證每個函式,每個獨立的步驟到底耗時在哪裡?

逐步測試驗證系統瓶頸

修改BulkCopy的引數

首先,我想到的是,修噶BulkCopy的各項引數,BulkCopyTimeout、BatchSize,不斷的測試調整,結果總是在某個範圍波動,實際並沒有影響。或許會影響一些CPU計數,但是遠遠沒有達到我的期望,寫入的速度還是在5秒1w~2w波動,遠遠達不到要求20秒內要寫20w的記錄。

按採集設備儲存

是的,上述結構按每個指標每個值為一條記錄,是不是太多的浪費?那麼按採集設備+採集時間作為一條記錄是否可行?問題是,怎麼解決不同採集設備屬性不一樣的問題?這時,一個同事發揮才能了,監控指標+監控值可以按XML格式儲存。哇,還能這樣?查詢呢,可以用for XML這種形式。

於是有了這種結構:No、MgrObjId、Dtime、XMLData

結果驗證,比上面的稍微好點,但是不是太明顯。

資料表分割槽???

那個時候還沒有學會這個技能,看了下網上的文章,好像挺複雜的,時間不多了,不敢嘗試。

停止其他程式

我知道這個肯定是不行的,因為軟體、硬體的架構暫時沒法修改。但是我希望驗證是不是這些因素影響的。結果發現,提示確實明顯,但是還是沒有達到要求。

難道是SQLServer的瓶頸?

沒轍了,難道這就是SQLServer的瓶頸?上網查了下相關的資料,可能是IO的瓶頸,尼瑪,還能怎麼辦,要升級服務器,要更換資料庫了嗎,但是,專案方給嗎?

等等,好像還有個東西,索引,對索引!索引的存在會影響插入、更新

去掉索引

是的,去掉索引之後查詢肯定慢,但是我必須先驗證去掉索引是否會加快寫入。如果果斷把MgrObjId和Id兩個欄位的索引去掉。

運行,奇跡出現了,每次寫入10w條記錄,在7~9秒內完全可以寫入,這樣就達到了系統的要求。

查詢怎麼解決?

一個表一天要4億多的記錄,這是不可能查詢的,在沒有索引的情況下。怎麼辦!?我又想到了我們的老辦法,物理分表。是的,原來我們按天分表,那麼我們現在按小時分表。那麼24個表,每個表只需儲存1800w條記錄左右。

然後查詢,一個屬性在一個小時或者幾個小時的歷史記錄。結果是:慢!慢!!慢!!!去掉索引的情況下查詢1000多萬的記錄根本是不可想象的。還能怎麼辦?

繼續分表,我想到了,我們還可以按底層的採集器繼續分表,因為採集設備在不同的採集器中是不同的,那麼我們查詢歷史曲線時,只有查單個指標的歷史曲線,那麼這樣就可以分散在不同的表中了。

說乾就乾,結果,通過按10個採集嵌入式並按24小時分表,每天生成240張表(歷史表名類似這樣:His_001_2014112615),終於把一天寫入4億多條記錄並支持簡單的查詢這個問題給解決掉了!!!

查詢優化

在上述問題解決之後,這個專案的難點已經解決了一半,專案監管也不好意思過來找茬,不知道是出於什麼樣的戰術安排吧。

過了很長一段時間,到現在快年底了,問題又來了,就是要拖死你讓你在年底不能驗收其他專案。

這次要求是這樣的:因為上述是模擬10w個監控指標,而現在實際上線了,卻只有5w個左右的設備。那麼這個明顯是不能達到標書要求的,不能驗收。那麼怎麼辦呢?這些聰明的人就想,既然監控指標減半,那麼我們把時間也減半,不就達到了嗎:就是說按現在5w的設備,那你要10s之內入庫儲存。我勒個去啊,按你這個邏輯,我們如果只有500個監控指標,豈不是要在0.1秒內入庫?你不考慮下那些受監控設備的感想嗎?

但是別人要玩你,你能怎麼辦?接招唄。結果把時間降到10秒之後,問題來了,大家仔細分析上面邏輯可以知道,分表是按採集器分的,現在採集器減少,但是數量增加了,發生什麼事情呢,寫入可以支持,但是,每張表的記錄接近了400w,有些採集設備監控指標多的,要接近600w,怎麼破?

於是技術相關人員開會討論相關的舉措。

在不加索引的情況下怎麼優化查詢?

有同事提出了,where子句的順序,會影響查詢的結果,因為按你刷選之後的結果再處理,可以先刷選出一部分資料,然後繼續進行下一個條件的過濾。聽起來好像很有道理,但是SQLServer查詢分析器不會自動優化嗎?原諒我是個小白,我也是感覺而已,感覺應該跟VS的編譯器一樣,應該會自動優化吧。

具體怎樣,還是要用事實來說話:

結果同事修改了客戶端之後,測試反饋,有較大的改善。我查看了代碼:

難道真的有這麼大的影響?等等,是不是忘記清空快取,造成了假象?
於是讓同事執行下述陳述句以便得出更多的信息:

-優化之前
DBCC FREEPROCCACHE
DBCC DROPCLEANBUFFERS

SET STATISTICS IO ON
select Dtime,Value from dbo.his20140825 WHERE Dtime>=” AND Dtime<=” AND MgrObjId=” AND Id=”
SET STATISTICS IO OFF

–優化之後
DBCC FREEPROCCACHE
DBCC DROPCLEANBUFFERS

SET STATISTICS IO ON
select Dtime,Value from dbo.his20140825 WHERE MgrObjId=” AND Id=” AND Dtime>=” AND Dtime<=”
SET STATISTICS IO OFF

結果如下:

優化之前反而更好了?

仔細查看IO資料,發現,預讀是一樣的,就是說我們要查詢的資料記錄都是一致的,物理讀、表掃描也是一直的。而邏輯讀取稍有區別,應該是快取命中數導致的。也就是說,在不建立索引的情況下,where子句的條件順序,對查詢結果優化作用不明顯。

那麼,就只能通過索引的辦法了。

建立索引的嘗試

建立索引不是簡單的事情,是需要瞭解一些基本的知識的,在這個過程中,我走了不少彎路,最終才把索引建立起來。

下麵的實驗基於以下記錄總數做的驗證:

按單個欄位建立索引

這個想法,主要是受我建立資料結構影響的,我記憶體中的資料結構為:Dictionary>。我以為先建立MgrObjId的索引,再建立Id的索引,SQLServer查詢時,就會更快。

先按MgrObjId建立索引,索引大小為550M,耗時5分25秒。結果,如上圖的預估計劃一樣,根本沒有起作用,反而更慢了。

按多個條件建立索引

OK,既然上面的不行,那麼我們按多個條件建立索引又如何?CREATE NONCLUSTERED INDEX Idx_His20141008 ON dbo.his20141008(MgrObjId,Id,Dtime)

結果,查詢速度確實提高了一倍:

等等,難道這就是索引的好處?花費7分25秒,用1.1G的空間換取來的就是這些?肯定是有什麼地方不對了,於是開始翻查資料,查看一些相關書籍,最終,有了加大的進展。

正確的建立索引

首先,我們需要明白幾個索引的要點:

•索引之後,按索引欄位重覆最少的來排序,會達到最優的效果。以我們的表來說,如果建立了No的聚集索引,把No放在where子句的第一位是最佳的,其次是Id,然後是MgrObjId,最後是時間,時間索引如果表是一個小時的,最好不要用

•where子句的順序決定了查詢分析器是否使用索引來查詢。比如建立了MgrObjId和Id的索引,那麼where MgrObjId=” and Id=” and Dtime=”就會採用索引查找,而where Dtime=” and MgrObjId=” and Id=”則不一定會採用索引查找。

•把非索引列的結果列放在包含列中。因為我們條件是MgrObjId和Id以及Dtime,因此傳回結果中只需包含Dtime和Value即可,因此把Dtime和Value放在包含列中,傳回的索引結果就有這個值,不用再查物理表,可以達到最優的速度。

跟上述幾點原則,我們建立以下的索引:CREATE NONCLUSTERED INDEX Idx_His20141008 ON dbo.his20141008(MgrObjId,Id) INCLUDE(Value,Dtime)

耗費時間為:6分多鐘,索引大小為903M。

我們看看預估計劃:

可以看到,這裡完全使用了索引,沒有額外的消耗。而實際執行的結果,1秒都不到,竟然不用一秒就在1100w的記錄中把結果篩選了出來!!帥獃了!!

怎麼應用索引?

既然寫入完成了、讀取完成了,怎麼結合呢?我們可以把一個小時之前的資料建立索引,當前一個小時的資料就不建立索引。也就是,不要再創建表的時候建立索引!!

還能怎麼優化

可以嘗試讀寫分離,寫兩個庫,一個是實時庫,一個是只讀庫。一個小時內的資料查詢實時庫,一個小時之前的資料查詢只讀庫;只讀庫定時儲存,然後建立索引;超過一個星期的資料,進行分析處理再儲存。這樣,無論查詢什麼時間段的資料,都能夠正確處理了——一個小時之內的查詢實時庫,一個小時到一個星期內的查詢只讀庫,一個星期之前的查詢報表庫。

如果不需要物理分表,則在只讀庫中,定時重建索引即可。

總結

如何在SQLServer中處理億萬級別的資料(歷史資料),可以按以下方面進行:
•去掉表的所有索引
•用SqlBulkCopy進行插入
•分表或者分割槽,減少每個表的資料總量
•在某個表完全寫完之後再建立索引
•正確的指定索引欄位

•把需要用到的欄位放到包含索引中(在傳回的索引中就包含了一切)

原文出處: 馬非碼的博客
原文鏈接:http://www.cnblogs.com/marvin/p/HowCanIHandleBigDataBySQLServer.html

赞(0)

分享創造快樂