0 引言

在大數(shù)據(jù)和云計算熱潮中,內(nèi)存數(shù)據(jù)庫市場的復(fù)合年增長率為43％（全球研究公司Markets＆Markets預(yù)測）,從2013年的22.1億美元躍升至2018年的132.3億美元。內(nèi)存計算最重要的驅(qū)動力來自內(nèi)存數(shù)據(jù)庫允許對“實時”事務(wù)數(shù)據(jù)的實時分析和實時的情境意識,而不是對“過時數(shù)據(jù)”進行事后分析。

更多公司正在采用或者計劃采用實時分析,這樣做的驅(qū)動是來自增加業(yè)務(wù)流程的速度和準(zhǔn)確性的壓力,特別在數(shù)字業(yè)務(wù)和物聯(lián)網(wǎng)方面。隨著數(shù)據(jù)規(guī)模越來越大,從萬億字節(jié)(TB)到千萬億字節(jié)(PB)級;一部智能手機每日可產(chǎn)生30 MB左右的數(shù)據(jù)量,而一座高自動化的工業(yè)4.0的工廠,一天產(chǎn)生的數(shù)據(jù)可以超過一個PB。大數(shù)據(jù)所帶來的大規(guī)模及需要實時處理等特點與傳統(tǒng)的以計算為中心的模式產(chǎn)生巨大矛盾,使得傳統(tǒng)計算模型難以適應(yīng)當(dāng)今大數(shù)據(jù)環(huán)境下的數(shù)據(jù)處理。數(shù)據(jù)處理從以計算為中心轉(zhuǎn)變成以數(shù)據(jù)為中心,通過使用傳統(tǒng)的內(nèi)存—磁盤訪問模式處理大數(shù)據(jù)存在I/O瓶頸,處理的速度問題愈發(fā)突出,且時效性難以保證,現(xiàn)有的方案都只能一定程度上緩解這個瓶頸。每家大型公司每分鐘都會做出數(shù)千次實時決策,企業(yè)的需求使得內(nèi)存計算技術(shù)成為目前廣受關(guān)注的技術(shù)。本文研究了從海量數(shù)據(jù)中識別出哪些數(shù)據(jù)是真正的熱點數(shù)據(jù),然后根據(jù)數(shù)據(jù)的熱度,分別將數(shù)據(jù)放入列式內(nèi)存、行式內(nèi)存、閃存和硬盤,進行存儲的智能分級管理,進而通過內(nèi)存計算技術(shù)支持企業(yè)級實時計算需求^[1]。

 1 數(shù)據(jù)庫內(nèi)存計算

內(nèi)存計算的概念最早被提出是在20世紀(jì)90年代,當(dāng)時硬件發(fā)展有限,沒有得到進一步深入研究。直至2010年以后,隨著內(nèi)存價格大幅下降,內(nèi)存容量增長,將大量數(shù)據(jù)存入專用服務(wù)器內(nèi)存得以實
現(xiàn)^[2]。而真正在企業(yè)級核心系統(tǒng)中運用最成功的方式是Database In-Memory,即內(nèi)存數(shù)據(jù)庫。關(guān)系型數(shù)據(jù)庫管理系統(tǒng)（Relational Database Management System,RDBMS）作為企業(yè)核心數(shù)據(jù)的管理系統(tǒng),如果具備內(nèi)存計算能力,可以直接使企業(yè)的業(yè)務(wù)系統(tǒng)獲得實時計算的能力。這個領(lǐng)域也涌現(xiàn)出眾多的技術(shù)方案,其中Oracle的Oracle Database In-Memory選件是應(yīng)用較為成功的技術(shù),可以支持用戶在不修改原有程序的情況下,快速實現(xiàn)內(nèi)存計算,透明地加速分析查詢^[3],從而大幅度提升計算性能,實現(xiàn)實時業(yè)務(wù)決策。

Oracle Database In-Memory技術(shù)要點是同時以行、列2種形式緩存數(shù)據(jù)^[4]。Oracle數(shù)據(jù)庫傳統(tǒng)上以行格式存儲數(shù)據(jù)。在一個行格式數(shù)據(jù)庫中,數(shù)據(jù)在數(shù)據(jù)庫中以行式存儲,每行數(shù)據(jù)包含多列,每列代表關(guān)于該記錄的不同屬性。行格式是聯(lián)機事物處理系統(tǒng)（Online Transaction Processing,OLTP）的理想選擇,給定記錄的所有屬性順序保存在一起,可以快速訪問記錄中的所有列。列格式數(shù)據(jù)庫將記錄的每個屬性以列的形式存儲,列格式是聯(lián)機分析系統(tǒng)（On-Line AnalysisProcessing,OLAP）的理想選擇,因為它只允許更快的數(shù)據(jù)檢索^[5]。

Oracle Database In-Memory支持在內(nèi)存中同時緩存行、列2種格式,這種雙格式的內(nèi)存計算架構(gòu)不會增加太多的內(nèi)存開銷,通過數(shù)據(jù)壓縮和內(nèi)存存儲優(yōu)化,增加列式緩存后內(nèi)存開銷只增大約20％^[6]。相對于性能方面的提升,內(nèi)存方面為了獲得最佳性能而付出的代價是很小的。雙格式的內(nèi)存計算架構(gòu)如圖1所示。

圖1 雙格式的內(nèi)存計算架構(gòu)Fig.1 Dual-format Database In-Memory architecture

Database In-Memory做到了行列2種格式的共存,并且實現(xiàn)了2種格式數(shù)據(jù)的事物級一致性^[7],使得OLAP業(yè)務(wù)通過內(nèi)存計算提升性能,支持實時分析,同時還可以較少分析類索引數(shù)量,使得OLTP類業(yè)務(wù)性能也有提升,充分體現(xiàn)了內(nèi)存計算的優(yōu)勢。

 2 數(shù)據(jù)熱圖

信息生命周期管理（Information Lifecycle Management,ILM）是根據(jù)企業(yè)當(dāng)前的業(yè)務(wù)和性能需求將數(shù)據(jù)存儲在不同的存儲和壓縮層中,這種方法提供了優(yōu)化存儲以節(jié)省成本和最大性能的可能性。

在Oracle Database 12c中包含2個ILM功能。一是數(shù)據(jù)熱圖（Heat Map）,通過熱圖可以聚合大量數(shù)據(jù),使用直觀的方式表現(xiàn)數(shù)據(jù)的溫度,自動跟蹤在行和段級別的修改和查詢時間戳,提供有關(guān)如何訪問數(shù)據(jù)的詳細(xì)信息^[8-9]。二是自動數(shù)據(jù)優(yōu)化（Automatic Data Optimization,ADO）,根據(jù)熱圖收集的信息,利用用戶定義的策略自動移動和壓縮數(shù)據(jù)。Heat Map和ADO可以利用Oracle數(shù)據(jù)庫壓縮和分區(qū)技術(shù)降低管理大量數(shù)據(jù)的成本,同時還能提高應(yīng)用程序和數(shù)據(jù)庫性能。

數(shù)據(jù)熱圖可以細(xì)粒度地跟蹤數(shù)據(jù)使用情況,跟蹤行和段級別的表/分區(qū)使用信息,以及在行級別跟蹤數(shù)據(jù)修改時間、全表掃描時間,聚合到塊級別,并在段級跟蹤索引查找時間。熱圖提供了數(shù)據(jù)使用情況的詳細(xì)視圖,以及訪問模式如何隨時間變化的信息。數(shù)據(jù)熱圖示例如圖2所示。

圖2 數(shù)據(jù)熱圖示例Fig.2 Heat map data example

圖2展示的是數(shù)據(jù)熱圖的一種形式,每個框表示表的一個分區(qū),框的大小是分區(qū)的相對大小,顏色表示對分區(qū)中任何行的最近訪問溫度。紅色表示該對象讀寫操作都比較頻繁;黃色表示該對象只有查詢操作,即只讀;藍(lán)色表示該對象不參與任何類型的活動。

紅色說明數(shù)據(jù)最熱,黃色可以叫做溫數(shù)據(jù)。如果為藍(lán)色,則這類數(shù)據(jù)可以安全地移動到低級存儲設(shè)備（例如遷移到性能較低的廉價存儲）,這種類型的數(shù)據(jù)也被稱為“過期數(shù)據(jù)”或“歸檔數(shù)據(jù)”。

企業(yè)級系統(tǒng)由于數(shù)據(jù)量龐大,如果簡單的將所有數(shù)據(jù)按照相同服務(wù)水平管理,如采用同一級別的存儲保存所有數(shù)據(jù),則無法控制系統(tǒng)的成本或保證應(yīng)用的性能。最關(guān)鍵或經(jīng)常訪問的數(shù)據(jù)需要最佳的性能和可用性,但為所有數(shù)據(jù)提供這種最佳的訪問質(zhì)量的存儲方案是昂貴的,低效的,并且在結(jié)構(gòu)上通常是不可能做到的。因此需要實施數(shù)據(jù)存儲分層的分級管理。

通過存儲分層,可以將數(shù)據(jù)部署在不同的存儲層上,從而將較少訪問（較冷）的數(shù)據(jù)遷移出最昂貴、最快的存儲。較冷的數(shù)據(jù)仍然在線可用,但速度較慢,這是由于較冷數(shù)據(jù)的很少訪問對整體應(yīng)用程序性能的影響最小。活躍程度更低的數(shù)據(jù)也可以在存儲中被壓縮到更高的水平。數(shù)據(jù)生命周期管理常用技術(shù)是存儲分層與數(shù)據(jù)壓縮。

數(shù)據(jù)存儲分級主要是內(nèi)存、閃存、普通固態(tài)硬盤（Solid-State Disk,SSD）、機械磁盤與離線存儲的磁帶。SSD存儲設(shè)備與傳遞機械硬盤不同,SSD可以并行處理多個隨機存取請求,不會產(chǎn)生單個I/O請求降級導(dǎo)致的等待時間^[10-11],組合多種介質(zhì)和數(shù)據(jù)壓縮可以構(gòu)造出更多的層次。

 3 自動化協(xié)同架構(gòu)

內(nèi)存計算、數(shù)據(jù)熱圖和數(shù)據(jù)分級存儲3種技術(shù)各有側(cè)重。其中數(shù)據(jù)熱圖與數(shù)據(jù)分級存儲主要應(yīng)用于數(shù)據(jù)生命周期管理,內(nèi)存計算則用于實時分析。采用熱圖結(jié)合分級策略,將最需要的數(shù)據(jù)放入內(nèi)存中,實現(xiàn)3種機制的自動化協(xié)同,達(dá)到在最低內(nèi)存成本上的最大性能收益。內(nèi)存計算、數(shù)據(jù)熱圖和數(shù)據(jù)分級存儲自動化調(diào)度模型如圖3所示。

圖3 自動化調(diào)度模型Fig.3 Automated scheduling model

3.1 決策引擎

決策引擎是系統(tǒng)的關(guān)鍵部分,旨在優(yōu)化數(shù)據(jù)庫中的數(shù)據(jù)分析類操作,基于知識庫分析數(shù)據(jù)庫中存在的分析處理工作負(fù)載,推薦需要加載或卸載出內(nèi)存的數(shù)據(jù),并提供決策實施后估計收益。

決策引擎主要有3部分組成：策略庫、熱圖、模式匹配模塊。決策引擎工作模式如圖4所示。

圖4 決策引擎工作模式Fig.4 Decision engine working mode

決策引擎基于數(shù)據(jù)熱圖分析數(shù)據(jù)的溫度,根據(jù)對數(shù)據(jù)庫對象的SQL操作模式、活動會話歷史（Active Session History,ASH）的跟蹤數(shù)據(jù),結(jié)合使用其他統(tǒng)計信息來分析數(shù)據(jù)的分區(qū)和分布情況。

預(yù)置的策略主要邏輯是消除用戶I / O等待、集群傳輸?shù)却途彌_區(qū)高速緩存鎖等待等數(shù)據(jù)庫等待事件,可以分析某些查詢處理的特點,推薦特定的壓縮類型。預(yù)置的策略是基于業(yè)務(wù)模式、數(shù)據(jù)庫建模和數(shù)據(jù)庫運維的經(jīng)驗人工創(chuàng)建的。根據(jù)策略引擎的決策可以自動或人工確認(rèn)后通過DBMS管理包進行對象加載/卸載操作。

策略庫中預(yù)定義了一些數(shù)據(jù)優(yōu)化的規(guī)則。如：某表或分區(qū)累計30天沒有寫操作,沒有頻繁讀操作,則推薦進行列式壓縮;某表或分區(qū)累計30天有少量寫操作,多次全表掃描,則推薦加載到列式內(nèi)存緩存區(qū)域;某表為時間分區(qū)表,按天分區(qū)。按業(yè)務(wù)規(guī)則,每天凌晨完成入庫,當(dāng)日日間頻繁查詢,人工定義每日加入列式內(nèi)存緩存區(qū)域,7天后卸載出內(nèi)存。

策略庫隨著信息不斷收集入庫,逐漸豐富,決策越來越準(zhǔn)確。策略庫結(jié)合數(shù)據(jù)熱圖中的熱點數(shù)據(jù)進行模式匹配,模式匹配將從熱圖中找到的熱點數(shù)據(jù)按照策略庫中提供的規(guī)則逐條過濾,發(fā)現(xiàn)符合條件的熱點數(shù)據(jù),則按照策略向數(shù)據(jù)生命周期管理引擎發(fā)起操作請求。

決策引擎底層數(shù)據(jù)庫建模如圖5所示。

圖5 決策引擎數(shù)據(jù)庫建模Fig.5 Decision engine database modeling

決策引擎的決策過程基于數(shù)據(jù)庫熱圖的幾個基礎(chǔ)視圖,如：v$heat_map_segment,以及本身策略庫的基礎(chǔ)表T_RULE和記錄決策引擎制定出的數(shù)據(jù)生命周期管理的方案T_OBJPOLICY,還有引擎運算使用的數(shù)據(jù)庫和操作系統(tǒng)各種狀態(tài)指標(biāo)的采集表。

3.2 數(shù)據(jù)生命周期管理引擎

Oracle Database12cR1中推出了Automatic Data Op