甲骨文公司副總裁及大中華區(qū)技術(shù)產(chǎn)品事業(yè)部總經(jīng)理吳承楊強(qiáng)調(diào)：整合信息系統(tǒng)是企業(yè)像大數(shù)據(jù)時代過渡的一項(xiàng)重要舉措，構(gòu)建數(shù)據(jù)庫要從平臺層考慮，而非應(yīng)用層，從而避免信息孤島的形成。在開發(fā)關(guān)系型數(shù)據(jù)庫時，應(yīng)首推甲骨文的企業(yè)級數(shù)據(jù)庫。

今天的CIO在選擇數(shù)據(jù)庫平臺時都應(yīng)從哪些角度來進(jìn)行考量？

我覺得首先來看一看今天企業(yè)里面經(jīng)常談的一個問題就是整合的問題。為什么會談到整合的問題，因?yàn)檎暇褪悄悻F(xiàn)在有很多沒有被整合的東西，所以是信息孤島，因?yàn)橛行畔⒐聧u的存在，所以需要整合。反過來講為什么信息孤島會存在，誰都沒有希望在建系統(tǒng)的時候要把它做成一個孤島。原因在于很多時候CIO在選擇建一個整個企業(yè)的系統(tǒng)的時候，它是希望由應(yīng)用來驅(qū)動。也就是說他在不斷建一個一個應(yīng)用，比如說我要建一個ERP的應(yīng)用，比如說我需要建一個人事的應(yīng)用，等等有各種各樣的應(yīng)用，有風(fēng)險的應(yīng)用。這樣你會發(fā)現(xiàn)每一個應(yīng)用他都建立起來了，但是當(dāng)他建立了十個、二十個，比如說一個銀行最少有七八十個應(yīng)用，建了七八十個應(yīng)用以后，他就發(fā)現(xiàn)原來應(yīng)用和應(yīng)用系統(tǒng)之間就開始有信息孤島，然后他開始希望做整合。實(shí)際上如果說你選擇的時候如果多考慮一下平臺層的問題，你可以讓信息孤島的問題有很大程度在早期就能解決，而不是到事后解決。這個平臺層，實(shí)際上最重要的一點(diǎn)首先就是應(yīng)該考慮數(shù)據(jù)庫。你數(shù)據(jù)的庫的選擇是非常非常重要的一點(diǎn)，所以說如果說我覺得我給CIO***個建議，你首先要考慮建一個平臺，而不僅僅是說根據(jù)你的業(yè)務(wù)需要建各種各樣的應(yīng)用，應(yīng)用是需要的，但是平臺也是非常重要的。這樣在數(shù)據(jù)庫的選擇上，我覺得重要的一點(diǎn)在于你應(yīng)該用一個數(shù)據(jù)庫即云的服務(wù)這樣一個概念來選擇。

大家可能會問，你今天來講怎么樣建數(shù)據(jù)庫的云服務(wù)呢？大家知道現(xiàn)在有很多種數(shù)據(jù)庫，甲骨文當(dāng)然是其中最重要的一種關(guān)系型的數(shù)據(jù)庫。甲骨文的市場份額也非常高，超過了50%。但是你會發(fā)現(xiàn)還有一些其他的數(shù)據(jù)庫，甚至于還有一些開源的數(shù)據(jù)庫。比如說甲骨文非常著名的MySQL當(dāng)然還有一些其他的比如說非關(guān)系型的數(shù)據(jù)庫，比如noSQL，這些東西怎么選擇呢？你既然要建立一個database service的平臺，你首先應(yīng)該想清楚哪些你是關(guān)系型的，哪些是非關(guān)系型的，這個是最重要的一點(diǎn)。你今天來講，你不可能用一個關(guān)系型的數(shù)據(jù)庫來解決所有的非關(guān)系型和關(guān)系型的問題。這個世界不是一個只是非黑即白的世界，簡單來講，比如說大家知道非關(guān)系型里面很重要一點(diǎn)就是noSQL和Hadoop，這里面是***的技術(shù)，現(xiàn)在業(yè)界有一種思潮認(rèn)為我可以用Hadoop解決所有的問題，不僅僅可以解決非關(guān)系型的問題，也可以解決關(guān)系型的問題。這個選擇這個想法對不對呢？這個答案首先我可以告訴各位肯定是錯誤的，為什么這么講？因?yàn)镠adoop實(shí)際上是谷歌發(fā)明的技術(shù)，但是今天即使在谷歌本身它關(guān)系型的數(shù)據(jù)庫也是由關(guān)系型的數(shù)據(jù)庫解決的，并不是用Hadoop解決的。

第二個問題在于，我是不是可以用MySQL來解決這個問題呢？大家說既然我同意了我不用Hadoop來解決這個問題。我用MySQL來解決這個問題可以嗎，MySQL也是一個關(guān)系型數(shù)據(jù)庫，只是它開源而已。這里面首先應(yīng)該有一個很明確的一點(diǎn)，不管是甲骨文所有的企業(yè)級數(shù)據(jù)庫和甲骨文的MySQL數(shù)據(jù)庫都是來自于同一家公司甲骨文。MySQL我們的定位它是解決一些簡單的事物性工作，而企業(yè)級是用甲骨文的企業(yè)級數(shù)據(jù)庫，大家說我是不是可以企業(yè)級的也是可以用MySQL解決，你到底希望你的投資是在數(shù)據(jù)庫層面上還是在整個應(yīng)用層面上。因?yàn)镸ySQL這樣的原因它沒有辦法支撐數(shù)據(jù)量很大的情況，所以他就要求把數(shù)據(jù)庫拆分。

舉個簡單的例子，假如說你是一個廚師，你希望你的后面有各種各樣的原料，你的原料里面有肉，有魚，有蔬菜，可能還有一些其他的配料。你到底是用一個大冰箱來裝，還是分成若干個小冰箱來裝。如果說你分成若干個小冰箱裝，你就要明確肉是裝在1號冰箱的，魚是裝在2號冰箱的，你的蔬菜是3號冰箱。如果你還有各種各樣的配料，你一定要非常非常清楚。因此在應(yīng)用層面，你就要確定我要取肉一定是從1號冰箱，但是如果說甲骨文的關(guān)系型數(shù)據(jù)庫，企業(yè)級數(shù)據(jù)庫你就是放在一個大冰箱，整個就是一個一千立升的冰箱，所有的東西擱進(jìn)去，只要在這個冰箱里面，就可以取到你想要的東西。這個實(shí)際上就是甲骨文的關(guān)系型數(shù)據(jù)庫，這是一個簡單的例子和MySQL的區(qū)別。

也就說你選擇甲骨文的企業(yè)級數(shù)據(jù)庫，對你來講，你在應(yīng)用層相對來講，你是不需要做太多的工作。反而如果說你選擇了MySQL，你需要在應(yīng)用層做很多的一些工作，確保你的分庫可以滿足你整個系統(tǒng)的要求。這點(diǎn)來講你要做一個選擇，不是說MySQL不能用，而在于你到底是需求什么。大家會說對CIO來講，我就是希望在應(yīng)用層做一些工作，然后我就把它拆成每個庫，是不是可以呢？答案是可以的。但是有一個問題大家不要忘記，***你的這個集成商你需要以后一直靠著它，這樣你對集成商的需求性是很大的，依賴性很大。某種程度他是被集成商某種程度是綁定的，這是***個問題。

第二個問題，因?yàn)槲磥頂?shù)據(jù)庫很重要的一點(diǎn)不僅僅是這個數(shù)據(jù)庫本身，很重要一點(diǎn)是它的很多選件。如果說大家是使用照相機(jī)會知道，照相機(jī)上面會配各種各樣的鏡頭。照相機(jī)能拍出好多照片跟鏡頭是非常非常大的關(guān)系，MySQL上面相對的選件就會比較少，而甲骨文上面選件就會非常非常多，并不是這些功能不需要。比如說安全性，比如說數(shù)據(jù)的一致性等等這些方面，都是有各種各樣的一些選件。因此來講，當(dāng)然你使用MySQL以后，這些選件你都需要找人來專門開發(fā)，這樣你才能達(dá)到性能。所以你可以看到如果你選擇MySQL，答案理論上是可以的，問題是你是不是愿意投入這么多的資源來做這樣一件事情，我們實(shí)際上大家可以看到現(xiàn)在業(yè)界流行的方法，你把這些專業(yè)的事情留給專業(yè)的人做，其實(shí)作為一個企業(yè)來講，數(shù)據(jù)庫的開發(fā)，選件的開發(fā)并不是你的強(qiáng)項(xiàng)，你的強(qiáng)項(xiàng)是業(yè)務(wù)。

因此你應(yīng)該把數(shù)據(jù)庫的事情給專業(yè)的數(shù)據(jù)庫的人來做，這就是甲骨文來做。所以總體來講我們給CIO的建議，***在你選擇你的應(yīng)用的時候，在你選擇整個系統(tǒng)的時候，不應(yīng)該僅僅考慮應(yīng)用層，一定要選擇平臺層，以減少你未來的信息孤島的風(fēng)險。再選擇平臺層的時候，最重要的是數(shù)據(jù)庫，數(shù)據(jù)庫的選擇，今天用Hadoop來解決所有的問題是不可能的，反過來講，用MySQL一種開源的數(shù)據(jù)庫，和甲骨文來比，的的確確都可以解決關(guān)系型數(shù)據(jù)庫的問題。但是問題是大家的價值取向不一樣，如果按照總體擁有成本來說一定是甲骨文的企業(yè)級數(shù)據(jù)庫擁有更好的TCO。