Exadata的獨門武器–卸載（Offloading）

Exadata的獨門武器--卸載（Offloading）

卸載（Offloading）是Exadata的獨門武器，正是它讓Exadata不同於其他任何一種運行Oracle的平台。卸載指的是將處理能力從資料庫伺服器轉移到儲存層，它也正是Exadata平台提供的主要賣點，它不僅僅轉移了CPU的使用，更主要的好處是減少了那些必須要返回給資料庫伺服器的資料量，而這正是大多數大型資料庫的主要瓶頸所在。

卸載這個詞在某些方面可以跟智能掃描（Smart Scan）互連，我們認為卸載是更好的描述方式，因為它指出了一部分傳統上由資料庫處理的SQL流程現在可以從資料庫層面“卸載（offloaded）”到儲存層面。這是一個更普適的措辭，它可以被用在那些甚至與SQL處理並無關係的最佳化上，比如用於提高備份和恢複操作的效率。

而另一方面，智能掃描，是一個更狹義的詞彙，僅僅是指Exadata對SQL語句的最佳化方式，當進行掃描操作（通常是全表掃描）的時候，這些最佳化就會起作用。對於智能掃描更明確的定義也體現在Oracle核心代碼中對於智能掃描相關等待事件的命名上，實際上有兩個等待事件在名稱中包含了“Smart
Scan”字樣，即“Cell Smart Table Scan”和“Cell Smart Index Scan”。我們將在後續的第10章裡更詳細地探討這兩個等待事件。好吧，我承認“智能掃描”這個詞確實帶有一些市場推廣的成分，但是在代碼上也確實有等待事件以此命名。無論如何，雖然這兩個詞在某些程度上可以互連，但是請記住“卸載”指的可不僅僅是加速SQL語句的執行。

本章我們將主要講述“智能掃描”這種最佳化方式。我們會提到跟智能掃描相關的多種最佳化手段，它們是如何工作的，以及如果想使用智能掃描，那麼有哪些前提條件必須滿足。我們也會講述一些技術，用以協助你確認對於給定的SQL語句，智能掃描有否被使用到。至於在本書別的章節會提到的其他卸載最佳化，本章僅僅會做簡要描述。

為何卸載如此重要

我們無法更加強調這個概念是何等重要，將資料庫的處理能力轉移到儲存層這樣的理念絕對是一個巨大的飛躍。這種概念已經存在了一段時間，實際上在幾年前就有傳言說Oracle帶著這種想法跟至少一家最大的SAN製造廠商進行過密談。顯然那時候儲存製造商對此想法並沒有興趣，於是Oracle決定靠一己之力來推進這個理念。隨後Oracle與惠普（HP）合作推出了最開始的Exadata
V1，整合了卸載的概念。沒過幾年，Oracle就出手收購了太陽微系統公司（Sun Microsystems），這使得Oracle一舉成為可以全面提供軟硬體整合解決方案的公司，這也讓Oracle可以完全控制到底想將哪些功能整合到產品裡去。

卸載的重要性在於，當前大型資料庫中一大主要瓶頸就是在磁碟系統和資料庫伺服器之間傳輸必要的能夠滿足資料倉儲類型的查詢所消耗的大量時間（因為頻寬所限）。這一方面是硬體架構的問題，但是更大的問題在於傳統Oracle資料庫所傳輸的大量資料。Oracle資料庫處理資料非常快也非常聰明，但是對於那些要讀取大量資料的查詢，將這些資料取到資料庫來仍然會消耗很長時間。所以就跟任何優秀的效能調整專家一樣，Oracle開始致力於減少最消耗時間的那些操作所花的時間。在分析中他們意識到每個需要磁碟讀的查詢會因為有大量資料要返回並由資料庫伺服器來處理而顯得特別低效。Oracle研發了最好的緩衝管理機制，但是對於那些確實龐大的資料集，將所有資料都保留在資料庫伺服器的記憶體中實在是不切實際的。

 Kevin說：作者們很好地解讀了Oracle查詢處理的發展曆程。不過我還是想提醒各位，當今商用的x64伺服器已經不再在架構上限制記憶體配置了。比如基於具有QuickPath互聯功能的Intel
Xeon 7500處理器的伺服器就支援在多DIMM插槽上的大量記憶體通道，商用伺服器具有數TB記憶體已然非常普遍。實際上，X2-8 Exadata就支援在資料庫網格上擁有2TB記憶體，並且此能力隨著時間推移必然會不斷增強。走向極大記憶體的x64系統的潮流方興未艾，我期待本書能保留足夠長的時間，當以後的讀者回過頭來再看時會發現此註解所言不假。關於Exadata需要記住的重要一點是，它擁有Oracle資料庫的所有功能並且附加了Exadata儲存伺服器，比如在某些場合，為了滿足服務水平，正確的解決方案是盡量完全排除磁碟介質的低效能，客戶就可以選擇將深度壓縮（比如Exadata混合列式壓縮）和記憶體間並行查詢（In-Memory
Parallel Query）一起使用。

想像一下你所能想到的最快查詢：單張表中一條記錄中的一列，並且你還知道這條記錄儲存在哪裡（通過rowid）。在傳統Oracle資料庫中，為了擷取這列的值最少也要有一個資料區塊被讀入記憶體（通常是8K大小），讓我們假設該表每個資料區塊中平均儲存著50條記錄，那麼很簡單，你傳輸了額外的49行到資料庫伺服器中，對於此查詢來說這就是無謂的開銷。如果有一億次呢？你應該開始意識到在大型資料倉儲中這個問題的嚴重性了。消減在儲存和資料庫伺服器之間傳遞完全不需要的資料所花費的時間，正是Exadata想要解決的主要問題。

卸載就是用來解決這樣的問題——在各層之間傳輸無關資料而花費過多時間。卸載有三個設計目標，不過主要目標的重要性遠超其他兩個。

     減少磁碟系統和資料庫伺服器之間的傳輸資料量。

     減少資料庫伺服器上的CPU佔用。

     減少儲存層磁碟讀取時間。

減少資料量是主要訴求和主要目標。卸載操作帶來的大多數最佳化手段都是為了實現該目標。減少CPU佔用同樣很重要，但這不是Exadata所帶來的主要好處，因此只好位居於減少傳輸資料量之後了（不過你們將會看到，解壓是一個例外，因為解壓操作會發生在儲存伺服器上）。另外還有幾個降低磁碟讀取時間的最佳化措施，不過，即使其中一些結果也頗引人注目，我們仍然不認為這一項目標是Exadata的最根本訴求。

Exadata是一個軟硬體一體的產品，依靠這兩方面組件，提供了令人矚目的超越非Exadata平台的效能提升，不過，相比而言，軟體方面帶來的效能提升讓硬體帶來的好處相形見絀。下面是一個例子：

SYS@SANDBOX> alter session setcell_offload_processing=false;

 

Session altered.

 

Elapsed: 00:00:00.06

SYS@SANDBOX> select count(*) fromkso.skew3 where col1 < 0;

 

 COUNT(*)

----------

        2

1 row selected.

 

Elapsed: 00:00:51.09

SYS@SANDBOX> alter session setcell_offload_processing=true;

 

Session altered.

 

Elapsed: 00:00:00.07

SYS@SANDBOX> select count(*) fromkso.skew3 where col1 < 0;

 

 COUNT(*)

----------

        2

1 row selected.

 

Elapsed: 00:00:00.15

該樣本示範了在一個具有3.84億行記錄的單表上的掃描。我們第一次是在禁用了卸載以後啟動並執行，用到了Exadata所有硬體所能提供的好處但是沒有軟體的，你會發現即使是在Exadata硬體上，這條查詢也執行了將近1分鐘。注意這是僅僅分散到我們這台V2四分之一機櫃的三台儲存伺服器上並且也沒有使用任何快閃記憶體。然後我們重新啟用了卸載，查詢不到1秒鐘就完成了。很顯然在兩次執行中硬體都是一樣的，那麼無疑正是卸載操作這樣的軟體能力帶來了如此大的差別。

一個福士版的Exadata？

經常會看到關於搭建一個福士版Exadata的主題。該想法是搭建一套在某些方面模仿Exadata的硬體平台，想來也是為了能花費比Oracle對Exadata的收費要低的成本。當然這些建議都是在複製Exadata的硬體部分，因為軟體模組無法複製（僅僅是這點就應該讓你不用再問到底這種嘗試是否切實可行了）。不過，搭建自己的Exadata聽上去很有吸引力，因為購買單獨硬體模組的開銷會比Oracle提供的整合價格要低，但是這種想法有幾個缺點：

1．硬體模組中獲得最多關注的是快閃記憶體。你可以購買一個擁有很大緩衝的SAN或者NAS。中等尺寸的Exadata（1/2機架）在儲存伺服器上提供大約2.5TB的快閃記憶體，這確實是一個很大的數字，但是緩衝了什麼跟緩衝有多大同樣重要。Exadata足夠智能到不會去緩衝那些不大可能從緩衝中收益的資料，比如，緩衝鏡像塊就沒什麼用處，因為Oracle只會從主塊中讀取資料（除非發現主塊損壞）。Oracle在編寫管理緩衝的軟體上已經曆時彌久，所以不用驚訝它的卓越表現，當掃描一個大表的時候，Oracle不會緩衝所有的資料區塊，這樣，那些經常會被讀取的資料區塊也就還會留在記憶體中。如果沒有這種瞭解資料庫的緩衝演算法，普通的SAN或者NAS必須要配備大得多的緩衝才可以與Exadata的快閃記憶體一較高下。另外請記住，在非Exadata儲存上儲存的資料量也要大很多，因為你無法使用混合列式壓縮。

2．從硬體方面看更重要的，但是很奇怪卻又偶爾會被DIY建議所忽略的，是儲存和資料庫之間的資料輸送量。Exadata一體機在儲存和資料庫伺服器之間提供了比當今大多數硬體架構都要平衡的資料通道，所以第二個關注的領域通常是各層之間的頻寬，但是增加各層之間的資料輸送量卻並非像聽上去這麼簡單。Exadata通過InfiniBand和可靠資料通訊端（Reliable
Datagram Sockets，RDS）協議來增大輸送量，Oracle研發了運行在InfiniBand網路上的iDB協議，而iDB協議在運行於非Exadata硬體的資料庫中是停用，因此如果想要增加資料層之間的頻寬，則必須要採用其他的方法，所以你可以使用運行在萬兆網上的IPOB、iSCSI或者NFS，再或者使用高速的光纖串連方案，無論哪種方案在伺服器上都需要多塊介面卡（都需要串連到快速系統匯流排）。存放裝置還需要提供足夠的資料輸出量以適應通路的消費能力（這正是當Oracle提到平衡配置時所指的意思）。同時，你還需要決定採用什麼硬體，還要測試所有環節來確保它們能良好協作，不會在磁碟到資料庫伺服器之間有任何一處瓶頸產生。

3．第三點通常會被DIY方案提到的是資料庫伺服器自身。Exadata的硬體規格隨處都可以查到，所以去購買完全相同的Sun機器是很容易做到的。但是很不幸，你需要計劃購買更多的CPU，因為你無法將CPU的處理能力卸載到Exadata儲存伺服器上，而隨之就會帶來Oracle資料庫許可證費用的增加。

4．假設我們可以做到在硬體的每個部分都和Exadata硬體效能相當，我們還是無法期盼能夠獲得與Exadata相近的整體效能，因為軟體才是Exadata效能提升的點睛之筆，通過在Exadata中禁用卸載來做比較測試可以很容易地證明這點，我們會看到沒有了軟體助力的硬體效能到底怎樣。Exadata軟體做的事情很大一部分就是消除完全不必要的工作，比如把最終將被丟棄的列和行仍然傳輸到資料庫伺服器中。

就像我們的朋友Cary Millsap常喜歡說的那樣，“做一件事情最快的方法就是不要去做它“。

  

本文節選自《深入理解Oracle Exadata》一書

Kerry Osborne（凱裡•奧斯本）

Randy Johnson（蘭迪•約翰遜）

Tanel Põder（托內耳•蔔戴德）著

黃凱耀，張樂奕，張瑞譯

電子工業出版社出版

圖書詳細資料:http://blog.csdn.net/broadview2006/article/details/7844209