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

?

?

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

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

?

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

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

?

---

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

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

正如上面文章提到的： Microsoft ?IT ?使用SQL Server來驅(qū)動 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ù)量應該用數(shù)據(jù)庫的實際占用體積大小來比較，而不應該用單表數(shù)據(jù)量的大小來比較！

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

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

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

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

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

?

?

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

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

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

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

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

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

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

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

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

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

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

6、CHECKFILEGROUP（SQL2005）

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

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

?

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

?

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

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

是不是有責任承擔這個風險，是不是他的數(shù)據(jù)庫架構沒有做好，沒有分庫分表分機房。

?

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

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

而關系型數(shù)據(jù)庫是處理結構化數(shù)據(jù)的，兩者的側重點是不一樣，Hadoop處理的是海量非結構化數(shù)據(jù)，一般數(shù)據(jù)量PB級別

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

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

?

---

二、SQL Server的性能

?

性能方面，我只想談論一下IO

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

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

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

?

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

Linux五種IO模型性能分析

Windows五種IO模型性能分析

?

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

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

?

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

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

?

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

---

三、SQL Server的功能

?

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

例如限制資源使用這個功能

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

而MySQL的Query Throttling針對的是

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

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

限制有多少用戶連接MYSQL服務器

?

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

我這里不評論好壞，我只想說各有各的優(yōu)缺點

?

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

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

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

?

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

---

總結

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

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

?

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

?

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