商業(yè)需求 |
Oracle內(nèi)存數(shù)據(jù)庫 |
SAP HANA |
用現(xiàn)有的App、BI和報告工具透明化工作。 |
跟所有Oracle軟件、獨立軟件供應(yīng)商(ISV)工具和除了自定義撰寫的app外的應(yīng)用程序?qū)崿F(xiàn)100%兼容。 |
相比之下功能很少。需要新的應(yīng)用程序或重新編碼現(xiàn)有的應(yīng)用程序。 |
云計算、大數(shù)據(jù)和數(shù)據(jù)庫的兼容。 |
沒有數(shù)據(jù)庫大小限制,使用動態(tài)隨機存取內(nèi)存(DRAM)、flash和透明磁盤。因為用戶不需要把他們的所有數(shù)據(jù)都放在昂貴的DRAM上,所以不存在存儲超支問題。 |
整個數(shù)據(jù)庫必須適合昂貴的DRAM,并且將不適合大型數(shù)據(jù)倉庫和大數(shù)據(jù)。數(shù)據(jù)庫云整合也不是可行的。SAP聲稱用戶可以將HANA與其他例如Sybase的數(shù)據(jù)庫連接起來,從而實現(xiàn)HANA數(shù)據(jù)的轉(zhuǎn)移和補充,,但是這個體系結(jié)構(gòu)會很脆弱、復(fù)雜和緩慢。 |
確保數(shù)據(jù)的可用性和安全性。 |
經(jīng)證明Oracle的最大可用性架構(gòu)是用Oracle內(nèi)存數(shù)據(jù)庫來繼承的,減少了計劃內(nèi)和計劃外的運行中斷。內(nèi)存復(fù)制會避免在節(jié)點故障時的停機時間。 |
不成熟的產(chǎn)品和可用性特性的丟失使得停機時間不可避免。沒有從節(jié)點故障中快速恢復(fù)的能力。安全功能是基本的。這需要多年的實際經(jīng)驗來覆蓋所有高可用性和高安全性情況。 |
沒有硬件鎖定或限制。 |
Oracle內(nèi)存數(shù)據(jù)庫可以在任何平臺上運行Oracle 12c數(shù)據(jù)庫。 |
HANA只能在經(jīng)過認(rèn)證的SAP上運行來自合作伙伴的基于x86的HANA設(shè)施??蛻魺o法在現(xiàn)有的未認(rèn)證硬件上運行HANA。 |
利用現(xiàn)有的IT人才。(DBAs,開發(fā)者) |
不要求新的API和最小的新DBA命令,就可以使Oracle內(nèi)存數(shù)據(jù)庫瑣碎的實現(xiàn)和維護。 |
因為HANA是一個新的以獨特的操作過程和編程來實踐的“平臺”,一個新的團隊或再進行培訓(xùn)是必要的。 |
尺度分析和在線事務(wù)處理(OLTP)。 |
Oracle內(nèi)存數(shù)據(jù)庫的獨特的雙格式支持透明的擴大、擴展分析和OLTP工作負(fù)載一起運行。 |
HANA對高性能的分析使用列的格式,其對OLTP的性能和可伸縮性有著嚴(yán)重的建筑性限制。其按比例增長和擴展方面很不成熟。 |
分享到微信 ×
打開微信,點擊底部的“發(fā)現(xiàn)”,
使用“掃一掃”即可將網(wǎng)頁分享至朋友圈。