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

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

在做網(wǎng)站、成都網(wǎng)站建設(shè)過程中，需要針對客戶的行業(yè)特點(diǎn)、產(chǎn)品特性、目標(biāo)受眾和市場情況進(jìn)行定位分析，以確定網(wǎng)站的風(fēng)格、色彩、版式、交互等方面的設(shè)計(jì)方向。創(chuàng)新互聯(lián)建站還需要根據(jù)客戶的需求進(jìn)行功能模塊的開發(fā)和設(shè)計(jì)，包括內(nèi)容管理、前臺展示、用戶權(quán)限管理、數(shù)據(jù)統(tǒng)計(jì)和安全保護(hù)等功能。

什么是Exadata？它跟國內(nèi)的一些oracle數(shù)據(jù)庫一體機(jī)品牌一樣，是一套專為Oracle數(shù)據(jù)庫打造的軟硬一體化的數(shù)據(jù)庫平臺，俗稱“數(shù)據(jù)庫一體機(jī)”，你可以簡單理解成，它們是一個平臺，只要把Oracle數(shù)據(jù)庫跑在這個平臺上面，就可以跑的又快又穩(wěn)又安全。

接下我來跟大家聊下Exadata的七宗罪，用“罪”這個詞當(dāng)然是夸張的，主要的目的還是讓大家了解到Exadata那些可能還不為人知的一些缺陷，有些缺陷甚至是巨大的，甚至?xí)屇愀杏XExadata的這些專有技術(shù)非常的雞肋。 如果Oracle公司可以看到這篇文章，能夠?qū)Ξa(chǎn)品加以改進(jìn)，那為寫這篇文章花費(fèi)的數(shù)個小時也就不白費(fèi)了。

性能，吾將上下而求索

說“罪”之前，先說說性能的事，因?yàn)樾阅芎苤匾?/p>

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

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

造成這一局面，很大程度來自于Oracle收服了大量的技術(shù)人員的心，這些人對Exadata的專有技術(shù)津津樂道。至于這些技術(shù)是不是容易應(yīng)用，以及應(yīng)用的條件，技術(shù)人員很多時候是不關(guān)心的，如果不經(jīng)過訓(xùn)練，他們很多時候缺乏產(chǎn)品思維。

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

數(shù)據(jù)庫領(lǐng)域也一直被一個問題困擾著，那就是性能。特別是，互聯(lián)網(wǎng)來了，性能的問題更是捉襟見肘。

很多老人的記憶里都有著吃不飽的經(jīng)歷，一旦浪費(fèi)一些糧食，會遭遇巨大的心理譴責(zé)，不過根據(jù)我的觀察，如果他們浪費(fèi)了一些衣服（買了幾乎不穿）這種譴責(zé)會非常少。其實(shí)不管是衣服和糧食，都是人類勞動的產(chǎn)物，本質(zhì)沒有任何區(qū)別，都不應(yīng)該浪費(fèi)。

性能猶如糧食，在數(shù)據(jù)庫的歷史上，一直就不夠用，當(dāng)年在阿里從事應(yīng)用DBA的那會兒，數(shù)據(jù)庫都是要精細(xì)化調(diào)優(yōu)的。到了現(xiàn)在，借助于技術(shù)進(jìn)步，各種高性能的架構(gòu)其實(shí)已經(jīng)讓性能不成為問題了，但是，還是會發(fā)現(xiàn)，這種擔(dān)心性能不夠的心理還在影響著非常多的人。

此外，用戶特別在意性能還有其他的一些原因，也一并列在這里：

• 性能指標(biāo)好量化。性能作為一個好度量的指標(biāo)，用戶容易把各個供應(yīng)商的產(chǎn)品區(qū)分開。就像我們的高考一樣，它的本質(zhì)目的并不是為了培養(yǎng)人才，而是為了區(qū)分人才，通過一個非常簡單的標(biāo)準(zhǔn)也就是分?jǐn)?shù)把人區(qū)分開。性能的道理也是一樣的，它非容易測量。當(dāng)然，我自己不是非常認(rèn)可這種區(qū)分的方法，對于產(chǎn)品的選擇，性能只是一個小的方面，就像你選擇一個車，不能只看跑得快不快，你一定還關(guān)注它的內(nèi)飾、安全性等等因素。

• 性能如果是無限的，那么就可以充分解放業(yè)務(wù)的想象力。某證券的漲樂財(cái)富通的APP可以做到5秒自動刷新賬戶信息，要知道每秒有幾百萬客戶在線，這個在傳統(tǒng)的IOE架構(gòu)下是不可想象的，有了數(shù)據(jù)庫一體機(jī)，就可以釋放業(yè)務(wù)的想象力。

Exadata第一罪，第一殺手锏功能無法在真實(shí)環(huán)境中落地

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

OLTP，殺手锏毫無用處

在OLTP方面，相對于國產(chǎn)的數(shù)據(jù)庫一體機(jī)品牌，Exadata并沒有優(yōu)勢。主要都是通過利用SSD，以及高效的存儲層協(xié)議來最大程度提高IOPS，降低IO延遲，畢竟對于OLTP系統(tǒng)延遲是關(guān)鍵。對于IOPS來說，IOPS的值越大，越能保證并發(fā)量。這里還需要提一下serversan，傳統(tǒng)的集中式存儲，機(jī)頭控制器還有存儲的前端口很容易成為性能瓶頸，但是一體機(jī)都是使用的serversan，相當(dāng)于每一個serversan的節(jié)點(diǎn)都是一個個可以單獨(dú)提供動力的節(jié)點(diǎn)，保證了IOPS和帶寬的可擴(kuò)展性?？梢园鸭惺酱鎯ο胂蟪删G皮火車，火車跑得快全靠車頭帶，而serversan是動車，每個動車組都單獨(dú)提供動力。

可能有Exadata的技術(shù)極客會提到Exadata的RDS協(xié)議，這個協(xié)議是用來集群間傳遞數(shù)據(jù)塊的，那什么時候需要傳遞數(shù)據(jù)塊？在多個節(jié)點(diǎn)都需要修改這個塊時。所以如果去設(shè)定一些極端場景，例如多個集群節(jié)點(diǎn)對少量的熱點(diǎn)數(shù)據(jù)頻繁做更新，那么數(shù)據(jù)塊需要不斷的在集群間傳遞，這種極端場景下，RDS協(xié)議可能會比IPoIB協(xié)議會有優(yōu)勢，例如用HammerDB或者Swingbench這種壓測工具去做性能測試把壓力開到最大（CPU跑滿），兩者可能會有5%左右的差異。RDS并不是銀彈，錦上添花而已。

OLAP，鏡中花，水中月

• OLAP方面呢？要知道Exadata本來就是為數(shù)據(jù)倉庫開發(fā)的。它的殺手武器就是它的存儲卸載。存儲卸載做到了 1）可以把大量的操作offload到存儲層完成，節(jié)省計(jì)算節(jié)點(diǎn)的資源 2）第二點(diǎn)也是最重要的一點(diǎn)，可以快速的過濾掉那些不需要掃描的數(shù)據(jù)，這樣不但提高了掃描的效率，還變相的提高了存儲到計(jì)算的帶寬。也就是說，Exadata不用在物理設(shè)備上做文章，例如把互聯(lián)層從40GB升級到100GB，通過卸載功能，它就能達(dá)到56GB甚至100GB的效果，甚至更高。因此，理論上它比國產(chǎn)的一體機(jī)品牌在OLAP方面要強(qiáng)。

真強(qiáng)嗎？讓我這個圈子里的人爆一點(diǎn)料給你聽一聽。

先思考一個問題，這個殺手锏也就是卸載功能什么時候能夠被用到？

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

索引的痛

要啟用卸載或者說smart scan，第一個限制的條件是，SQL語句的執(zhí)行計(jì)劃必須是全表掃描（全索引掃描也可以認(rèn)為是全表掃描）。

smart scan是卸載的一個類型，用于SQL語句，卸載還可以對數(shù)據(jù)庫文件的快速創(chuàng)建，RMAN增量備份等有效果，不過這篇文章并不是做技術(shù)的深入探討，簡單的把卸載和smart scan做了等同。

也就是，如果你的系統(tǒng)是OLTP類的訪問，這個殺手級特性對你是毫無作用的，因?yàn)镺LTP的特點(diǎn)是查詢短小精干，要走索引。卸載功能只能用于偏分析類的系統(tǒng)（例如OLAP），但是請注意，重點(diǎn)來了，在這種分析型場景下，表上不能有相關(guān)的索引，否則，按照Oracle的CBO算法有極大可能執(zhí)行計(jì)劃不能滿足走全表掃描這個前提。

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

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

至此死循環(huán)產(chǎn)生了。索引是刪還是不刪，我遭遇過的大多數(shù)客戶，都選擇了不刪。就讓卸載功能歲月靜好在那美美的呆著，無為而治，更為痛心的是，客戶買的Exadata有1/3的錢都是為了這個功能付費(fèi)，接觸的某證券客戶，經(jīng)過統(tǒng)計(jì)，只有不到1%的SQL可以用到卸載功能，其他99%的沒有特意經(jīng)過優(yōu)化的SQL都走了索引掃描。

必須打開direct path read讀取方式

能用上卸載的第二個條件是，查詢必須要走direct path read方式，也就是讀取的數(shù)據(jù)不經(jīng)過buffer cache，直接放入到數(shù)據(jù)讀取進(jìn)程自己的私有內(nèi)存（PGA）中，現(xiàn)實(shí)的情況是，不少用戶把這個直接路徑讀是關(guān)閉掉的，因?yàn)檫@些全表掃描的SQL導(dǎo)致了過多的物理IO。

所以這對客戶來說又是一個巨大的挑戰(zhàn)。

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

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

以上說了啟用卸載，這個超級殺手锏的功能，所要滿足的前置條件，都很難滿足！

此外，你的應(yīng)用需要做大量的測試驗(yàn)證，中間DBA需要高度配合，而且這個DBA得是個高級專家，review每一個SQL，看是不是要加hint，還是刪索引，這是巨大的工作量，是個系統(tǒng)工程，需要多個角色的配合才能完成，如果為了省事，把所有的索引都刪掉，那么你的系統(tǒng)離崩潰也不遠(yuǎn)了，因?yàn)镺LTP類型的SQL一定還是通過buffer cache這種內(nèi)存讀的方式查詢的快。

卸載功能，在OLTP場景下，根本無法發(fā)揮作用。

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

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

我非常認(rèn)可一句話,

“人類技術(shù)的發(fā)展有一個很重要的概念，不斷地讓一個難被駕馭的技術(shù)，越來越容易地被普通人操縱?！?/p>

就像美圖秀秀戰(zhàn)勝PS，一個技術(shù)能被越多的人駕馭，價值也才越大，從這一點(diǎn)上來說，Exadata在鉆牛角尖了，客戶去落地使用這個產(chǎn)品是非常困難的。技術(shù)本身可以很復(fù)雜，但是對客戶的界面要足夠的簡單。

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

Exadata有一個EHCC的壓縮功能，這也是他的第二大殺手锏功能。畢竟Exadata這個產(chǎn)品主要是面向數(shù)據(jù)倉庫系統(tǒng)的，壓縮功能被提到這樣的地位并不為過。

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

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

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

以上介紹了這么多都說明了Exadata是一個封閉的系統(tǒng)，上了這個船，你就得一直在船上，這個船可不是諾亞方舟。 它讓用戶產(chǎn)生了巨大的沉沒成本，被沉沒成本綁架后，用戶只能老老實(shí)實(shí)呆在船上。很多人只是買了一張40塊的電影票，看到爛片，也得堅(jiān)持把片看完，更別說是一個幾百萬上千萬的設(shè)備。

Exadata第四罪，技術(shù)門檻太高

從市面上很難招聘到一個懂Exadata的DBA，而Exadata要想用的好，恰恰需要一個非常懂行的人。如果用戶的DBA技能不達(dá)標(biāo)，那就只能“無為而治”了，我經(jīng)常參加一些oracle圈子里的活動，接觸到的很多第三方數(shù)據(jù)庫服務(wù)公司的專家都說，對于Exadata，絕大多數(shù)客戶也都是“無為而治“的?？墒?，客戶為了那些殺手锏的功能是支付了幾百上千萬的費(fèi)用的。就像買了一個汗血寶馬，結(jié)果沒人能夠騎，騎的門檻很高。

Exadata第五罪，Exadata并不包含license

給大家糾正一下：不要覺得買了Oracle Exadata就理所當(dāng)然的包括了Oracle數(shù)據(jù)庫的license，Oracle Exadata是個Oracle數(shù)據(jù)庫的硬件運(yùn)行平臺，它本身不包括Oracle License，各位買過Exadata的可以看一下，是否Exadata的軟件清單里包括了Oracle 的數(shù)據(jù)庫許可，客戶需要重新購買。

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

我們都知道計(jì)算機(jī)硬件基本上按照摩爾定律在發(fā)展，Exadata 自從2008年推出至今，在近10年的時間里，核心網(wǎng)絡(luò)一直初心未改運(yùn)行在40Gb的IB上的，而國內(nèi)的一體機(jī)早都有100Gb以上的產(chǎn)品了，帶寬的效率提高了3倍?？赡苡腥艘f，它有卸載功能，40Gb 夠用了，不需要提升帶寬，但是前提是要有專家DBA對SQL做精細(xì)化的調(diào)優(yōu)，這將帶來巨大的系統(tǒng)管理成本，數(shù)據(jù)庫系統(tǒng)也越來越復(fù)雜。大家為什么不接受簡單高效的方式，升級到100Gb-200Gb的網(wǎng)絡(luò)呢？

我想最大的可能是因?yàn)?，如果它升級了網(wǎng)絡(luò)，它存在的合法性就不存在了。Exadata最大的賣點(diǎn)就是通過卸載功能來最大化提升自己的價值，如果通過提升硬件來達(dá)到提升性能的目的，它豈不是沒有面子？這從一定程度上來說，還是以“產(chǎn)品為王”的思路來做產(chǎn)品，而不是以用戶的需求和痛點(diǎn)來做產(chǎn)品。國產(chǎn)的一體機(jī)品牌在這個方面更愿意采用更簡單、對DBA和業(yè)務(wù)更透明的的方式來釋放數(shù)據(jù)庫的性能。

Exadata第七罪，維保 & 擴(kuò)容 & 服務(wù)

第七點(diǎn)就不詳寫了，誰用誰知道，好像沒遇到過對Exadata 維保、擴(kuò)容滿意的用戶，可能是高額利潤賺習(xí)慣了吧，沒辦法說！另外維保、擴(kuò)容，升級都極其復(fù)雜，服務(wù)響應(yīng)也非常地不及時。其余內(nèi)容，大家自行腦補(bǔ)就好。

Exadata的未來

說說Exadata的未來，我有點(diǎn)咸吃蘿卜淡操心了，我曾經(jīng)發(fā)朋友圈說既然Exadata這么復(fù)雜，如果可以結(jié)合人工智能，深度學(xué)習(xí)技術(shù)，那么它的前景還是非常不錯的，但是最近又反思了這個問題，可能答案并沒有這么簡單。（事實(shí)上，oracle公司從18C起已經(jīng)開始搞自治數(shù)據(jù)庫了）

就像上面提到的， Exadata有一個非常大的問題，是不容易使用，感覺上就像是一堆熱愛技術(shù)的極客搞了一個使用門檻很高的產(chǎn)品 ，如何才能降低它的使用門檻呢？我以前認(rèn)為的答案是，借助于深度學(xué)習(xí)的人工智能技術(shù)，讓Exadata的通過自治來達(dá)到降低使用門檻的目的。

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

你可能會認(rèn)為我是一個技術(shù)悲觀派，但是我要說明的是，我非常看好人工智能在數(shù)據(jù)庫領(lǐng)域的價值的，但是它的最大的應(yīng)用場景是在非核心的數(shù)據(jù)庫場景上，這些數(shù)據(jù)庫，不需要DBA操心，哪怕慢，慢就慢點(diǎn)，只要省事就好了，這些非重要的業(yè)務(wù)系統(tǒng)對于企業(yè)來說數(shù)量上也是非常多的，因此自治數(shù)據(jù)庫是非常有前景的，但是核心數(shù)據(jù)庫還有得搞，路還很長。等自治數(shù)據(jù)庫也可以提供確定性了才能去考慮。

當(dāng)前標(biāo)題：性能神化，聊聊Exadata的“七宗罪”
網(wǎng)站路徑：http://m.jiaotiyi.com/article/jgjspd.html