大家要注意到去IOE當前本質已經是變化為解決數據庫層面的問題，對于應用服務器和中間件，采用X86服務器和負載均衡，集群技術本身已經不存在太大的問題。包括起可靠性，可擴展性和性能等。當前我們看到的很多應用本身也是應用服務器層基本全部X86+虛擬化，而對于數據庫往往還在使用小型機和集中存儲。

現在的高性能的X86服務器性能已經趕上了3，4年前的中端小型機性能。比如現在的6到8C，8核高配的X86服務器性能能夠達到80-100萬TPMC，而3年前的中端小型機性能也就60萬TPMC的樣子。對于小型機的替代大家最關心的問題仍然是高可用性，小型機基本可以達到5個9的高可用性，而現在隨著類似至強7500等X86服務器引入了大量在小型機中才使用到的RAS技術，基本達到4個9是沒有太大問題的。

還有就是小型機的縱向擴展能力相當強，比如CPU可以最多擴展到24個，而對于X86服務器則是希望通過橫向擴展來應對小型機的縱向擴展能力。而橫向擴展自然帶來的一個問題就是分布式的問題。

對于數據庫層面，拿MySQL數據庫來和Oracle數據庫做一個比較，當前第三方的評測是在相同的硬件配置條件下兩個數據庫的性能和Benchmark數據庫相當。而實際上對于數據庫層面我們更加關心的還是在海量數據下的復雜事務處理能力。如果對于存儲大表數據都在千萬行級別一下，可以說兩個數據庫可能不會出現太明顯的差距。而如果對于大于千萬或上億數據的海量數據OLTP處理上，Oracle估計還是具備有明顯的優勢。而對于這一個問題的解決，根據互聯網企業的經驗，仍然是通過數據庫的水平拆分和垂直拆分來解決這個問題。

類似EMC提供的集中存儲是另外一個重要的話題，可以看到在使用集中存儲的時候，我們很容易去實現類似Oracle的RAC集群，同時本身集中SAN,NAS存儲也具備更高的存儲高可用性和高可靠性。類似互聯網企業淘寶也曾經談到過，在采用廉價的本地磁盤存儲后，由于大量的IO磁盤讀寫也經常出現硬盤掛掉的情況。雖然這些可以通過RAID技術來避免單獨故障，但是對于存儲的高可靠性確實本地存儲趕不上集中存儲。

由于在去小型機，Oracle數據庫和集中存儲情況下，將直接轉換為數據庫層的構建成為一個share nothing的分布式數據庫集群。而現在的MPP+Share nothing的New SQL數據庫，類似Greenpulm，Vertica，Hive等更多的都是解決OLAP層面的問題。而對于去IOE首先需要解決的是聯機事務處理層面的事情。

那么對于Share nothing的分布式數據庫，當前也有類似Mysql Cluster技術來支撐，但是這種分布式數據庫雖然做到了高可靠性，但是由于需要支撐CUD操作，導致這種集群很難達到滿足實際應用需求的存儲容量和業務高性能。在實際的業務應用場景下，除了少量的類似MDM主數據場景比較適合采用外，真正的核心的大量業務操作和邏輯處理場景往往并不適合。

基于這種情況，當前最常用的技術就變化為了對數據庫進行水平拆分和垂直拆分，但是這種拆分我們希望的是對應用層透明，因此在數據庫上面引入了一個核心的DaaS服務層。但是當前的DaaS服務層很難做到數據庫的完全透明，同時對于上層的應用構建造成一定的約束。包括有些跨庫的Sql語句，類似跨庫聚合Group By等的語句不支持，這些都需要應用層自己去解決。

在跨庫后帶來的一個重要問題就是分布式事務的問題，對于DaaS來說可以解決部分分布式事務的問題，但是需要采用嚴格的XA兩階段提交來解決分布式事務，本身的高可靠性和一致性仍然需要進一步進行驗證。而對于應用，仍然需要應用去解決一些分布式事務的問題，即通過事務補償，BASE方法等去解決分布式事務的問題，這些本質上都是削弱了對高一致性的支持，這也是CAP定量經常說的，在一個分布式的系統中很難真正做到三者全部滿足。在滿足高可用性和分區容錯性的基礎上，往往需要犧牲一定的高一致性。

由于采用數據庫拆分和DaaS層，對于應用層的應用構建將帶來比較大的變化，特別是很多原來數據庫沒有拆分的時候一個SQL就搞定的問題，一個通過數據庫層事務就能解決的問題，都會變成了分布式事務問題，或者多次調用服務操作才能夠解決的問題。這往往才是說的去IOE的一個關鍵。