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

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

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

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

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

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

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

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

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