當然在這些廠商之間的花費是不同的但是因為沒有人會按照報價購買產品所以按照這個因素進行比較TPCC是很困難的
如何確定一個服務器所能支持的最大並發OLTP用戶數?
這始終是一個很難回答得問題因為人們經常想聽到Dell 能處理多少的並發用戶量事實上即使是同一系列的服務器有相同的內存容量但是也會由於CPU的數量CPU的時鐘頻率CPU的內核數高速緩沖存儲器的大小等因素導致能力的差異比較服務器是很困難的除非你有看起來幾乎一樣配置的機器但是你也需要比較相同的網絡和磁盤IO等情況假設你那樣做問題變成你如何分析這樣的基准結果並准確確定那台服務器的最大並發用戶負載圖表顯示了TPCC基准的結果只在一台服務器上確定拐點（即用戶負載開始對響應時間有負面影響）
圖
如果你的最終用戶要求響應時間（最常見的指標）少於秒那麼在個並發用戶這個點你應該停下來圖顯示這個服務器可支持多達個用戶並發直到響應時間達到無法接受的急驟上升的點 在這種情況下TPS比率開始趨於平緩或減少這個例子中碰巧這兩個點同時出現但是並不總是如此明顯;這是因為有時兩個拐點並不一定排列的這麼整齊當拿不准時建議通常關注TPCC或OLTP類型事務的響應時間
如何確定一個服務器所能支持的最大數據倉庫大小?
這又是一個很難回答的問題因為大多數人想聽到是處理X千兆字節的數據需要一台Dell 上文中提到比較服務器是不容易的事情除非你擁有的主機幾乎有一樣的配置以及一樣的網絡和磁盤I/O環境磁盤I/O在這裡是特別重要的因為TPCH結果大部分是由磁盤數量來決定的如果能比較服務器那麼問題就變為如何從基准結果中確定那台指定服務器的最大數據倉庫的大小在圖表中顯示了基於幾個強大的Oracle RAC服務器配置的TPCH基准的測試結果這些服務器訪問分布在多個SAN和超過個磁盤上的GB數據
圖
在TPCH中值得注意的是應該同時關注整體運行時和間平均響應時間TPCH的詢問是非常復雜的通常要花數個小時或好幾天才能完成
根據圖表最好的硬件配置大運行小時平均響應時間約小時然而通過幾次運行時間很長的測試實際的響應時間的變化是很傾斜的因此如果你的用戶對於高度復雜的決策支持查詢能接受運行時間在個小時的個節點的集群將可以滿足要求如果不能接受的話那麼需要購買更多磁盤而不是增加更多的服務器對於千兆容量的數據倉庫使用到個磁盤可以達到最佳的效果這種情況並不少見
[] []
From:http://tw.wingwit.com/Article/program/SQL/201311/16233.html
