轉載http://geniusmatt.blogbus.com/logs/75269846.html
前言
最近計劃做pureScale高可用性及擴展性測試，收集了一些這方面的資料，09年年末也有過一次和Oracle關於Exadata V2產品的交流。嚴格意義上，pureScale和Exadata V2沒有可比性。pureScale不是Exadata V2那樣的軟硬件集合的一體化機架解決方案，它更像是在DB2 V9.7之上的性能及功能擴展。然而這兩個產品在許多方面都使用了業界的新技術，代表了數據庫架構的發展方向。因此我覺得有必要從不同的維度，對兩個產品做下比較。
比較項目包括：
歷史
架構
技術特點
成本
擴展性
比較項目
歷史
Exadata
Exadata V1 –September 2008 (Oracle OpenWorld Conference 2008)
使用HP平臺服務器，爲數據倉庫設計。
這個階段Exadata的設計目標應該是針對Teradata的數據倉庫產品而特定的。
Exadata V2 – November 2009
使用Sun X86平臺服務器，增加了Flash Cache存儲中間層，爲OLTP和數據倉庫設計。
值得遺憾的Sun的UltraSPARC IV+並沒有用到Exadata V2上面，儘管在單核計算能力上比不上IBM的POWER7芯片，但是UltraSPARC IV+芯片的多線程並行計算能力絕對是亮點。
儘管如此，nehalem也算是不差的選擇。
pureScale
DB2 pureScale – October 2009
2009年10月9日IBM對外發布了pureScale項目，在此前的很長一段時間，它都處於高保密狀態。
在pureScale之前，DB2在不同版本操作系統上支持：SMP、share nothing(DPF)。而pureScale是作爲IBM在主機業務外對Share Disk架構的實踐。
而pureScale的設計目標，借用IBM自己的話說就是：OLTP業務上實現高擴展性、對應用透明、持續的可用性。
可以很清晰的看出來兩個產品的發展思路：
Exadata從V1的專營OLAP，轉到OLAP和OLTP通吃。但是用本來是提高OLAP業務性能的技術，給跑OLTP的業務使用的思路，透露出Oracle對於Exadata的想法很邪惡。
pureScale則針對OLTP業務，滿足OLTP業務最關心的可用性、業務透明性及擴展性的需求。
僅僅從產品定位方面，pureScale勝出一籌。
架構
Exadata
在Exadata的集成數據庫解決方案中主要包括兩部分：數據庫服務器網格、存儲服務器網格。滿配機架包括8臺Sun X86平臺(XEON processor)的數據庫服務器，14臺Sun X86平臺的存儲服務器(每臺12塊2TGB的SAS/SATA盤，並配置Sun Flash Cache)。
數據庫服務器網格是基於RAC集羣，數據庫的存儲管理使用ASM，這個層面沒有什麼新意，不做累述。
存儲服務器網格基於Exadata Cell的概念，即每個存儲服務器是一個Exadata Cell。由於使用ASM，因此在存儲層面上的冗餘及條帶設計都由ASM負責。因此IBM會說，Exadata存儲集羣無法使用RAID技術。存儲服務器技術的最大亮點是實現了Smart Scan功能（將全表掃描的SQL交給存儲服務器預處理），達到的效果是存儲與數據庫間只傳輸結果集，不傳輸數據集，有效的提高了I/O效率。
InfiniBand網絡層負責連接數據庫服務器網格和存儲服務器網格。支持實現Smart Scan功能的iDB協議。
數據庫服務器網格之間的通信（RAC集羣Global Cache交互）依舊基於TCP/IP協議。
pureScale
作爲一種非一體式解決方案，對於pureScale的架構說明集中在數據庫集羣。
數據庫服務器集羣是運行DB2 V9.8的IBM中高端P系列服務器（P550以上），被稱爲DB2 Member。
pureScale數據庫集羣的亮點是採用了集中管理鎖定和緩存的Global Cache管理方式。這個概念是來自於System z Sysplex。充當管理者角色的服務器被稱爲 DB2 CF(Coupling Facility)，CF primary將共享數據放在自己的內存中，統一協調多個成員對共享數據的訪問。
存儲部分採用支持InfiniBand網絡的SAN架構，其上搭建IBM的共享文件系統GPFS。
InfiniBand網絡層負責連接數據庫服務器網格和存儲服務器網格。支持RDMA功能，因此不但負責傳輸存儲I/O，也負責存儲內存I/O。
可以看出，Exadata的優勢是在存儲I/O的處理環節，而pureScale則將重心放在了內存管理方面。這也是由兩個產品最初的設計背景決定的。
技術特點
Exadata
Flash Cache
使用閃存作爲存儲中間層，存放“熱”表。這是V2在V1基礎上，針對OLTP應用作出的改進。
Infiniband Connectivity
與其他網絡協議(如TCP/IP)相比，InfiniBand具有更高的傳輸效率。原因在於許多網絡協議具有轉發損失的數據包的能力，但是由於要不斷地確認與重發，基於這些協議的通信也會因此變慢，極大地影響了性能。
Exadata Cell
Exadata Cell可以看作是一臺插滿12塊本地磁盤(SAS/SATA)的PC服務器，數據的保護基於ASM硬盤組的鏡像和hot swappable Disk，而不是傳統存儲的RAID和hotspare。存儲與EXADATA之間的通信通過基於InfiniBand的iDB協議進行，傳輸SmartScan產生的結果集而不是傳統數據塊，藉以減少磁盤子系統的吞吐量。針對share disk架構必然會遇到的DB Server的I/O爭用問題，Exadata可以定製IORM，將共享存儲的I/O資源按比例分配給不同的數據庫使用。
pureScale
RDMA
利用基於InfiniBand的 Remote Direct Memory Access (RDMA) 直接對遠程服務器的內存執行寫操作。因此可以通過集中式的CF機制來防止那種分佈式鎖維護的高開銷。據說使用DDR InfiniBand進行通訊，pure Scale數據庫節點間的內存通訊能像運行並行數據庫集羣的SMP box的系統板間內存通訊一樣快。Global buffer pool存儲成員提交的共享數據頁。Global lock manager管理成員順序訪問對象。Shared Comunication Area提供DB2控制數據的一致性機制。
InfiniBand
同Exadata部分
SVC（SAN Volume Controller）
"Scalable, high performance InfiniBand-attached SAN Volume Controller"
SVC提供最小兩節點配置的集羣，提供3GB/s的最大讀性能。
成本
Exadata
整體解決方案的成本一般都不會太便宜，值得欣賞的一點是Exadata並沒有像pureScale一樣刻意限制其只能使用中高端服務器，使用Xeon處理器的PC Server加上Linux的配置，貌似是一種價格便宜量又足的解決方案。然而還是那句話，作爲一種整體解決方案，其價格不僅僅限於硬件費用，此外若是應用於OLTP業務，強大的Exadata Cell的磁盤子系統，也有些殺雞焉用宰牛刀的意味了。
pureScale
目前只能在IBM中高端P服務器運行（P550以上），AIX 6L操作系統DB2 V9.8，IBM宣佈將把pureScale支持的服務器向PC server（x系列服務器）方向擴展，支持Linux及windows操作系統，但目前只是將來時。只有綁定技術才能獲得最大利益，IBM深諳其道。
擴展性
Exadata
Quarter Rack/Half Rack/Full Rack
通過線纜鏈接可以擴展到8個機架
pureScale
對應用透明的可擴展性，即不停機實現member的增減。
操作複雜度：pureScale在橫向擴展的操作較RAC簡單。
橫向擴展性：由於RAC會遇到共享數據管理方面的瓶頸，因此一旦應用設計有問題，Exadata集羣的表現將會很糟糕。由於使用了Exadata cell存儲服務器，因此在磁盤I/O方面的瓶頸並不會十分明顯。
pureScale有共享數據管理方面的優勢，但由於採用簡單的存儲方案，因此會存在磁盤爭用方面的問題。
由於二者都是shared disk方案，最終都無法避免的出現磁盤爭用方面的問題，因此橫向擴展能力存在最終瓶頸。
結論
由於兩家公司對產品設計理念的不同，因此在有些角度上，兩個產品看似沒有可比性。此外在相同的技術層面上，性能，可用性以及成本存在相互掣肘的關係，因此不能從單一角度，去評定系統優劣，總之一句話，沒有最好的產品架構，最適合自身業務的架構，纔是最好的。
