效能神化，聊聊Exadata 的“七宗罪”

什麼是Exadata？它跟國內的一些oracle資料庫一體機品牌一樣，是一套專為Oracle資料庫打造的軟硬一體化的資料庫平臺，俗稱“資料庫一體機”，你可以簡單理解成，它們是一個平臺，只要把Oracle資料庫跑在這個平臺上面，就可以跑的又快又穩又安全。

接下我來跟大家聊下Exadata的七宗罪，用“罪”這個詞當然是誇張的，主要的目的還是讓大家瞭解到Exadata那些可能還不為人知的一些缺陷，有些缺陷甚至是巨大的，甚至會讓你感覺Exadata的這些專有技術非常的雞肋。 如果Oracle公司可以看到這篇文章，能夠對產品加以改進，那為寫這篇文章花費的數個小時也就不白費了。

效能，吾將上下而求索

說“罪”之前，先說說效能的事，因為效能很重要。

自然和自然的法則在黑夜中隱藏；上帝說，讓牛頓去吧！於是一切都被照亮。

在效能方面很多人把Exadata神化了，Exadata不是牛頓。

造成這一局面，很大程度來自於Oracle收服了大量的技術人員的心，這些人對Exadata的專有技術津津樂道。至於這些技術是不是容易應用，以及應用的條件，技術人員很多時候是不關心的，如果不經過訓練，他們很多時候缺乏產品思維。

人類在歷史上有三個問題一直未曾解決，飢餓，戰爭和瘟疫，未來簡史的作者尤瓦爾.赫拉利說，人類直到21世紀，才總算解決了這三大難題。

資料庫領域也一直被一個問題困擾著，那就是效能。特別是，網際網路來了，效能的問題更是捉襟見肘。

很多老人的記憶裡都有著吃不飽的經歷，一旦浪費一些糧食，會遭遇巨大的心理譴責，不過根據我的觀察，如果他們浪費了一些衣服（買了幾乎不穿）這種譴責會非常少。其實不管是衣服和糧食，都是人類勞動的產物，本質沒有任何區別，都不應該浪費。

效能猶如糧食，在資料庫的歷史上，一直就不夠用，當年在阿里從事應用DBA的那會兒，資料庫都是要精細化調優的。到了現在，藉助於技術進步，各種高效能的架構其實已經讓效能不成為問題了，但是，還是會發現，這種擔心效能不夠的心理還在影響著非常多的人。

此外，使用者特別在意效能還有其他的一些原因，也一併列在這裡：

• 效能指標好量化。效能作為一個好度量的指標，使用者容易把各個供應商的產品區分開。就像我們的高考一樣，它的本質目的並不是為了培養人才，而是為了區分人才，透過一個非常簡單的標準也就是分數把人區分開。效能的道理也是一樣的，它非容易測量。當然，我自己不是非常認可這種區分的方法，對於產品的選擇，效能只是一個小的方面，就像你選擇一個車，不能只看跑得快不快，你一定還關注它的內飾、安全性等等因素。

• 效能如果是無限的，那麼就可以充分解放業務的想象力。某證券的漲樂財富通的APP可以做到5秒自動重新整理賬戶資訊，要知道每秒有幾百萬客戶線上，這個在傳統的IOE架構下是不可想象的，有了資料庫一體機，就可以釋放業務的想象力。

Exadata第一罪，第一殺手鐧功能無法在真實環境中落地

那麼Exadata的效能怎麼樣呢？花開兩朵，各表一枝。

OLTP，殺手鐧毫無用處

在OLTP方面，相對於國產的資料庫一體機品牌，Exadata並沒有優勢。主要都是透過利用SSD，以及高效的儲存層協議來最大程度提高IOPS，降低IO延遲，畢竟對於OLTP系統延遲是關鍵。對於IOPS來說，IOPS的值越大，越能保證併發量。這裡還需要提一下serversan，傳統的集中式儲存，機頭控制器還有儲存的前埠很容易成為效能瓶頸，但是一體機都是使用的serversan，相當於每一個serversan的節點都是一個個可以單獨提供動力的節點，保證了IOPS和頻寬的可擴充套件性。可以把集中式儲存想象成綠皮火車，火車跑得快全靠車頭帶，而serversan是動車，每個動車組都單獨提供動力。

可能有Exadata的技術極客會提到Exadata的RDS協議，這個協議是用來叢集間傳遞資料塊的，那什麼時候需要傳遞資料塊？在多個節點都需要修改這個塊時。所以如果去設定一些極端場景，例如多個叢集節點對少量的熱點資料頻繁做更新，那麼資料塊需要不斷的在叢集間傳遞，這種極端場景下，RDS協議可能會比IPoIB協議會有優勢，例如用HammerDB或者Swingbench這種壓測工具去做效能測試把壓力開到最大（CPU跑滿），兩者可能會有5%左右的差異。RDS並不是銀彈，錦上添花而已。

OLAP，鏡中花，水中月

• OLAP方面呢？要知道Exadata本來就是為資料倉儲開發的。它的殺手武器就是它的儲存解除安裝。儲存解除安裝做到了 1）可以把大量的操作offload到儲存層完成，節省計算節點的資源 2）第二點也是最重要的一點，可以快速的過濾掉那些不需要掃描的資料，這樣不但提高了掃描的效率，還變相的提高了儲存到計算的頻寬。也就是說，Exadata不用在物理裝置上做文章，例如把互聯層從40GB升級到100GB，透過解除安裝功能，它就能達到56GB甚至100GB的效果，甚至更高。因此，理論上它比國產的一體機品牌在OLAP方面要強。

真強嗎？讓我這個圈子裡的人爆一點料給你聽一聽。

先思考一個問題，這個殺手鐧也就是解除安裝功能什麼時候能夠被用到？

答，天時地利人和，不比集齊七顆龍珠召喚神龍的難度小。Exadata的銷售人員是不會告訴這一點的。接下來來具體說一說。

索引的痛

要啟用解除安裝或者說smart scan，第一個限制的條件是，SQL語句的執行計劃必須是全表掃描（全索引掃描也可以認為是全表掃描）。

smart scan是解除安裝的一個型別，用於SQL語句，解除安裝還可以對資料庫檔案的快速建立，RMAN增量備份等有效果，不過這篇文章並不是做技術的深入探討，簡單的把解除安裝和smart scan做了等同。

也就是，如果你的系統是OLTP類的訪問，這個殺手級特性對你是毫無作用的，因為OLTP的特點是查詢短小精幹，要走索引。解除安裝功能只能用於偏分析類的系統（例如OLAP），但是請注意，重點來了，在這種分析型場景下，表上不能有相關的索引，否則，按照Oracle的CBO演算法有極大可能執行計劃不能滿足走全表掃描這個前提。

你可能會說，那不建索引不就完了嗎？事實的情況是，每個DBA都或多或少，有哪麼些索引情節，搞一堆索引在表上。這也是你為什麼能夠聽到很多Exadata的工程師去幫客戶最佳化SQL給出的建議是：“刪掉索引”。甚至這句話被傳的還神乎其神，說，Exadata太神奇了，沒索引才跑得快。

不過且慢，刪掉索引真的可以解決所有的問題嗎？不但可能解決不了問題，而且離系統崩潰也不遠了。大多數客戶的環境，都不是那麼的純粹，不是純OLTP或者純OLAP，這些索引可能在OLTP業務下是需要的，如果為了讓分析型的任務跑得快，把索引刪掉，那麼就會影響那些OLTP型業務的服務質量了，而 OLTP型的任務對延遲又是最為敏感的。 試想，如果每次查詢淘寶訂單都要十幾秒，你一定要瘋掉，十幾秒的時間都可以看一個抖音短影片了。

至此死迴圈產生了。索引是刪還是不刪，我遭遇過的大多數客戶，都選擇了不刪。就讓解除安裝功能歲月靜好在那美美的待著，無為而治，更為痛心的是，客戶買的Exadata有1/3的錢都是為了這個功能付費，接觸的某證券客戶，經過統計，只有不到1%的SQL可以用到解除安裝功能，其他99%的沒有特意經過最佳化的SQL都走了索引掃描。

必須開啟direct path read讀取方式

能用上解除安裝的第二個條件是，查詢必須要走direct path read方式，也就是讀取的資料不經過buffer cache，直接放入到資料讀取程式自己的私有記憶體（PGA）中，現實的情況是，不少使用者把這個直接路徑讀是關閉掉的，因為這些全表掃描的SQL導致了過多的物理IO。

所以這對客戶來說又是一個巨大的挑戰。

曾經遭遇的某銀行的Exadata上一個案例是，某個表上有頻繁的增刪改操作，奇怪的是，這個“寫入多”的行為導致表上的其它查詢操作變得非常慢，最後經過分析是由於很多查詢選擇了direct path read的讀取方式，導致每次讀取前都要先把 buffer cache中的髒資料刷到磁碟，等待刷盤的過程中，查詢會被阻塞，直到刷盤完成，一旦這種讀取操作比較多，就會有大量的查詢被阻塞。

Exadata第二罪，上，下，都是折磨

以上說了啟用解除安裝，這個超級殺手鐧的功能，所要滿足的前置條件，都很難滿足！

此外，你的應用需要做大量的測試驗證，中間DBA需要高度配合，而且這個DBA得是個高階專家，review每一個SQL，看是不是要加hint，還是刪索引，這是巨大的工作量，是個系統工程，需要多個角色的配合才能完成，如果為了省事，把所有的索引都刪掉，那麼你的系統離崩潰也不遠了，因為OLTP型別的SQL一定還是透過buffer cache這種記憶體讀的方式查詢的快。

解除安裝功能，在OLTP場景下，根本無法發揮作用。

即使退一萬步，你覺得自己團隊有大量的Oracle頂級專家，這些工作你都認，認為還是要上，就完了嗎？

並沒有，到了某一天，你接受了天啟，感覺到Exadata並沒有想象那麼好，想換掉它，悲劇又會重演，因為，你還需要把當初review過的所有的SQL重新review一遍，哪些加過的hint可能要去掉，或者把當初刪掉的索引再加回來，這又是一個極為漫長痛苦的過程。這個過程，我親身經歷過，而且現在還正在經歷（某銀行客戶）。

我非常認可一句話,

“人類技術的發展有一個很重要的概念，不斷地讓一個難被駕馭的技術，越來越容易地被普通人操縱。”

就像美圖秀秀戰勝PS，一個技術能被越多的人駕馭，價值也才越大，從這一點上來說，Exadata在鑽牛角尖了，客戶去落地使用這個產品是非常困難的。技術本身可以很複雜，但是對客戶的介面要足夠的簡單。

Exadata第三罪，上帝的歸上帝，凱撒的歸凱撒

Exadata有一個EHCC的壓縮功能，這也是他的第二大殺手鐧功能。畢竟Exadata這個產品主要是面向資料倉儲系統的，壓縮功能被提到這樣的地位並不為過。

不過這裡我負責任的告訴大家，該功能只能在Exadata上使用，意味著你的容災也得用Exadata來搭建，不能使用通用平臺來做Exadata的容災，這是巨大的成本啊，相信就是銀行，面對這樣的成本，也得思量思量吧？

如果你選擇了用通用平臺來搭建Exadata的容災，使用EHCC壓縮過的資料將不能被訪問，除非使用特定的辦法花大量的時間去做解壓才行。此外，壓縮還會讓資料的備份和遷移同樣變得頭痛萬分。再有，資料的壓縮本身就如硬幣的兩面，節省了空間，消耗了CPU資源，更為重要的是，對於Exadata來說，壓縮是必須在計算節點完成的，不能解除安裝到儲存節點，如果要壓縮的資料量比較大，那就得思考一下，畢竟客戶是要為計算節點的CPU付大量的license費用的。

這裡提一下，我接觸到的很多客戶其實是把壓縮功能關閉掉的，做這樣的犧牲，就是為了能夠使用通用平臺來搭建容災，不過可惜的是客戶是為了這個功能支付了大量的費用的。

以上介紹了這麼多都說明了Exadata是一個封閉的系統，上了這個船，你就得一直在船上，這個船可不是諾亞方舟。 它讓使用者產生了巨大的沉沒成本，被沉沒成本綁架後，使用者只能老老實實呆在船上。很多人只是買了一張40塊的電影票，看到爛片，也得堅持把片看完，更別說是一個幾百萬上千萬的裝置。

Exadata第四罪，技術門檻太高

從市面上很難招聘到一個懂Exadata的DBA，而Exadata要想用的好，恰恰需要一個非常懂行的人。如果使用者的DBA技能不達標，那就只能“無為而治”了，我經常參加一些oracle圈子裡的活動，接觸到的很多第三方資料庫服務公司的專家都說，對於Exadata，絕大多數客戶也都是“無為而治“的。可是，客戶為了那些殺手鐧的功能是支付了幾百上千萬的費用的。就像買了一個汗血寶馬，結果沒人能夠騎，騎的門檻很高。

Exadata第五罪，Exadata並不包含license

給大家糾正一下：不要覺得買了Oracle Exadata就理所當然的包括了Oracle資料庫的license，Oracle Exadata是個Oracle資料庫的硬體執行平臺，它本身不包括Oracle License，各位買過Exadata的可以看一下，是否Exadata的軟體清單裡包括了Oracle 的資料庫許可，客戶需要重新購買。

Exadata第六罪，萬年不變的40G

我們都知道計算機硬體基本上按照摩爾定律在發展，Exadata 自從2008年推出至今，在近10年的時間裡，核心網路一直初心未改執行在40Gb的IB上的，而國內的一體機早都有100Gb以上的產品了，頻寬的效率提高了3倍。可能有人要說，它有解除安裝功能，40Gb 夠用了，不需要提升頻寬，但是前提是要有專家DBA對SQL做精細化的調優，這將帶來巨大的系統管理成本，資料庫系統也越來越複雜。大家為什麼不接受簡單高效的方式，升級到100Gb-200Gb的網路呢？

我想最大的可能是因為，如果它升級了網路，它存在的合法性就不存在了。Exadata最大的賣點就是透過解除安裝功能來最大化提升自己的價值，如果透過提升硬體來達到提升效能的目的，它豈不是沒有面子？這從一定程度上來說，還是以“產品為王”的思路來做產品，而不是以使用者的需求和痛點來做產品。國產的一體機品牌在這個方面更願意採用更簡單、對DBA和業務更透明的的方式來釋放資料庫的效能。

Exadata第七罪，維保 & 擴容 & 服務

第七點就不詳寫了，誰用誰知道，好像沒遇到過對Exadata 維保、擴容滿意的使用者，可能是高額利潤賺習慣了吧，沒辦法說！另外維保、擴容，升級都極其複雜，服務響應也非常地不及時。其餘內容，大家自行腦補就好。

Exadata的未來

說說Exadata的未來，我有點鹹吃蘿蔔淡操心了，我曾經發朋友圈說既然Exadata這麼複雜，如果可以結合人工智慧，深度學習技術，那麼它的前景還是非常不錯的，但是最近又反思了這個問題，可能答案並沒有這麼簡單。（事實上，oracle公司從18C起已經開始搞自治資料庫了）

就像上面提到的， Exadata有一個非常大的問題，是不容易使用，感覺上就像是一堆熱愛技術的極客搞了一個使用門檻很高的產品 ，如何才能降低它的使用門檻呢？我以前認為的答案是，藉助於深度學習的人工智慧技術，讓Exadata的透過自治來達到降低使用門檻的目的。

但是我這個想法現在想想不太接地氣。大多數客戶選擇使用Exadata，會把比較重要的業務放上面，只要是重要的業務系統，都有一個顯性的需求，“我要穩穩的幸福”，一定不希望，今天自治系統決定加個索引，明天又決定刪個索引，這會帶來不確定性，而核心系統最需要的屬性就是確定性。

你可能會認為我是一個技術悲觀派，但是我要說明的是，我非常看好人工智慧在資料庫領域的價值的，但是它的最大的應用場景是在非核心的資料庫場景上，這些資料庫，不需要DBA操心，哪怕慢，慢就慢點，只要省事就好了，這些非重要的業務系統對於企業來說數量上也是非常多的，因此自治資料庫是非常有前景的，但是核心資料庫還有得搞，路還很長。等自治資料庫也可以提供確定性了才能去考慮。