溫馨提示×
您好，登錄后才能下訂單哦！
點擊 登錄注冊 即表示同意《億速云用戶服務條款》
您好，登錄后才能下訂單哦！
什么是Exadata？它跟國內的一些oracle數據庫一體機品牌一樣，是一套專為Oracle數據庫打造的軟硬一體化的數據庫平臺，俗稱“數據庫一體機”，你可以簡單理解成，它們是一個平臺，只要把Oracle數據庫跑在這個平臺上面，就可以跑的又快又穩又安全。
接下我來跟大家聊下Exadata的七宗罪，用“罪”這個詞當然是夸張的，主要的目的還是讓大家了解到Exadata那些可能還不為人知的一些缺陷，有些缺陷甚至是巨大的，甚至會讓你感覺Exadata的這些專有技術非常的雞肋。 如果Oracle公司可以看到這篇文章，能夠對產品加以改進，那為寫這篇文章花費的數個小時也就不白費了。
說“罪”之前，先說說性能的事，因為性能很重要。
自然和自然的法則在黑夜中隱藏；上帝說，讓牛頓去吧！于是一切都被照亮。
在性能方面很多人把Exadata神化了，Exadata不是牛頓。
造成這一局面，很大程度來自于Oracle收服了大量的技術人員的心，這些人對Exadata的專有技術津津樂道。至于這些技術是不是容易應用，以及應用的條件，技術人員很多時候是不關心的，如果不經過訓練，他們很多時候缺乏產品思維。
人類在歷史上有三個問題一直未曾解決，饑餓，戰爭和瘟疫，未來簡史的作者尤瓦爾.赫拉利說，人類直到21世紀，才總算解決了這三大難題。
數據庫領域也一直被一個問題困擾著，那就是性能。特別是，互聯網來了，性能的問題更是捉襟見肘。
很多老人的記憶里都有著吃不飽的經歷，一旦浪費一些糧食，會遭遇巨大的心理譴責，不過根據我的觀察，如果他們浪費了一些衣服（買了幾乎不穿）這種譴責會非常少。其實不管是衣服和糧食，都是人類勞動的產物，本質沒有任何區別，都不應該浪費。
性能猶如糧食，在數據庫的歷史上，一直就不夠用，當年在阿里從事應用DBA的那會兒，數據庫都是要精細化調優的。到了現在，借助于技術進步，各種高性能的架構其實已經讓性能不成為問題了，但是，還是會發現，這種擔心性能不夠的心理還在影響著非常多的人。
此外，用戶特別在意性能還有其他的一些原因，也一并列在這里：
性能指標好量化。性能作為一個好度量的指標，用戶容易把各個供應商的產品區分開。就像我們的高考一樣，它的本質目的并不是為了培養人才，而是為了區分人才，通過一個非常簡單的標準也就是分數把人區分開。性能的道理也是一樣的，它非容易測量。當然，我自己不是非常認可這種區分的方法，對于產品的選擇，性能只是一個小的方面，就像你選擇一個車，不能只看跑得快不快，你一定還關注它的內飾、安全性等等因素。
性能如果是無限的，那么就可以充分解放業務的想象力。某證券的漲樂財富通的APP可以做到5秒自動刷新賬戶信息，要知道每秒有幾百萬客戶在線，這個在傳統的IOE架構下是不可想象的，有了數據庫一體機，就可以釋放業務的想象力。
那么Exadata的性能怎么樣呢？花開兩朵，各表一枝。
在OLTP方面，相對于國產的數據庫一體機品牌，Exadata并沒有優勢。主要都是通過利用SSD，以及高效的存儲層協議來最大程度提高IOPS，降低IO延遲，畢竟對于OLTP系統延遲是關鍵。對于IOPS來說，IOPS的值越大，越能保證并發量。這里還需要提一下serversan，傳統的集中式存儲，機頭控制器還有存儲的前端口很容易成為性能瓶頸，但是一體機都是使用的serversan，相當于每一個serversan的節點都是一個個可以單獨提供動力的節點，保證了IOPS和帶寬的可擴展性。可以把集中式存儲想象成綠皮火車，火車跑得快全靠車頭帶，而serversan是動車，每個動車組都單獨提供動力。
可能有Exadata的技術極客會提到Exadata的RDS協議，這個協議是用來集群間傳遞數據塊的，那什么時候需要傳遞數據塊？在多個節點都需要修改這個塊時。所以如果去設定一些極端場景，例如多個集群節點對少量的熱點數據頻繁做更新，那么數據塊需要不斷的在集群間傳遞，這種極端場景下，RDS協議可能會比IPoIB協議會有優勢，例如用HammerDB或者Swingbench這種壓測工具去做性能測試把壓力開到最大（CPU跑滿），兩者可能會有5%左右的差異。RDS并不是銀彈，錦上添花而已。
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中的臟數據刷到磁盤，等待刷盤的過程中，查詢會被阻塞，直到刷盤完成，一旦這種讀取操作比較多，就會有大量的查詢被阻塞。
以上說了啟用卸載，這個超級殺手锏的功能，所要滿足的前置條件，都很難滿足！
此外，你的應用需要做大量的測試驗證，中間DBA需要高度配合，而且這個DBA得是個高級專家，review每一個SQL，看是不是要加hint，還是刪索引，這是巨大的工作量，是個系統工程，需要多個角色的配合才能完成，如果為了省事，把所有的索引都刪掉，那么你的系統離崩潰也不遠了，因為OLTP類型的SQL一定還是通過buffer cache這種內存讀的方式查詢的快。
卸載功能，在OLTP場景下，根本無法發揮作用。
即使退一萬步，你覺得自己團隊有大量的Oracle頂級專家，這些工作你都認，認為還是要上，就完了嗎？
并沒有，到了某一天，你接受了天啟，感覺到Exadata并沒有想象那么好，想換掉它，悲劇又會重演，因為，你還需要把當初review過的所有的SQL重新review一遍，哪些加過的hint可能要去掉，或者把當初刪掉的索引再加回來，這又是一個極為漫長痛苦的過程。這個過程，我親身經歷過，而且現在還正在經歷（某銀行客戶）。
我非常認可一句話,
“人類技術的發展有一個很重要的概念，不斷地讓一個難被駕馭的技術，越來越容易地被普通人操縱。”
就像美圖秀秀戰勝PS，一個技術能被越多的人駕馭，價值也才越大，從這一點上來說，Exadata在鉆牛角尖了，客戶去落地使用這個產品是非常困難的。技術本身可以很復雜，但是對客戶的界面要足夠的簡單。
Exadata有一個EHCC的壓縮功能，這也是他的第二大殺手锏功能。畢竟Exadata這個產品主要是面向數據倉庫系統的，壓縮功能被提到這樣的地位并不為過。
不過這里我負責任的告訴大家，該功能只能在Exadata上使用，意味著你的容災也得用Exadata來搭建，不能使用通用平臺來做Exadata的容災，這是巨大的成本啊，相信就是銀行，面對這樣的成本，也得思量思量吧？
如果你選擇了用通用平臺來搭建Exadata的容災，使用EHCC壓縮過的數據將不能被訪問，除非使用特定的辦法花大量的時間去做解壓才行。此外，壓縮還會讓數據的備份和遷移同樣變得頭痛萬分。再有，數據的壓縮本身就如硬幣的兩面，節省了空間，消耗了CPU資源，更為重要的是，對于Exadata來說，壓縮是必須在計算節點完成的，不能卸載到存儲節點，如果要壓縮的數據量比較大，那就得思考一下，畢竟客戶是要為計算節點的CPU付大量的license費用的。
這里提一下，我接觸到的很多客戶其實是把壓縮功能關閉掉的，做這樣的犧牲，就是為了能夠使用通用平臺來搭建容災，不過可惜的是客戶是為了這個功能支付了大量的費用的。
以上介紹了這么多都說明了Exadata是一個封閉的系統，上了這個船，你就得一直在船上，這個船可不是諾亞方舟。 它讓用戶產生了巨大的沉沒成本，被沉沒成本綁架后，用戶只能老老實實呆在船上。很多人只是買了一張40塊的電影票，看到爛片，也得堅持把片看完，更別說是一個幾百萬上千萬的設備。
從市面上很難招聘到一個懂Exadata的DBA，而Exadata要想用的好，恰恰需要一個非常懂行的人。如果用戶的DBA技能不達標，那就只能“無為而治”了，我經常參加一些oracle圈子里的活動，接觸到的很多第三方數據庫服務公司的專家都說，對于Exadata，絕大多數客戶也都是“無為而治“的。可是，客戶為了那些殺手锏的功能是支付了幾百上千萬的費用的。就像買了一個汗血寶馬，結果沒人能夠騎，騎的門檻很高。
給大家糾正一下：不要覺得買了Oracle Exadata就理所當然的包括了Oracle數據庫的license，Oracle Exadata是個Oracle數據庫的硬件運行平臺，它本身不包括Oracle License，各位買過Exadata的可以看一下，是否Exadata的軟件清單里包括了Oracle 的數據庫許可，客戶需要重新購買。
我們都知道計算機硬件基本上按照摩爾定律在發展，Exadata 自從2008年推出至今，在近10年的時間里，核心網絡一直初心未改運行在40Gb的IB上的，而國內的一體機早都有100Gb以上的產品了，帶寬的效率提高了3倍。可能有人要說，它有卸載功能，40Gb 夠用了，不需要提升帶寬，但是前提是要有專家DBA對SQL做精細化的調優，這將帶來巨大的系統管理成本，數據庫系統也越來越復雜。大家為什么不接受簡單高效的方式，升級到100Gb-200Gb的網絡呢？
我想最大的可能是因為，如果它升級了網絡，它存在的合法性就不存在了。Exadata最大的賣點就是通過卸載功能來最大化提升自己的價值，如果通過提升硬件來達到提升性能的目的，它豈不是沒有面子？這從一定程度上來說，還是以“產品為王”的思路來做產品，而不是以用戶的需求和痛點來做產品。國產的一體機品牌在這個方面更愿意采用更簡單、對DBA和業務更透明的的方式來釋放數據庫的性能。
第七點就不詳寫了，誰用誰知道，好像沒遇到過對Exadata 維保、擴容滿意的用戶，可能是高額利潤賺習慣了吧，沒辦法說！另外維保、擴容，升級都極其復雜，服務響應也非常地不及時。其余內容，大家自行腦補就好。
說說Exadata的未來，我有點咸吃蘿卜淡操心了，我曾經發朋友圈說既然Exadata這么復雜，如果可以結合人工智能，深度學習技術，那么它的前景還是非常不錯的，但是最近又反思了這個問題，可能答案并沒有這么簡單。（事實上，oracle公司從18C起已經開始搞自治數據庫了）
就像上面提到的， Exadata有一個非常大的問題，是不容易使用，感覺上就像是一堆熱愛技術的極客搞了一個使用門檻很高的產品 ，如何才能降低它的使用門檻呢？我以前認為的答案是，借助于深度學習的人工智能技術，讓Exadata的通過自治來達到降低使用門檻的目的。
但是我這個想法現在想想不太接地氣。大多數客戶選擇使用Exadata，會把比較重要的業務放上面，只要是重要的業務系統，都有一個顯性的需求，“我要穩穩的幸福”，一定不希望，今天自治系統決定加個索引，明天又決定刪個索引，這會帶來不確定性，而核心系統最需要的屬性就是確定性。
你可能會認為我是一個技術悲觀派，但是我要說明的是，我非常看好人工智能在數據庫領域的價值的，但是它的最大的應用場景是在非核心的數據庫場景上，這些數據庫，不需要DBA操心，哪怕慢，慢就慢點，只要省事就好了，這些非重要的業務系統對于企業來說數量上也是非常多的，因此自治數據庫是非常有前景的，但是核心數據庫還有得搞，路還很長。等自治數據庫也可以提供確定性了才能去考慮。
免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
