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

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

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

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

4、1年發(fā)布了Big Data Appliance是一款新的集成設(shè)計(jì)系統(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 頁），長(zhǎng)篇（84 頁）背景：2015 年 7 月，Oracle 12c（內(nèi)存）通過了運(yùn)行 SAP 應(yīng)用的認(rèn)證，例如 SAP Business Suite、SAP BW 及行業(yè)解決方案新聞稿和 SAP 內(nèi)部回應(yīng)技術(shù)事實(shí)針對(duì) SAP 應(yīng)用進(jìn)行 Oracle 12

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

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

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

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

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

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

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

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

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

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

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

16、band”: 提供40Gb/s 端口帶寬，聚合帶寬高達(dá)880Gb/s , 端口延時(shí)(0.1um ）小于以太網(wǎng)的 1/1000EXADATA性能提升的原因 HANA才是SAP王道“Smart Scan”功能在SAP ERP或SAP BW中不起作用，并會(huì)增加系統(tǒng)的負(fù)載，SAP建議關(guān)閉此功能。“混合列壓縮”功能在SAP環(huán)境中可能會(huì)導(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ù)的爭(zhēng)論，HANA采用10Gb/s萬兆以太網(wǎng)技術(shù)互聯(lián)，標(biāo)配4口并

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

35、出新的應(yīng)用和更新。軟件采購成本SAP對(duì)生產(chǎn)系統(tǒng)之外的系統(tǒng)不收費(fèi)用，客戶可任意部署多套應(yīng)用。購買HANA的Runtime License，DB部分只需要Application費(fèi)用的15%用戶采購ERP時(shí)使用Oracle數(shù)據(jù)庫需要支付22%的DB軟件許可費(fèi)，In-Memory License需要額外支持4.5%使用HANA作為數(shù)據(jù)庫服務(wù)器，在硬件投資上對(duì)于普通數(shù)據(jù)庫的部署成本，將降低70%以上。SAP HANA數(shù)據(jù)庫運(yùn)維簡(jiǎn)單，維護(hù)成本降低40%以上。完全整合場(chǎng)景AnyDB與傳統(tǒng)應(yīng)用并存場(chǎng)景只有ERP on HANA才能真正提高性能并且為業(yè)務(wù)轉(zhuǎn)型帶來價(jià)值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場(chǎng)景的結(jié)合SAP HANA 架構(gòu)應(yīng)用場(chǎng)景AnyDBBWAnyDBAnyDBBWSAP BusinessSuite在傳統(tǒng)數(shù)據(jù)庫上的ERP、BW的場(chǎng)景傳統(tǒng)場(chǎng)景在傳統(tǒng)數(shù)據(jù)庫上的ERP以及BW on HANA場(chǎng)景的結(jié)合業(yè)務(wù)流程的健壯性實(shí)時(shí)運(yùn)營(yíng)類報(bào)表支持業(yè)務(wù)

37、模式的改進(jìn)和創(chuàng)新Business Suiteon HANA管理報(bào)表敏捷化獲益針對(duì)于行業(yè)特點(diǎn)的優(yōu)化持續(xù)的技術(shù)創(chuàng)新平臺(tái)傳統(tǒng)數(shù)據(jù)庫上的ERP, BW on HANA, HANA加速器以及數(shù)據(jù)集市在傳統(tǒng)數(shù)據(jù)庫上的ERP、BW的場(chǎng)景SAP HANA運(yùn)行于 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) 進(jìn)行轉(zhuǎn)移無簡(jiǎn)化的數(shù)據(jù)模型無簡(jiǎn)化的業(yè)務(wù)流程無現(xiàn)代