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

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

還有就是小型機(jī)的縱向擴(kuò)展能力相當(dāng)強(qiáng)，比如CPU可以最多擴(kuò)展到24個(gè)，而對于X86服務(wù)器則是希望通過橫向擴(kuò)展來應(yīng)對小型機(jī)的縱向擴(kuò)展能力。而橫向擴(kuò)展自然帶來的一個(gè)問題就是分布式的問題。

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

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

由于在去小型機(jī)，Oracle數(shù)據(jù)庫和集中存儲(chǔ)情況下，將直接轉(zhuǎn)換為數(shù)據(jù)庫層的構(gòu)建成為一個(gè)share nothing的分布式數(shù)據(jù)庫集群。而現(xiàn)在的MPP+Share nothing的New SQL數(shù)據(jù)庫，類似Greenpulm，Vertica，Hive等更多的都是解決OLAP層面的問題。而對于去IOE首先需要解決的是聯(lián)機(jī)事務(wù)處理層面的事情。

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

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

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

由于采用數(shù)據(jù)庫拆分和DaaS層，對于應(yīng)用層的應(yīng)用構(gòu)建將帶來比較大的變化，特別是很多原來數(shù)據(jù)庫沒有拆分的時(shí)候一個(gè)SQL就搞定的問題，一個(gè)通過數(shù)據(jù)庫層事務(wù)就能解決的問題，都會(huì)變成了分布式事務(wù)問題，或者多次調(diào)用服務(wù)操作才能夠解決的問題。這往往才是說的去IOE的一個(gè)關(guān)鍵。