0 引言

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3.1 決策引擎

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

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

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

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

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

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

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

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

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

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

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

Oracle Database12cR1中推出了Automatic Data Op