Oracle 12c In-Memory技術(shù)優(yōu)勢詳解

1、Oracles 12c In-Memory for SAP Applications技術(shù)優(yōu)勢詳解Oracle Database In-Memory產(chǎn)生的背景與功能介紹Oracle Database In-Memory優(yōu)勢與不足Oracle Exadata與Hana的比較SAP Application on HANA的整體優(yōu)勢總結(jié)今日話題近年來Oracle在各領(lǐng)域產(chǎn)品的發(fā)展歷程不斷嘗試，卻一直未找到數(shù)據(jù)分析領(lǐng)域的最佳解決方案2005年6月正式收購TimesTen，正式進入內(nèi)存計算領(lǐng)域Oracle收購Sun后于2008月正式發(fā)布第一款數(shù)據(jù)庫一體機Exadata，號稱能夠更好地支持混合型負載于201

2、2年發(fā)布Exalytics，專門針分析型應(yīng)用，由TimesTen、Essbase、BI工具等產(chǎn)品混裝的軟硬件一體機解決方案2014年6月Oracle 12C正式發(fā)布，12C中包含了Database In-Memory功能，該功能的發(fā)布標(biāo)志著Oracle進入行/列混合處理的領(lǐng)域2014年2012年2008年2005年不斷嘗試局限性依然采用傳統(tǒng)的行式處理引擎主要用作傳統(tǒng)數(shù)據(jù)庫的 Cache，并未有根本的技術(shù)轉(zhuǎn)變通過Smart Scan、存儲索引等方式減少了數(shù)據(jù)庫I/O針對交易處理系統(tǒng)性能提升較大，OLAP處理性能未能有重大突破SAP應(yīng)用對Exadata進行了認證，但不支持很多數(shù)據(jù)庫底層的調(diào)優(yōu)方式大

3、量既有軟件和硬件的打包產(chǎn)品TimesTen、Essbase等技術(shù)并未有新的突破多業(yè)務(wù)處理層反而增加了產(chǎn)品的復(fù)雜度，降低了效率沒有得到用戶的認可，實際用戶非常少實際效果如何-有待于市場進一步檢驗？2005年6月正式收購TimesTen，正式進入內(nèi)存計算領(lǐng)域Oracle收購Sun后于2008月正式發(fā)布第一款數(shù)據(jù)庫一體機Exadata，號稱能夠更好地支持混合型負載2012年發(fā)布Exalytics，專門針對分析型應(yīng)用，由TimesTen、Essbase、BI工具等產(chǎn)品混裝的軟硬件一體機解決方案2011年大量開源產(chǎn)品的組合，并未做到真正的集成僅對硬件進行了優(yōu)化設(shè)計架構(gòu)復(fù)雜，實施難度大，全球案例很少201

4、1年發(fā)布了Big Data Appliance是一款新的集成設(shè)計系統(tǒng)，其中包括開源Hadoop、Oracle NoSQL數(shù)據(jù)庫、Oracle數(shù)據(jù)集成Hadoop應(yīng)用適配器以及開源R面向 SAP 應(yīng)用的 Oracle 12c（內(nèi)存）Oracle 網(wǎng)站鏈接Oracle 發(fā)布了面向 SAP 應(yīng)用的 Oracle 12c（內(nèi)存）白皮書 短篇（12 頁），長篇（84 頁）背景：2015 年 7 月，Oracle 12c（內(nèi)存）通過了運行 SAP 應(yīng)用的認證，例如 SAP Business Suite、SAP BW 及行業(yè)解決方案新聞稿和 SAP 內(nèi)部回應(yīng)技術(shù)事實針對 SAP 應(yīng)用進行 Oracle 12

5、c 認證的階段 支持的 Oracle 12c 功能可為 SAP 應(yīng)用帶來價值從不同角度了解 Oracle In-Memory對SAP 應(yīng)用提供與SAP HANA 平臺類似的價值能夠輕松配合 SAP 應(yīng)用使用Oracle也發(fā)表了一篇關(guān)于12c Database In-Memory與SAP HANA對比的所謂優(yōu)勢上述觀點來自于 Oracle的官方途徑揭秘Oracle 12c Database In-Memory出現(xiàn)的技術(shù)背景推出新功能目標(biāo)：進一步優(yōu)化系統(tǒng)性能追趕主流技術(shù)的發(fā)展趨勢最大化利用可用的硬件資源補足短板、提升產(chǎn)品的競爭力Oracle 12c In-Memory 是什么？能夠用列式存儲方式緩

6、存數(shù)據(jù)庫表按需在SGA中自動創(chuàng)建內(nèi)存區(qū)域，基于表空間/表/分區(qū)等粒度緩存數(shù)據(jù)類似于HANA的列存儲格式，雙數(shù)據(jù)存儲格式當(dāng)數(shù)據(jù)庫關(guān)閉時釋放緩存數(shù)據(jù) 自動加速OLAP查詢優(yōu)化器會根據(jù)最優(yōu)的執(zhí)行計劃自動選擇行式或列式存儲 自動維護行和列式存儲的一致性（行/列數(shù)據(jù)轉(zhuǎn)換） 12c In-Memory功能能夠兼容現(xiàn)有的應(yīng)用支持數(shù)據(jù)壓縮 類似于Exadata的HCC壓縮方式 Oracle 12c Database In-Memory本質(zhì)上是一種內(nèi)存計算技術(shù)，它在內(nèi)存中開辟了一份空間，按照列的方式存儲一份數(shù)據(jù)副本。用戶可以從內(nèi)存中快速地訪問并對這些列式緩存數(shù)據(jù)進行計算，從而提升數(shù)據(jù)庫查詢和分析的性能。 Dat

7、abase In-Memory 在Oracle中以DB Option的方式提供（需要額外付費）。Oracle 12c In-Memory 的缺陷Database In-Memory In-Memory Database使用場景有一定的局限性不是內(nèi)存計算的專用引擎，延用了Oracle傳統(tǒng)的行式處理引擎需要管理員很多的維護/調(diào)優(yōu)操作性能與純內(nèi)存數(shù)據(jù)庫仍有一定差距Oracle 12c In-Memory 更多的技術(shù)壁壘數(shù)據(jù)還存在著多份重復(fù)的拷貝磁盤/內(nèi)存中的行格式存儲磁盤/內(nèi)存中的索引內(nèi)存中的列式存儲集群環(huán)境對硬件有一定要求若在Database In-Memory下啟用RAC硬件必須使用Exadat

8、a或SuperCluster 不支持集群表SAP應(yīng)用中一些關(guān)鍵場景使用，如BESG(總分類賬)部分數(shù)據(jù)庫高級功能仍然不支持如Active Data Guard不支持Long, Long Raw, LOBs，缺乏對大字段的文本分析支持DBA潛在著大量的工作6個壓縮設(shè)置、5種不同的加載方式需要管理員不斷地調(diào)整性能磁盤上僅持久化行式存儲的數(shù)據(jù)數(shù)據(jù)庫重啟后，列式存儲的內(nèi)存結(jié)構(gòu)需要重新構(gòu)建內(nèi)存重構(gòu)后，進一步的優(yōu)化會耗費大量時間很多場景下需要重新采購硬件很多舊機器內(nèi)存不足額外的性能開銷為了將數(shù)據(jù)同步至IMC，傳統(tǒng)數(shù)據(jù)在更新同時還要寫一份Transaction Journal在很多情況下，仍需要借助索引和聚

9、集加速為何選用Oracle 12c Database In-Memory(Oracle觀點)Oracle聲稱事實最佳的性能與可擴展性O(shè)racle擁有SAP SD和BI-DataMart的benchmark記錄Oracle RAC/Exadata等方案均具有較強的可擴展性HANA的純內(nèi)存數(shù)據(jù)架構(gòu)可以提供更高的處理性能。HANA的MPP架構(gòu)更利于水平擴展，而Oracle的Shared-disk架構(gòu)不利于部署大規(guī)模集群。Oracle提供的測試結(jié)果僅是基于特別應(yīng)用的內(nèi)存測試，不具有普示性。大量 SAP的測試證明 HANA是運行SAP應(yīng)用的最佳選擇最佳的開發(fā)靈活性O(shè)racle 12c Database

10、In-Memory基本不需要額外的開發(fā)工作 Oracle 12c Database In-Memory雖基本不需要額外開發(fā)，但會引入額外的管理成本。最高的可靠性與可用性O(shè)racle的MAA架構(gòu)能保證系統(tǒng)的最大可用性SAP HANA也具有很完善的高可用性架構(gòu)，諸如集群、基于System Replication和存儲復(fù)制的容災(zāi)、基于時間點的備份與恢復(fù)等。超大規(guī)模數(shù)據(jù)庫的最佳方案Oracle 12c的高級壓縮選件可以支持更大的數(shù)據(jù)容量實際上HANA也可以通過Scale-out架構(gòu)支持大規(guī)模數(shù)據(jù)管理，可以完全滿足SAP應(yīng)用數(shù)據(jù)集的需求。另外利用DT以及開源的Hadoop技術(shù)可以支持 PB級別的數(shù)據(jù)。最

11、佳的數(shù)據(jù)安全性O(shè)racle的透明數(shù)據(jù)加密和Database Vault可以提供額外的安全保護SAP HANA支持數(shù)據(jù)庫級別提供的主要安全功能，并且提供模型級別的安全控制自我維護與簡化管理OEM、SAP DBA Cookpit、AWR等輔助工具可以協(xié)助完成數(shù)據(jù)庫的管理工作盡管Oracle提供了一些輔助調(diào)優(yōu)工具，但性能調(diào)整方案仍需要人工介入。另外，Oracle 12c Database In-Memory的雙數(shù)據(jù)存儲格式也增加了數(shù)據(jù)庫的管理成本和復(fù)雜程度數(shù)據(jù)整合的最佳方案Exadata一體機以及MDC功能可以支持高度集成的數(shù)據(jù)環(huán)境實際上如果需要支持基于RAC的In-Memory Column st

12、ore硬件只能采用 Exadata或者 Oracle Supercluster從硬件軟件融合的最佳方案支持Oracle 12c Database In-Memory的Exadata是軟/硬件結(jié)合的最佳選擇SAP HANA沒有鎖定單一硬件品牌，而是通過認證合作硬件的方式，給用戶更靈活的選擇相關(guān)優(yōu)勢來自與Oracle for SAP Technical updateOracle 12c Database In-Memory與SAP HANA的簡單比較成熟度Oracle 12c的內(nèi)存數(shù)據(jù)庫完整的名稱是in-memory columnar & compression簡稱 IMCC或者叫 New Mem

13、ory DB。 2013年宣布，遲至2014年7月推出第一版，在國內(nèi)幾乎沒有成功案例。架構(gòu)先進性在架構(gòu)上IMCC僅僅是一個新的數(shù)據(jù)緩存區(qū)對于用戶只讀，雖然是常駐內(nèi)存并按列方式組織數(shù)據(jù)且經(jīng)過壓縮；本質(zhì)上數(shù)據(jù)庫架構(gòu)沒有改變。雙格式數(shù)據(jù)存儲帶來額外操作，包括內(nèi)存列數(shù)據(jù)的同步都會引入新的效能問題IMCC采用了很多新技術(shù)，給DBA甚至是Basis都帶來了大量的管理負擔(dān)對SAP應(yīng)用的支持情況標(biāo)準(zhǔn)的SAP應(yīng)用不會針對12c IMCC進行專門的優(yōu)化，在SAP應(yīng)用中IMCC的應(yīng)用場景和效能將會受到很大限制Oracle的底層平臺未來將被取代，SAP計劃在2025年以后不再支持Oracle數(shù)據(jù)庫成熟度SAP HAN

14、A是成熟的、經(jīng)過10000多家客戶使用驗證的產(chǎn)品。僅在中國就有上百家的SAP ERP和BW客戶選擇使用HANA SAP針對S/4、Suite on HANA、BWoH和B/4HANA有清晰的路線圖，HANA將做為SAP應(yīng)用的首選產(chǎn)品架構(gòu)先進性SAP HANA是從簡化IT架構(gòu)設(shè)計層面出發(fā)，同時集成了內(nèi)存計算、列式存儲、多分析引擎等核心技術(shù)，為下一代全新的內(nèi)存型應(yīng)用提供了一個內(nèi)存計算平臺。HANA本身是完整且獨立的實時數(shù)據(jù)處理平臺，不依賴于其他數(shù)據(jù)庫對SAP應(yīng)用的支持情況從2011年開始SAP BW就開始基于HANA進行優(yōu)化，從處理流程、系統(tǒng)架構(gòu)到性能都有了很大程度的優(yōu)化SoH基于HANA進行專向

15、優(yōu)化。針對HANA特點很多應(yīng)用層代碼都下沉至HANA上處理。執(zhí)行效率和產(chǎn)品功能都有了很大的改進。S/4 HANA更是基于HANA重新設(shè)計的新一代ERP，是SAP應(yīng)用的未來發(fā)展方向SAP HANA對比Oracle ExadataInfiniBand 請求DB ServersExadata Storage12 原因2“混合列壓縮(HCC)”： 自稱10 x50 x 壓縮比，并提高磁盤I/O效率 原因3“Smart Flash Cache”： 依靠Flash Cache，加速隨機I/O 原因1“Smart Scan”： 計算負載部分卸載至并行智能存儲層，并只傳輸經(jīng)篩選的有用數(shù)據(jù) 原因4“Infini

16、band”: 提供40Gb/s 端口帶寬，聚合帶寬高達880Gb/s , 端口延時(0.1um ）小于以太網(wǎng)的 1/1000EXADATA性能提升的原因 HANA才是SAP王道“Smart Scan”功能在SAP ERP或SAP BW中不起作用，并會增加系統(tǒng)的負載，SAP建議關(guān)閉此功能?！盎旌狭袎嚎s”功能在SAP環(huán)境中可能會導(dǎo)致數(shù)據(jù)更新和并發(fā)問題，Notes105047有說明，建議關(guān)閉?！爸悄荛W存技術(shù)”功能在SAP ERP或SAP BW環(huán)境中沒有作用，沒有額外加速效果，SAP建議關(guān)閉?！癐nfinband”與“萬兆以太網(wǎng)”是網(wǎng)絡(luò)技術(shù)的爭論，HANA采用10Gb/s萬兆以太網(wǎng)技術(shù)互聯(lián)，標(biāo)配4口并

17、行，同樣可達到40Gb/s帶寬 。（某些廠商已采用Infiniband架構(gòu)）綜上所述，EXADATA在SAP應(yīng)用中存在諸多水土不服，很多技術(shù)被限制使用，不能發(fā)揮速度優(yōu)勢，只能當(dāng)成普通數(shù)據(jù)庫服務(wù)器來使用。Oracle Exadata對比SAP HANA的核心架構(gòu)缺陷一體機硬件采用Sun系列服務(wù)器+Intel CPU組合的方式，但是Sun系列服務(wù)器架構(gòu)較老，出貨量持續(xù)下滑，市場占有量很低。被Oracle收購后，架構(gòu)趨向封閉，幾乎只用作數(shù)據(jù)庫服務(wù)器收到美國斯諾登事件影響，美系產(chǎn)品數(shù)據(jù)安全性受到質(zhì)疑，目前國企央企以及國家核心機構(gòu)企業(yè)都謹慎選擇此類產(chǎn)品采購成本較高，硬件與軟件采取死綁定的策略不可分離與I

18、ntel深入合作，Intel為HANA優(yōu)化處理指令集，在硬件層級提升HANA性能合作伙伴眾多，SAP提供內(nèi)存計算標(biāo)準(zhǔn)，目前支持11家合作伙伴，多達4000多款設(shè)備可選主要支持聯(lián)想、華為等國內(nèi)合作伙伴，開放架構(gòu)接受國家及伙伴的信息監(jiān)管。以國內(nèi)自主硬件技術(shù)運行內(nèi)存計算，支持中國制造！軟、硬件松耦合，初始化投入成本低數(shù)據(jù)庫架構(gòu)Share Everything: 一般是針對單個主機，完全透明共享CPU/MEMORY/IO，并行處理能力是最差的Share Disk: 各個處理單元使用自己的私有 CPU和Memory，共享磁盤系統(tǒng)，典型的代表Oracle RAC， 它是數(shù)據(jù)共享式SMP（對稱多處理）Sha

19、re Nothing: 各個處理單元都有自己私有的CPU/內(nèi)存/硬盤等，不存在共享資源，類似于MPP（大規(guī)模并行處理）模式，各處理單元之間通過協(xié)議通信，并行處理和擴展能力最好Oracle采取Share Everything + Share Disk方式實現(xiàn)數(shù)據(jù)庫架構(gòu)，例如RAC環(huán)境。計算節(jié)點Share Everything，存儲節(jié)點Share Disk 優(yōu)勢：數(shù)據(jù)在每節(jié)點上冗余，很容易做到系統(tǒng)安全最大化，數(shù)據(jù)不容易丟失 劣勢：每個節(jié)點都要數(shù)據(jù)復(fù)制，所以實際處理的空間很小。OLTP系統(tǒng)帶來的內(nèi)部通訊開銷比較令人恐怖，因此RAC集群很少有超過3個節(jié)點HANA采取Share Nothing + MP

20、P架構(gòu) 優(yōu)勢：物理表水平分割，每節(jié)點獨立處理和存儲具有獨立工作空間，服務(wù)器擴展是線性的，具有強大的并發(fā)能力和處理能力 劣勢：節(jié)點不能互相備份，集群中需要備用節(jié)點其它項對比：HANA與Exadata的比較 1/4對比項產(chǎn)品概覽產(chǎn)品成熟度與技術(shù)先進性架構(gòu)先進性硬件標(biāo)準(zhǔn)維護性SAP HANAHANA是成熟的、經(jīng)過全球10000多家客戶使用驗證的產(chǎn)品。HANA是實現(xiàn)OLTP與OLAP統(tǒng)一的內(nèi)存數(shù)據(jù)庫技術(shù)平臺。HANA屬于革新一代的數(shù)據(jù)庫技術(shù)、是第一個成功商用的通用型企業(yè)級內(nèi)存數(shù)據(jù)庫。PB級的大數(shù)據(jù)處理能力已經(jīng)得到驗證。同時不僅充分利用內(nèi)存數(shù)據(jù)庫的高速處理能力，還拓展了許多與數(shù)據(jù)庫緊密的功能應(yīng)用如預(yù)測性

21、分析等。查詢分析性能提升1000倍。采用Share Nothing架構(gòu)，突破共享存儲IO帶寬瓶頸，實現(xiàn)大規(guī)模并行處理。先HANA是從簡化IT架構(gòu)設(shè)計層面出發(fā)，為下一代全新的內(nèi)存型應(yīng)用提供了一個內(nèi)存計算平臺。HANA平臺具有數(shù)據(jù)庫和數(shù)據(jù)倉庫兩大功能；數(shù)據(jù)無需再通過聚合過程，HANA可以提供虛擬的多維度數(shù)據(jù)聚合，供商務(wù)智能和分析、以及大數(shù)據(jù)探查。HANA內(nèi)置R集成預(yù)測分析功能；空間地理數(shù)據(jù)支持；搜索；文本分析；圖像引擎；Hadoop智能訪問和IQ集成。開放內(nèi)存計算標(biāo)準(zhǔn)，全球有9家供應(yīng)商，3000多種配置可選。體積小，功能全，部署簡單，維護方便。不需要DBA進行數(shù)據(jù)庫調(diào)優(yōu)，不需要索引，不需要預(yù)先計算

22、。ExadataExadata基于oracle傳統(tǒng)數(shù)據(jù)庫技術(shù)，從硬件底層優(yōu)化了數(shù)據(jù)讀取技術(shù)，但是從根本技術(shù)上來講還是采用了傳統(tǒng)的磁盤數(shù)據(jù)庫技術(shù)。其在技術(shù)上落后于HANA為領(lǐng)導(dǎo)者的內(nèi)存計算技術(shù)。采用Share Everything架構(gòu)，存在存儲瓶頸。這必然制約企業(yè)關(guān)鍵業(yè)務(wù)的長期發(fā)展。基于傳統(tǒng)的磁盤技術(shù)，雖然后期也引入了內(nèi)存處理、壓縮及列存儲等技術(shù)，但是本質(zhì)上的數(shù)據(jù)架構(gòu)沒有改變，仍然沒有徹底解決從硬盤讀取的IO問題。數(shù)據(jù)聚合層面還需要通過借用數(shù)據(jù)倉庫技術(shù)來實現(xiàn)數(shù)據(jù)的多維度分析和存儲。一家綁定，沒有例外。傳統(tǒng)的DBA支持，并且維護人員需要強化知識來管理Exadata的日常運行。優(yōu)勢項弱勢項劣式項其它

23、項對比：HANA與Exadata的比較 2/4對比項技術(shù)先進性易用性數(shù)據(jù)加載行列存儲技術(shù)數(shù)據(jù)持久化可靠性SAP HANAHANA的技術(shù)架構(gòu)非常簡單清晰：行列表選擇邏輯很清楚，列式表數(shù)據(jù)及索引；DBA無需再不斷的查看查詢計劃，嘗試有效的索引。數(shù)據(jù)庫易用性極大提高，這也節(jié)約了人工成本。HANA列式表數(shù)據(jù)加載采用“Delta Merge”和列壓縮技術(shù)優(yōu)化加載性能。在大規(guī)模（PB以上級）數(shù)據(jù)加載時能充分發(fā)揮Share Nothing架構(gòu)優(yōu)勢，不受存儲IO瓶頸影響。HANA天然的就有行和列兩種存儲型式；對于OLTP操作、用行式存儲，對于OLAP型操作、用列式存儲。HANA列式表數(shù)據(jù)即索引技術(shù)使得HANA

24、無需再建索引，不僅節(jié)約的內(nèi)存還提升了性能。HANA是完全內(nèi)存數(shù)據(jù)庫，行、列表都做了數(shù)據(jù)持久化設(shè)計，以保證重啟或掉電數(shù)據(jù)不丟失；處理層與持久化層分開，交易、查詢事務(wù)與管理性事務(wù)分開，互不影響。完整的備份策略：全量備份、增量備份；HANA采用share nothing架構(gòu)，實現(xiàn)HA功能的完整設(shè)計；可以實現(xiàn)standby，HA，各個等級的高可用?；跀?shù)據(jù)庫的整體優(yōu)化，基于HANA技術(shù)整體提高性能和穩(wěn)定性，通過SLT工具在內(nèi)中直接進行數(shù)據(jù)加載，數(shù)據(jù)直接寫入HANA數(shù)據(jù)庫。Exadata內(nèi)存仍然以數(shù)據(jù)緩存的形式存在，直到內(nèi)存選項的出現(xiàn)改善了緩存方式，但是兩套數(shù)據(jù)（行式及列式）的同步，帶來數(shù)據(jù)管理成本和難

25、度的大幅增加；實際使用中，還需要用戶去抉擇哪些表需要用到內(nèi)存數(shù)據(jù)庫、何時開何時關(guān)閉表的緩存。行列訪問的決策都交給優(yōu)化器，在實際場景下對于復(fù)雜SQL，為了達到業(yè)務(wù)需要的性能，是需要經(jīng)過數(shù)據(jù)庫調(diào)優(yōu)的，原有的優(yōu)化經(jīng)驗此時不可用，這往往會極大增加DBA的工作量。數(shù)據(jù)從行式表加載到列式表，數(shù)據(jù)存在行、列兩份數(shù)據(jù)；事務(wù)修改的數(shù)據(jù)通過“transaction journal”（很奇怪的實現(xiàn)方式）來更新，同一份數(shù)據(jù)加載兩次，極大的浪費了CPU和內(nèi)存資源。Oracle本身是行式數(shù)據(jù)庫，只有打開選項以后才可以使用列式表。列式表何時用、用在什么表上全得由用戶自己決定，能達到什么效果也未知。持久化層即是處理層，所以在

26、執(zhí)行數(shù)據(jù)處理操作和數(shù)據(jù)管理操作時會有IO競爭，例如備份任務(wù)執(zhí)行時會極大影響正常數(shù)據(jù)操作。Oracle 原有的高可用、災(zāi)難備份/恢復(fù)機制。優(yōu)勢項弱勢項劣式項其它項對比：HANA與Exadata的比較 3/4對比項遷移實施環(huán)節(jié)及成本比較升級或替換數(shù)據(jù)庫復(fù)雜程度實現(xiàn)效果標(biāo)準(zhǔn)模塊加速SAP HANA實施HANA加速器場景，不需要中斷現(xiàn)有的任何業(yè)務(wù)系統(tǒng)，并且切換以后可以依據(jù)配置來選擇不同的數(shù)據(jù)源，很容易切回原有的系統(tǒng)。ERP中可以配置選擇外部數(shù)據(jù)源，很容易實現(xiàn)HANA加速器場景的切換和應(yīng)用。數(shù)據(jù)通過SLT工具一步到位，實時同步，對前端用戶沒有任何影響。同時，保留原來報表的輸入和輸出邏輯，未改變用戶使用習(xí)

27、慣。從架構(gòu)角度徹底解決IO瓶頸問題，整體提升100倍以上（原型驗證數(shù)據(jù)）支撐高并發(fā)的訪問，能滿足ERP集中實施過程中不斷增加的并發(fā)訪問需求。在不改變業(yè)務(wù)用戶操作習(xí)慣的情況下，響應(yīng)速度提升顯著，用戶體驗大大改善。ERP標(biāo)準(zhǔn)模塊加速無需重新實施；所有現(xiàn)有內(nèi)容開發(fā)和其他投資將會完全兼容和保護；加速月結(jié)：加速財務(wù)報表，加速物料帳月結(jié)；加速層級報表：報告維度不再有限制，超快響應(yīng)時間；增強行項目分析能力：更快速的獲取信息，海量和任意條件數(shù)據(jù)查詢。Exadata整個系統(tǒng)數(shù)據(jù)需要遷移，遷移過程比較復(fù)雜，并且需要有相當(dāng)?shù)耐C時間，對業(yè)務(wù)操作產(chǎn)生影響。系統(tǒng)切換復(fù)雜，需要由專業(yè)DBA來實現(xiàn)數(shù)據(jù)轉(zhuǎn)移。系統(tǒng)切換后，部分

28、查詢還是需要SQL調(diào)優(yōu)的方式來優(yōu)化，并且優(yōu)化效果不可預(yù)計。數(shù)據(jù)處理機制未改變，磁盤處理方式未能擺脫IO處理等關(guān)鍵技術(shù)點的限制所有加速來自底層硬件優(yōu)化，不提供基于應(yīng)用層面的處理優(yōu)化。優(yōu)勢項弱勢項劣式項其它項對比：HANA與Exadata的比較 4/4對比項深入應(yīng)用功能數(shù)據(jù)同步數(shù)據(jù)分析模型是否可建模數(shù)據(jù)可預(yù)測分析數(shù)據(jù)可視化SAP HANA數(shù)據(jù)通過SLT實時同步，數(shù)據(jù)吞吐量有大量案例，可支持大規(guī)模的數(shù)據(jù)處理。HANA加速器中，SAP提供大量現(xiàn)成的分析模型，用戶可以選擇直接使用或在模型上做增強，大大降低了客戶應(yīng)用的開發(fā)成本?？蓜?chuàng)建靈活的內(nèi)存數(shù)據(jù)模型，以適應(yīng)不同類型，以及不同格式的分析需求HANA加速器

29、中，可提供數(shù)據(jù)預(yù)測分析功能，提供基于現(xiàn)有數(shù)據(jù)的業(yè)務(wù)趨勢分析，極大的提升數(shù)據(jù)價值提供快速應(yīng)用開發(fā)平臺，可在HANA加速器上實現(xiàn)數(shù)據(jù)可視化，或移動應(yīng)用快速部署。Exadata系統(tǒng)及數(shù)據(jù)遷移，但是實際上只是同樣的數(shù)據(jù)庫運行在不同的硬件上而已。完全不提供分析模型完全不提供建模功能完全不提供預(yù)測模型完全不提供可視化功能優(yōu)勢項弱勢項劣式項SAP HANA：卓越的企業(yè)應(yīng)用簡化工具SAP HANA 基于 SAP HANA 的 SAP Business Warehouse 基于 SAP HANA 的 SAP Business Suite 基于 SAP HANA 的 SAP Simple Finance實時分析實

30、時報告實時業(yè)務(wù)OLAP 和 OLTP 集成一體面向基于 SAP HANA 的 SAP Business Suite 的 SAP HANA Enterprise Cloud (SAP HANA 企業(yè)云）內(nèi)存平臺即時的財務(wù)洞察無聚合數(shù)據(jù)單一的真實信息源簡單的數(shù)據(jù)模型全新的用戶體驗先進的處理方式靈活的部署選擇20112013201220142015應(yīng)用與平臺看事物的不同角度從應(yīng)用到平臺從平臺到應(yīng)用業(yè)務(wù)價值點客戶應(yīng)用業(yè)務(wù)功能完整最終用戶可操作性技術(shù)領(lǐng)先數(shù)據(jù)安全保護平臺通用完整應(yīng)用與平臺越來越緊密應(yīng)用離不開平臺應(yīng)用邏輯下沉應(yīng)用持續(xù)使用應(yīng)用性能提升平臺離不開應(yīng)用數(shù)據(jù)存儲方式硬件環(huán)境配置HA與災(zāi)備基于SAP

31、 HANA的SAP Business Suite財務(wù)會計和財政結(jié)算財務(wù)快速關(guān)帳 實時財務(wù)績效管理 應(yīng)收應(yīng)付管理有效應(yīng)收賬款管理有效應(yīng)付賬款管理財政和財務(wù)風(fēng)險管理 集中財政風(fēng)險管理企業(yè)風(fēng)險合規(guī)訪問控制角色分析自動化跨系統(tǒng)流程控制市場，銷售，服務(wù)銷售：訂單及合同管理優(yōu)化報價管理合作伙伴/渠道銷售;銷售支持洞察力驅(qū)動的銷售市場計劃和資源管理洞察力驅(qū)動市場活動客戶服務(wù)管理有效合同中心洞察力驅(qū)動的服務(wù)供應(yīng)鏈管理倉庫管理和操作性采購實時庫存管理有效采購策略性采購優(yōu)化制造和供應(yīng)計劃洞察力驅(qū)動的供應(yīng)鏈計劃企業(yè)資產(chǎn)管理維護運營最大化資產(chǎn)使用和運行時間人力資源核心Core HR和工資加速組織架構(gòu)變化公示洞察力驅(qū)動

32、的勞動力成本管理研究開發(fā)企業(yè)包和項目管理端到端訂單設(shè)計管理復(fù)雜項目的最大化生產(chǎn)和盈利制造生產(chǎn)計劃實時物料計劃即刻物料流控制Oracle DB In-Memory & Exadata 不具備SAP ERP中25 業(yè)務(wù)場景的特別優(yōu)化只有利用HANA優(yōu)化現(xiàn)有的數(shù)據(jù)結(jié)構(gòu)，才能使SAP ERP發(fā)揮最大價值聚合的數(shù)據(jù)行項目表應(yīng)用現(xiàn)有的財務(wù)模塊Financials Accounting:BSEGControlling:COEPSoH的場景Financials Accounting:BSEGControlling:COEPHANA實時HANA視圖應(yīng)用在智能財務(wù)下的會計統(tǒng)一的會計“大憑證”PayablesRec

33、eivablesRevenue & CostFixed Assets性能指標(biāo)數(shù)據(jù)容量業(yè)務(wù)用戶對于系統(tǒng)性能的抱怨Oracle加速器場景智能財務(wù), 智能物流, 基于HANA特性的業(yè)務(wù)優(yōu)化場景：月結(jié)-過渡到連續(xù)處理實時處理的流程設(shè)計大大減少了月結(jié)瓶頸Real-time analytics for process oversight本地月結(jié)流程需要涉及超過100個工作項及多個批次帶來的瓶頸價值驅(qū)動消除月末批處理瓶頸實時的公司間對賬財務(wù)報表的即時可查詢CO-PA行項目級別的實時對賬流程任務(wù)自動執(zhí)行關(guān)帳駕駛艙實時監(jiān)控進程面臨的挑戰(zhàn)多批運行環(huán)境依賴關(guān)系 批量瓶頸延緩下游活動 更多糾錯工作的存在 拖到后期密切

34、復(fù)雜的問題 時間壓力 延遲能見度報告可見的優(yōu)勢50%減少總賬的過賬錯誤60%減少收入確認以及過賬時間70%減少解決分配問題的時間關(guān)閉批次合并批次月結(jié) & 合并初始階段傳統(tǒng)月結(jié)月結(jié) & 合并初始階段即時報表基于HANA的月結(jié)選擇Suite on HANA的理由選擇ERP ON HANA的理由基于內(nèi)存計算的SAP ERP應(yīng)用，整體性能高于普通磁盤數(shù)據(jù)庫。SAP ERP中25個業(yè)務(wù)場景為HANA特別優(yōu)化。加速效果上看，報表性能提升1000倍，MRP性能提升4倍，財務(wù)清帳速度提升70倍，主數(shù)據(jù)讀取性能提升40倍，憑證讀取性能提升50倍。將來SAP商務(wù)套件將以HANA作為主推數(shù)據(jù)庫，在HANA之上不斷推

35、出新的應(yīng)用和更新。軟件采購成本SAP對生產(chǎn)系統(tǒng)之外的系統(tǒng)不收費用，客戶可任意部署多套應(yīng)用。購買HANA的Runtime License，DB部分只需要Application費用的15%用戶采購ERP時使用Oracle數(shù)據(jù)庫需要支付22%的DB軟件許可費，In-Memory License需要額外支持4.5%使用HANA作為數(shù)據(jù)庫服務(wù)器，在硬件投資上對于普通數(shù)據(jù)庫的部署成本，將降低70%以上。SAP HANA數(shù)據(jù)庫運維簡單，維護成本降低40%以上。完全整合場景AnyDB與傳統(tǒng)應(yīng)用并存場景只有ERP on HANA才能真正提高性能并且為業(yè)務(wù)轉(zhuǎn)型帶來價值Business Suite on HANAH

36、ANA DBCRMSCMSRMPLMERPVDLSAP Business SuiteBWAppsCust Mart AppSAP BusinessSuiteHANA DB傳統(tǒng)數(shù)據(jù)庫上的ERP, BW on HANA, HANA加速器以及數(shù)據(jù)集市AnyDBHANA DBBWSAP BusinessSuite在傳統(tǒng)數(shù)據(jù)庫上的ERP以及BW on HANA場景的結(jié)合SAP HANA 架構(gòu)應(yīng)用場景AnyDBBWAnyDBAnyDBBWSAP BusinessSuite在傳統(tǒng)數(shù)據(jù)庫上的ERP、BW的場景傳統(tǒng)場景在傳統(tǒng)數(shù)據(jù)庫上的ERP以及BW on HANA場景的結(jié)合業(yè)務(wù)流程的健壯性實時運營類報表支持業(yè)務(wù)

37、模式的改進和創(chuàng)新Business Suiteon HANA管理報表敏捷化獲益針對于行業(yè)特點的優(yōu)化持續(xù)的技術(shù)創(chuàng)新平臺傳統(tǒng)數(shù)據(jù)庫上的ERP, BW on HANA, HANA加速器以及數(shù)據(jù)集市在傳統(tǒng)數(shù)據(jù)庫上的ERP、BW的場景SAP HANA運行于 Oracle In-memory 與 SAP HANA 之上的 SAP 應(yīng)用SAP Business Suite基于 Oracle 的 SAP Business Suite數(shù)據(jù)模型 - 表格、聚合Any DB基于 Any DB 的 SAP Business SuiteSAP Business Suite應(yīng)用邏輯 數(shù)據(jù)模型 - 表格、聚合Oracle 12c In-Memory很少的應(yīng)用邏輯將通過核心數(shù)據(jù)服務(wù) (CDS) 進行轉(zhuǎn)移無簡化的數(shù)據(jù)模型無簡化的業(yè)務(wù)流程無現(xiàn)代