簡介

　　數據庫已經是絕大多數IT應用的核心，各種數據庫看上去很大不同，多層體系結構以及SOA的發展，使得應用邏輯的實現前移。數據庫的性能，與其功能相比較，變得越來越重要了。因此，性能是衡量數據庫的非常重要的方面，我們這里將討論數據庫性能基準的五個常見問題。

　　1.Windows和Linux，哪個操作系統的性能基準結果更好？

　　這是一個有爭議的很難回答的問題。雖然大部分可能認為Linux可能更快一些，但是Windows server平臺在過去的幾年中已經快速成熟了。下面是圖表1,它是在相同的硬件環境下執行得到的在線TPC-C基準結果的圖表，使用了32位和64位的Windows 2003 Server Release 2 和 CentOS 4 Update 3 (一個免費Redhat的企業版本)。

　　你可以看到，技術上看來是不分勝負的。因此,你可以按自己意愿選擇，或者考慮到培訓成本，可以選擇擁有較多系統管理員的那個操作系統。

　　圖1

　　2. 32位還是64位，哪種更好?這會影響操作系統的選擇嗎?

　　64位Unix 服務器已經有很多年了,但64位的Windows操作系統才剛剛變成現實。(Windows NT可運行在DEC Alpha上,但一直沒有真正進入主流。)很長一段時間，AMD的Athlon-64和Opteron處理器一直很出色。直到2006年中Intel的二代雙核CPU的出現，它的表現相當讓人驚訝！現在我們可以用更好的價格購買這些硬件。我們將能耗和房間制冷都計算到TCO中。

　　與32位相比，64位真的有明顯差異嗎?根據圖表1,回答是否定的。但那是因為64位提供的主要優勢在于增加了可尋址內存。圖表2將再次顯示TPC-C基準執行的結果，但系統和數據庫可以分配的內存的總數量增加了。　

　　圖2

　　我們有了這些很清楚的結果。這些數據顯示,如果你的服務器有2GB或少一些的內存,在32位和64位的處理下沒有明顯的差別。但當你的服務器的內存增加到超過2GB以后,64位的優勢就會顯示出來.盡管諸如Oracle數據庫有32位聯接選項來欺騙數據庫，使之可以訪問稍多的內存(知名的巨大內存模型)，這僅僅只能有一點效果。特大內存對系統和數據庫來說，可以不斷實現性能的改進。

　　一般情況下，服務器的內存大于4GB時，建議使用64位。不過值得注意的是，有時某些類型的硬件（例如驅動器，iSCS）和更新的數據庫選項(例如，ASM,OCFS)在32位的Linux上工作得更好。

　　3.哪個數據庫擁有最好的性能基準：Oracle 10g，SQL Server 2005 還是MySQL 5.0?

　　這也是一個有爭議的問題。說到它，僅僅是把經常提到最多的三個數據庫拿來討論。（這里并不是有意忽略DB2－UDB，PostgreSQL或所有的其他數據庫）。我們知道數據庫廠商一般是不歡迎公布性能基準數據的，特別是在它們之間的比較情況。盡管如此，我們來討論這個常見的問題。圖表3顯示了在MySQL,SQL Server和Oracle數據庫上執行的TPC－C基準的結果。

　　圖3

　　碰巧的是我們不必冒任何廠商憤怒的風險，因為性能結果顯示，它們的技術不分勝負。同樣，你可以按照你的意愿選擇數據庫，或者是哪個數據庫管理員多就選擇哪一個。

　　當然，在這些廠商之間的花費是不同的，但是因為沒有人會按照報價購買產品，所以按照這個因素進行比較TPC-C是很困難的。

　　4.如何確定一個服務器所能支持的最大并發OLTP用戶數?

　　這始終是一個很難回答得問題，因為人們經常想聽到，“Dell 1850能處理多少的并發用戶量。”事實上，即使是同一系列的服務器，有相同的內存容量，但是也會由于CPU的數量、CPU的時鐘頻率、CPU的內核數、高速緩沖存儲器的大小等因素導致能力的差異。比較服務器是很困難的，除非你有看起來幾乎一樣配置的機器。但是你也需要比較相同的網絡和磁盤IO等情況。假設你那樣做，問題變成你如何分析這樣的基準結果，并準確確定那臺服務器的最大并發用戶負載。圖表4顯示了TPC-C基準的結果，只在一臺服務器上確定拐點（即用戶負載開始對響應時間有負面影響）。

　　圖4

　　如果你的最終用戶要求響應時間（最常見的指標）少于2秒，那么在200個并發用戶這個點你應該停下來。圖4顯示這個服務器可支持多達250個用戶并發直到響應時間達到無法接受的急驟上升的點. 在這種情況下，TPS比率開始趨于平緩或減少，這個例子中碰巧，這兩個點同時出現。但是并不總是如此明顯;這是因為有時兩個拐點并不一定排列的這么整齊。當拿不準時，建議通常關注TPC-C或OLTP類型事務的響應時間。

　　5.如何確定一個服務器所能支持的最大數據倉庫大小?

　　這又是一個很難回答的問題，因為大多數人想聽到是，“處理X千兆字節的數據需要一臺Dell 1850。”上文中提到，比較服務器是不容易的事情，除非你擁有的主機幾乎有一樣的配置，以及一樣的網絡和磁盤I/O環境。磁盤I/O在這里是特別重要的，因為TPC-H結果大部分是由磁盤數量來決定的。如果能比較服務器，那么問題就變為如何從基準結果中確定那臺指定服務器的最大數據倉庫的大小。在圖表5中，顯示了基于幾個強大的Oracle RAC服務器配置的TPC-H基準的測試結果。這些服務器訪問分布在多個SAN和超過100個磁盤上的300GB數據。

　　圖5

　　在TPC-H中，值得注意的是，應該同時關注整體運行時和間平均響應時間。TPC-H的詢問是非常復雜的，通常要花數個小時，或好幾天才能完成。

　　根據圖表6，最好的硬件配置大運行5小時，平均響應時間約4小時。然而，通過幾次運行時間很長的測試，實際的響應時間的變化是很傾斜的。因此，如果你的用戶對于高度復雜的決策支持查詢能接受運行時間在4個小時的，8個節點的集群將可以滿足要求。如果不能接受的話，那么需要購買更多磁盤，而不是增加更多的服務器。對于千兆容量的數據倉庫，使用500到1000個磁盤可以達到最佳的效果，這種情況并不少見。

　　圖5