百度上暫時(shí)還沒有搜索到相關(guān)的個人寫的比較有價(jià)值的文章，至少在中文網(wǎng)絡(luò)的世界里面沒有

但是在微軟的網(wǎng)站有這樣一篇文章：《比較 SQL Server 與 IBM DB2》

文章從下面幾個方面進(jìn)行了對比

1、TCO和ROI2、性能和可擴(kuò)展性3、高可用性4、安全5、管理6、開發(fā)效率7、商業(yè)智能和數(shù)據(jù)倉庫8、OLTP9、SAP集成

文章介紹得比較牛逼

性能與可擴(kuò)展性

SQL Server 的性能和可擴(kuò)展性優(yōu)于IBM DB2.

• 基準(zhǔn)顯示SQL Server 能夠掌控大型工作負(fù)荷:

  • 在TPC-C 基準(zhǔn)測試總，SQL Server每分鐘的事務(wù)處理超過1百萬，并且在Windows平臺上擁用最好的性能.
  • 在 TPC-H 基準(zhǔn)的10項(xiàng)比較中，有7項(xiàng)SQL Server優(yōu)于DB2.
  • 在一項(xiàng)SAP-SD 認(rèn)證基準(zhǔn)中支持 93,000個并發(fā)用戶，相當(dāng)于全球最大的SAP客戶的10倍以上.
  • 在新的OLTP基準(zhǔn)標(biāo)準(zhǔn)-TPC-E中，SQL Server 是無可爭議的領(lǐng)先者.
  • 閱讀最新的SQL Server 2008 基準(zhǔn)結(jié)果.

• SQL Server 2008 包括最新的性能與可擴(kuò)展性，能夠優(yōu)于DB2為大型工作負(fù)荷提供更好的性能:

  • o 改進(jìn)分區(qū)表、索引、范圍及其他
  • o 壓縮支持符合甚至超越了IBM DB2 UDB資源管理，能夠控制更細(xì)的CPU和內(nèi)存資源
  • o 性能數(shù)據(jù)收集器可以跨企業(yè)定位問題、調(diào)整和監(jiān)控SQL Server實(shí)例
  • o 高度調(diào)整的ETL引擎目前保持了世界ETL性能紀(jì)錄

成功案例

• Citi Group runsLava market montage解決方案運(yùn)行在SQL Server上, 達(dá)到每秒200,000次以上的更新頻率

• Xerox采用SQL Server管理每天7百萬的事務(wù)處理，達(dá)到99.999%運(yùn)行時(shí)間

• American Power Conversion遷移至 SQL Server企業(yè)版---實(shí)現(xiàn)100%的快速響應(yīng)時(shí)間，節(jié)省費(fèi)用800,000美元

• VHA 從DB2的大型機(jī)遷移至SQL Server—提升了25%效率, 降低了89%的復(fù)制時(shí)間, 顯著降低了總擁有成本.

• Countrywide Home Loans選擇了SQL Server以提高性能，獲得高可用性

• Microsoft IT使用SQL Server來驅(qū)動 27TB的全球法定安全工具

• Nasdaq, 全球領(lǐng)先的科技股交易，實(shí)時(shí)定票系統(tǒng)，采用SQL Server處理高達(dá)每秒5000的事務(wù)量.

• Unisys UPSS system, 在 SQL Server上架構(gòu)23 TB的數(shù)據(jù)倉庫，進(jìn)入了數(shù)據(jù)倉庫峰值負(fù)荷的Top10行列.

• PRemier BankCard將12 TB的數(shù)據(jù)倉庫和OLTP數(shù)據(jù)庫升級到SQL Server.

• Danske Supermarket 在 SQL Server分析服務(wù)上運(yùn)行600GB的的多維分析，以及10TB的商業(yè)智能數(shù)據(jù)

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

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

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

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

其實(shí)大家剛開始用數(shù)據(jù)庫最關(guān)心的莫過于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ù)量應(yīng)該用數(shù)據(jù)庫的實(shí)際占用體積大小來比較，而不應(yīng)該用單表數(shù)據(jù)量的大小來比較！

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

在我眼中只是一個比較小的數(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ù)庫里面的大表，大家第一個想法就是使用表分區(qū)來管理它，表分區(qū)從SQL Server2005開始推出到現(xiàn)在SQL Server2014還是使用表分區(qū)

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

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

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

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

1、壓縮單獨(dú)某個分區(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ī)重新生成某個分區(qū)的數(shù)據(jù)（SQL2014 針對聯(lián)機(jī)索引操作事件類的進(jìn)度報(bào)告現(xiàn)在具有兩個新數(shù)據(jù)列：PartitionId 和 PartitionNumber）

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

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

6、CHECKFILEGROUP（SQL2005）

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

8、鎖升級可以提升到分區(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可能會沒有能力handle，但是，你的數(shù)據(jù)庫真的reached 100TB，那么你們公司的數(shù)據(jù)庫架構(gòu)師

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

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

視頻里面甲骨文技術(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ī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)核->存儲設(shè)備這種架構(gòu)，用戶程序和OS內(nèi)核之間存在一套IO接口

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

而Linux操作系統(tǒng)的IO行為跟Windows有很多不同之處的，兩者的文件系統(tǒng)的不同，兩者的IO設(shè)備驅(qū)動不一樣，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ò)存儲的機(jī)器來講更加好，上層的一個請求，對于下層少量的網(wǎng)絡(luò)數(shù)據(jù)包

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

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

三、SQL Server的功能

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

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

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

而MySQL的Query Throttling針對的是

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

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

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

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

我這里不評論好壞，我只想說各有各的優(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這個行業(yè)

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

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

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