還有一個(gè)帖子《 sqlserver的并發(fā)處理能力到底如何呀？高手都說說？ 》

?

?

其實(shí)這個(gè)題目是too open ended，無論大家認(rèn)為它的定位在Oracle之下，還是只適合于中小型數(shù)據(jù)庫，我只想說一下它在我眼中的能力

我相信我寫完后其他數(shù)據(jù)庫愛好者就會(huì)出來噴了， Oracle 的、 MySQL 的，畢竟這種文章跟《C#和JAVA哪家強(qiáng)》之類的文章是比較類似的。

?

我在這篇文章主要講兩個(gè)大家最care的方面：數(shù)據(jù)量、性能和功能

其實(shí)大家剛開始用數(shù)據(jù)庫最關(guān)心的莫過于OLTP場景里面的性能了還有這個(gè)數(shù)據(jù)庫系統(tǒng)的所能夠hold住的數(shù)據(jù)量

?

---

一、hold住大數(shù)據(jù)量

SQL Server作為一個(gè)成熟的商業(yè)數(shù)據(jù)庫，對于hold住大數(shù)據(jù)量是沒有問題的

正如上面文章提到的： Microsoft ?IT ?使用SQL Server來驅(qū)動(dòng) 27TB 的全球法定安全工具

?

在本人所在公司也有一些比較大的數(shù)據(jù)庫，數(shù)據(jù)庫體積大的也有7~8TB，小的幾十MB

很多人說：“SQL Server不能處理海量數(shù)據(jù)，數(shù)據(jù)量一大SQL Server就處理不了！”

我想問：“海量數(shù)據(jù)究竟有多少數(shù)據(jù)？1億？10億？100億？1TB？10TB？100TB？”

反正我天天都對著這麼多數(shù)據(jù)（上TB也有、上十億條也有），還是這樣用SQL Server管理它們。

?

我這里想說明一下如何比較數(shù)據(jù)量： 比較數(shù)據(jù)量應(yīng)該用數(shù)據(jù)庫的實(shí)際占用體積大小來比較，而不應(yīng)該用單表數(shù)據(jù)量的大小來比較！

這里有一個(gè)例子：之前我們數(shù)據(jù)庫服務(wù)器里有一個(gè)表，有六個(gè)字段，都是int類型，單表數(shù)據(jù)量已經(jīng)1億+了，但是數(shù)據(jù)庫的大小只有20G不到

在我眼中只是一個(gè)比較小的數(shù)據(jù)庫，雖然它的數(shù)據(jù)量比較驚人

在園友 馬非碼 的博客里曾經(jīng)寫到一篇文章《 我是如何在SQLServer中處理每天四億三千萬記錄的 》，文章是非常多的推薦

但是在我眼里，文章沒有多少新意，正如我剛才說的，四億三千萬數(shù)據(jù)可能就<100G的數(shù)據(jù)，這麼多數(shù)據(jù)其實(shí)跟SQL Server是否能hold住

沒有多大關(guān)系，而是跟博主的架構(gòu)能力有關(guān)系，數(shù)據(jù)庫架構(gòu)無非就是 分表-》分庫-》分機(jī)房，解決 CAP 問題，還有就是 MVCC 的問題。

?

?

實(shí)際上，超大型數(shù)據(jù)庫（VLDB）跟小型數(shù)據(jù)庫管理起來是不一樣的，這里我是不管它數(shù)據(jù)量，我只管它的數(shù)據(jù)庫實(shí)際占用體積

對于管理大型數(shù)據(jù)庫里面的大表，大家第一個(gè)想法就是使用 表分區(qū) 來管理它，表分區(qū)從SQL Server2005開始推出到現(xiàn)在SQL Server2014還是使用表分區(qū)

大家會(huì)說，微軟還是沒有什么 突破 ，還是用這麼老的表分區(qū)技術(shù)來管理大表，甚至于有時(shí)候我做了表分區(qū)，但是整個(gè)數(shù)據(jù)庫這麼大，我還是做不了完整備份。。。

貌似在大家的眼中，表分區(qū)只是作為一種提升查詢性能的工具，更直接來說，就是提升Select Query性能的利器

但是對于我們DBA來說，分區(qū)表的優(yōu)勢更多的體現(xiàn)在管理方面

分區(qū)表的管理優(yōu)勢如下：

1、壓縮單獨(dú)某個(gè)分區(qū)的數(shù)據(jù)（SQL2008）

2、按分區(qū)的統(tǒng)計(jì)信息（SQL2014 CREATE STATISTICS 和相關(guān)統(tǒng)計(jì)信息語句現(xiàn)在允許通過使用 INCREMENTAL 選項(xiàng)創(chuàng)建按分區(qū)的統(tǒng)計(jì)信息）

3、聯(lián)機(jī)重新生成某個(gè)分區(qū)的數(shù)據(jù)（SQL2014 針對聯(lián)機(jī)索引操作事件類的進(jìn)度報(bào)告現(xiàn)在具有兩個(gè)新數(shù)據(jù)列：PartitionId 和 PartitionNumber）

4、聯(lián)機(jī)重新組織某個(gè)分區(qū)的數(shù)據(jù)（SQL2005）

5、文件組備份和段落還原(SQL2005)

6、CHECKFILEGROUP（SQL2005）

7、交換分區(qū)(刪除歷史數(shù)據(jù)或歸檔 或進(jìn)行ETL)

8、鎖升級(jí)可以提升到分區(qū)鎖，而不是直接到表鎖（SQL2008）

?

其實(shí)只要表分區(qū)做得好，分區(qū)區(qū)間做得合理，定時(shí)維護(hù)分區(qū)表，hold住大數(shù)據(jù)量是沒有多少問題的。

?

前年看到一篇文章，對于關(guān)系型數(shù)據(jù)庫，如果數(shù)據(jù)庫的實(shí)際占用體積到了100TB，關(guān)系型數(shù)據(jù)庫已經(jīng)無能為力了，該到Hadoop上場的時(shí)候了。

本人承認(rèn) ，如果你的數(shù)據(jù)庫真的有100TB，那么SQL Server可能會(huì)沒有能力handle，但是，你的數(shù)據(jù)庫真的reached 100TB，那么你們公司的數(shù)據(jù)庫架構(gòu)師

是不是有責(zé)任承擔(dān)這個(gè)風(fēng)險(xiǎn)，是不是他的數(shù)據(jù)庫架構(gòu)沒有做好，沒有分庫分表分機(jī)房。

?

我先不管關(guān)系型數(shù)據(jù)庫是否有能力handle這麼大的數(shù)據(jù)量，后來我又看了一個(gè)視頻。

視頻里面甲骨文技術(shù)產(chǎn)品事業(yè)部總經(jīng)理吳承楊介紹了關(guān)系型數(shù)據(jù)庫和Hadoop的區(qū)別，Hadoop是處理非結(jié)構(gòu)化數(shù)據(jù)的

而關(guān)系型數(shù)據(jù)庫是處理結(jié)構(gòu)化數(shù)據(jù)的，兩者的側(cè)重點(diǎn)是不一樣，Hadoop處理的是海量非結(jié)構(gòu)化數(shù)據(jù)，一般數(shù)據(jù)量PB級(jí)別

而吳承楊總經(jīng)理也講到，非結(jié)構(gòu)化數(shù)據(jù)通常指代的就是網(wǎng)頁數(shù)據(jù)，Hadoop把這些數(shù)據(jù)經(jīng)過處理之后就存放進(jìn)去關(guān)系型數(shù)據(jù)庫里面以便查詢

所以不能把Hadoop和關(guān)系型數(shù)據(jù)庫相提并論。

?

---

二、SQL Server的性能

?

性能方面，我只想談?wù)撘幌翴O

大家知道不管Windows還是Linux，都是 用戶程序->OS內(nèi)核->存儲(chǔ)設(shè)備這種架構(gòu)，用戶程序和OS內(nèi)核之間存在一套IO接口

同樣，OS內(nèi)核和存儲(chǔ)設(shè)備之間一樣存在一套IO接口，有異步，同步，存儲(chǔ)設(shè)備的Write Through和Write Back等參數(shù)

而Linux操作系統(tǒng)的IO行為跟Windows有很多不同之處的，兩者的文件系統(tǒng)的不同，兩者的IO設(shè)備驅(qū)動(dòng)不一樣，IO調(diào)度模型不一樣

?

由于本人對Windows和Linux的IO調(diào)度沒有太深入研究，大家可以參考下面兩篇文章

Linux五種IO模型性能分析

Windows五種IO模型性能分析

?

其實(shí)一般不是太差的數(shù)據(jù)庫都可以達(dá)到上千的TPS，上萬的QPS，上萬的并發(fā)連接

由于本人沒有親自測試也沒有環(huán)境，就不再詳細(xì)說了

?

之前看過一本書，里面說Linux的IO調(diào)度模型對于使用網(wǎng)絡(luò)存儲(chǔ)的機(jī)器來講更加好，上層的一個(gè)請求，對于下層少量的網(wǎng)絡(luò)數(shù)據(jù)包

而Windows上層的一個(gè)IO請求會(huì)對網(wǎng)絡(luò)存儲(chǔ)發(fā)出比Linux還多的網(wǎng)絡(luò)數(shù)據(jù)包，好像是iSCSI協(xié)議，所以運(yùn)行在Linux上的Oracle和MySQL會(huì)更勝一籌

?

但是可以說，SQL Server針對Windows系統(tǒng)做過特別優(yōu)化，在TPS和QPS各方面測試中不會(huì)跟主流數(shù)據(jù)庫相差很遠(yuǎn)，不然的話SQL Server早就從地球上消失了

---

三、SQL Server的功能

?

本人覺得SQL Server的功能做得是比較完善了，最起碼對于一個(gè)商業(yè)數(shù)據(jù)庫，其他競爭對手有的功能，SQL Server基本都有

例如限制資源使用這個(gè)功能

SQL Server的資源調(diào)控器可以針對登錄用戶限制它所使用的CPU、內(nèi)存、IO資源

而MySQL的Query Throttling針對的是

限制用戶每小時(shí)的修改數(shù)據(jù)庫數(shù)據(jù)的數(shù)量

控制用戶每小時(shí)打開新連接的數(shù)量

限制有多少用戶連接MYSQL服務(wù)器

?

MySQL的Query Throttling偏向于查詢方面的

我這里不評(píng)論好壞，我只想說各有各的優(yōu)缺點(diǎn)

?

到目前為止，我還未發(fā)現(xiàn)其他數(shù)據(jù)庫有的功能，SQL Server沒有的，或者本人才疏學(xué)淺，可能Oracle有的功能而SQL Server沒有的

比如：Oracle中的位圖索引，而在SQL Server中位圖過濾(Bitmap)運(yùn)算符

相關(guān)文章：《 SQL Server優(yōu)化器特性-位圖過濾(Bitmap) 》

?

很多時(shí)候只是大家的實(shí)現(xiàn)方式不一樣已而，而不代表SQL Server沒有

---

總結(jié)

本人做DBA的時(shí)間不長，在學(xué)校開始接觸，到畢業(yè)之后公司使用SQL Server，到現(xiàn)在由它來帶我進(jìn)入DBA這個(gè)行業(yè)

對于SQL Server這個(gè)產(chǎn)品，本人是比較感激的，每天跟各位SQL Server愛好者討論如何使用它，不亦樂乎

?

只可惜SQL Server在中國國內(nèi)市場越來越不活躍，不知道以后會(huì)不會(huì)有盡頭。

?

如有不對的地方，歡迎大家拍磚o(∩_∩)o?