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

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

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

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

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

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

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

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

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