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

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

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

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

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

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

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

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

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

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