成為一個“Real-Time Enterprise”并不需要將整個數據庫放在內存當中，如果你是Oracle Database的用戶，并且購買了最新的Oracle Database In-Memory Option(甲骨文數據庫內存計算選件)。
具體來說，實現的步驟有三步：
1、配置內存中列存儲的容量;
2、將表或分區加入列存儲中;
3、刪除分析型索引，提升OLTP性能
按照甲骨文公司數據庫技術產品執行副總裁Andrew Mendelsohn的說法，甲骨文數據庫內存計算選件避免了企業用戶及開發者的“選擇性犧牲”和“硬件成本的提升”。他很直接的表示，對于其他的數據庫供應商來說，內存計算的成本和復雜度都較高，而且會造成用戶在不同業務領域使用數據庫時的鎖定。
很顯然，Andrew Mendelsohn的矛頭直指在內存計算(In-Memory Computing)市場風頭強勁的競爭友商SAP及其SAP HANA內存計算解決方案。他認為，在內存計算市場，或者說在內存計算技術解決方案的應用上，“企業用戶存在著一定的誤區”，只有甲骨文公司能夠改變這一切。
TB級內存的內存計算無法普及
在“Wintel(Windows+Intel)”時代，軟件開發商和硬件供應商被認為是“沆瀣一氣”的，隨著軟件功能的多樣化以及特性的提升，需要更好的硬件來支持，似乎是一條必然的定理。
同樣的思路也存在于內存計算領域。2014年初，英特爾發布最新一代面向關鍵業務及實時計算的至強E7 v2處理器，四插槽和八插槽系統的內存容量高達6TB及12TB，成為當今單一系統內Scale-up最高的內存容量，這被認為是為了順應內存計算這一重要的實時計算實現方式，特別是在大數據時代。
問題在于，實現這一大容量單一系統內存硬件架構的成本十分昂貴，甚至是不現實的：內存的價格十分昂貴，尤其是面向關鍵業務服務器平臺的內存，為了達到最大的內存容量，單條32GB內存是必須的，但其價格并不是16GB內存的2倍或8GB內存條的4倍，而是更高。
即便是為了關鍵業務系統或是實時的大數據內存計算，企業CIO也無法承受四路或八路服務器平臺通過32GB單條內存滿配的成本。
因此，在相當長的一段時間內，內存計算被認為是“昂貴且無法普遍使用的”。雖然SAP HANA在市場上的聲音很多，IBM、惠普、戴爾相繼認證了SAP HANA系統平臺，但整體來看，內存計算市場更像是一個陽春白雪的“金字塔尖”：要知道，2012年3月前的6個月中，SAP HANA In-Memory系統雖然從200個客戶手中獲得了兩億美元的營收，但平均每個客戶的成本高達100萬美元。
甲骨文也同樣推出了Exalytics In-Memory系統，并行執行TimesTen和Essbase數據庫，是一個類似SAP HANA的“將整個數據庫全部放入內存”的內存計算系統，但價格同樣高昂：根據2012年媒體披露的信息，Exalytics硬件價格為13.5萬美元。
對于用戶遍布全球各行各業的Oracle Database來說，在其上實現通用性更強、價格更加便宜、易用性更好以及與現有系統融合更充分的內存計算系統，如果采取類似的實現方式，“內存計算可能永遠也無法普及”。
內存計算應保持輕量級和普適性
“我們看到許多其他的內存數據庫的產品，都需要購買很多內存，(但甲骨文的內存計算)可以選擇在表、分區等不同的級別容量上購買內存。”Andrew Mendelsohn表示，內存計算不應成為企業的硬件負擔，甲骨文認為，它應當能夠基于現有的IT基礎設施和投資具備內存計算的能力，適應所有的工業化的、主流的標準硬件設備。
“你不需要選擇或是等待需要經過(內存計算方案)認證的硬件平臺。” Andrew Mendelsohn此言直指不斷發布“XXX服務器經過SAP HANA認證”的競爭對手解決方案。
“適應所有主流硬件平臺”的Oracle Database In-Memory Option并非也只能運行在標準硬件上(在采訪時，甲骨文公司驗證了其在雙插槽服務器上的驚人效率)——企業間也存在著“貧富差距”——Oracle M6-32 大內存機(Oracle M6-32 Big Memory Machine)是適合Oracle Database In-Memory的、最強大的縱向擴展平臺，提供多達32TB DRAM內存和3TB/秒內存帶寬，最大限度地提高了內存性能。
此外，Oracle Database In-Memory Option可以在大型SMP服務器上縱向擴展、跨服務器集群的橫向擴展以及存儲分層(將內存訪問、閃存優化以及磁盤存儲進行分層，將活躍度較低的數據轉移到閃存和磁盤中)，來進一步提高系統的運行效率、降低成本。
列式數據庫非常重要 但只在內存里即可
列式數據庫——或者說是數據庫格式——是內存計技術的另一個關鍵點，但在一般場景中，傳統的行式數據庫和列式數據庫是不能夠共存的：“對于企業用戶或開發者來說，必須做出選擇，或者說是犧牲。” Andrew Mendelsohn表示。
“過去從來沒有人嘗試過混合兩種格式進行應用，它們都是在獨立的(環境中)應用。甲骨文則把列式數據庫引入了傳統的甲骨文行式數據庫，進一步引入了Oracle Database In-Memory Option。對于其他的數據庫產品，在你寫(創建)一個表時，就要決定是行式還是列式，也就是決定了把這個表用來做什么，應用開發者必須要在最初做出決定：為交易型應用優化還是分析型應用。”
在企業應用中，行式數據庫和列式數據庫有著不同的用途：
· 交易型應用在行式數據庫中更快，比如電子商務類的應用。主要的操作是插入或查詢一條信息(比如銷售訂單)，在訪問少量行，大量列時更快。
· 列式數據庫則主要被用來進行分析，更適合統計分析型應用，比如按照地域生成銷售額報告，與行式數據庫相反，其在訪問大量行，少量列數據時會更快。
但內存計算的一大重要目的，就是實現在線數據的實時分析，由行式數據庫(在線交易系統)到列式數據庫(近線分析平臺)的路徑延遲、復雜度都會減損實時在線分析的效果和響應速度，并意味著應用開發及數據庫建立時的雙重工作。
Andrew Mendelsohn談到，甲骨文的創新在于“同一張表在內存中同時支持行和列兩種格式，同時激活并保持事務一致性”：分析和報表使用新的內存列格式，OLTP使用久經考驗的行格式。但他也表示，甲骨文采用的是“內存列式存儲技術”，也就是純內存中的列格式存儲，而非對速度較慢的磁盤也做出改變。
“Oracle內存列式存儲技術無需持久化、無需記錄日志，能夠快速響應數據變化。” Andrew Mendelsohn認為，列式數據格式是為了分析，而不是為了業務運營，需要的是快速響應數據變化而不是將至持久化，“純內存中的列式存儲能夠快速響應數據變化，且可達到2倍至20倍的壓縮比例，其粒度還支持表級與分區級”。此外，純內存格式不改變Oracle的存儲格式、日志、備份或是恢復。
據甲骨文方面資料顯示，在測試當中，列格式的每CPU內核可達到10億條/秒的掃描速度，而行格式僅能達到百萬條，性能的提升高達一百倍以上。不僅如此，通過將多表的連接操作轉化為高效的列掃描，表連接速度也加快10倍。
對很多企業來說，內存計算現階段還不是“一場數據與業務的變革”，更多的是錦上添花——一張報表不需要等待1天、1小時，只需要幾分鐘——甲骨文必須解決一個問題：不能夠對現有的業務產生影響，更要延續原本在甲骨文生態環境上用戶熟悉的生態環境。
Andrew Mendelsohn給出了答案。
混合工作負載 延續生態環境
“關鍵是不用犧牲在線交易型應用的性能，要同時兼顧兩種不同的應用。”在Andrew Mendelsohn所給出甲骨文內存計算“三步操作”中最后一步是“刪除分析型索引，提升OLTP性能”，這也是Oracle Database In-Memory Option對現有在線業務系統最有利的一部分。
傳統OLTP系統為了實現快速查詢，往往在數據庫中建立分析型索引，在這樣的架構下，向表中插入一條記錄需要同時更新數十個索引，OLTP系統性能被迫降低。然而，通過用列存儲取代分析型索引，新的OLTP系統中可以給予任意一列實現快速分析，OLTP和批處理的速度得到提升。
“關系型數據庫中的分析索引只是為了分析，僅僅加速了定制查詢和報表，而每次修改或插入數據條目，還都需要同時更新10-20個分析型索引，速度很慢。” Andrew Mendelsohn表示，列式存儲可以基于任何一列實現快速分析，讓數據庫減少甚至刪除分析型索引，也就不必在插入和修改時再去顧及索引的修改，這能夠幫助OLTP和批處理速度更快。
他認為，與OLTP的速度提升同樣關鍵的是，在同一個關系型數據庫中，OLTP的速度和實時分析的速度都加快了，能夠實現混合型工作負載，而不是互相分隔、互相獨立的系統，在Thales-Raytheon Systems公司，Oracle Database In-Memory Option“允許我們將近一半的索引從支撐混合負載的大型數據庫中刪除，在提升復雜查詢速度的同時，加快了OLTP業務操作的性能。”該公司的軟件工程師Andrew Zitelli表示。
此外，Oracle Database In-Memory在任何與Oracle數據庫兼容的現有應用環境中，都能夠非常簡單、快捷地進行部署。測試結果顯示，包括Oracle電子商務套件、Oracle JD Edwards、Oracle PeopleSoft、Oracle Siebel和Oracle融合應用等在內的一系列應用都可以獲得1000倍以上的性能提升。
與云計算市場的戰略一樣，Oracle Database In-Memory同樣延續了整個甲骨文生態環境上的各項能力，包括Oracle Exadata數據庫云服務器和Oracle SuperCluster在內的Oracle集成系統針對Oracle Database In-Memory進行了優化;透明支持所有甲骨文高可用性方案，比如Oracle RAC或是Oracle Data Guard;Oracle集成系統的內存容錯功能同樣也可以使用，它可以被用來跨多個節點選擇性地復制內存數據;Direct-to-Wire Infiniband則提高了內存的橫向擴展速度。
Oracle Database In-Memory Option對企業來說是一項不錯的技術，從目前掌握的信息來看，它更簡單易用、成本較低、系統利用率更好，以對現有系統最小的改造工作量，保證了“即刻”可得的實時(內存)計算。
但不可否認，SAP HANA在市場上的聲音更強，前期市場鋪墊和現在的業務認知度更高，而從下面的文檔可以看出，甲骨文確實將Oracle Database In-Memory Option的主要競爭對手瞄準了SAP HANA。
點擊下載Oracle與SAP內存計算對比文檔
這不會是一場有最終贏家的市場競爭，在不同的企業、不同的環境和不同的需求下，甲骨文和SAP可能一樣好，但如果我們將云計算、SaaS、數據庫市場、硬件平臺等多種因素考慮在一起的話，甲骨文的勝算則高出了SAP。
京公網安備 11010502049343號