關(guān)系型數(shù)據(jù)庫(kù)內(nèi)存化存儲(chǔ)模型研究

張 俊，廖雪花，余旭玲，雷 蒙

1.四川師范大學(xué) 計(jì)算機(jī)科學(xué)學(xué)院，成都 610101

2.四川師范大學(xué) 物理與電子工程學(xué)院，成都 610101

傳統(tǒng)關(guān)系型數(shù)據(jù)庫(kù)（MySQL）通過(guò)磁盤管理數(shù)據(jù)，大數(shù)據(jù)環(huán)境下，高并發(fā)請(qǐng)求會(huì)頻繁地訪問(wèn)磁盤操作數(shù)據(jù)，由于磁盤的物理結(jié)構(gòu)限制，數(shù)據(jù)庫(kù)會(huì)面臨著高穩(wěn)定性和高性能的挑戰(zhàn)，完全基于磁盤讀寫的關(guān)系型數(shù)據(jù)庫(kù)已經(jīng)不能滿足新應(yīng)用的擴(kuò)展性和時(shí)延需求。然而MySQL在歷史上積累了大量數(shù)據(jù)[1]，為了能繼續(xù)充分利用這些數(shù)據(jù)，繼續(xù)為用戶提供服務(wù)、為企業(yè)創(chuàng)造更多的價(jià)值，MySQL提供了MEMORY存儲(chǔ)引擎。該存儲(chǔ)引擎將所有數(shù)據(jù)放在內(nèi)存中。但引擎對(duì)數(shù)據(jù)字段類型有限制，表容量較小，隨著數(shù)據(jù)量的增加，需要多次的手動(dòng)修改以維護(hù)容量，應(yīng)用配置復(fù)雜。同時(shí)該引擎在數(shù)據(jù)持久化方面存在嚴(yán)重問(wèn)題，其數(shù)據(jù)易丟失。

本文提出基于Redis 實(shí)現(xiàn)MySQL 數(shù)據(jù)庫(kù)內(nèi)存化的方案，相較MySQLMEMORY，Redis 支持多種數(shù)據(jù)結(jié)構(gòu)，擁有NOSQL 高擴(kuò)展性的優(yōu)勢(shì)，同時(shí)由于Redis 在高并發(fā)場(chǎng)景下表現(xiàn)出的極高性能和易于配置、部署的優(yōu)勢(shì)，Redis在內(nèi)存數(shù)據(jù)庫(kù)中獲得了廣泛的認(rèn)可。本文利用Redis解決高并發(fā)場(chǎng)景下MySQL的I/O瓶頸問(wèn)題[2]，其核心思想是將MySQL中的熱點(diǎn)數(shù)據(jù)遷移到Redis中，應(yīng)用程序通過(guò)Redis訪問(wèn)數(shù)據(jù)，實(shí)現(xiàn)海量熱點(diǎn)數(shù)據(jù)的高效存取。

現(xiàn)階段大多應(yīng)用系統(tǒng)使用結(jié)構(gòu)化查詢語(yǔ)言SQL 操作MySQL 數(shù)據(jù)庫(kù)，但Redis 目前不支持標(biāo)準(zhǔn)SQL 訪問(wèn)，無(wú)法兼容現(xiàn)有系統(tǒng)的訪問(wèn)模式；為了降低數(shù)據(jù)的學(xué)習(xí)成本和處理成本，本內(nèi)存化方案后期將展開Redis 對(duì)查詢語(yǔ)言SQL的支持的研究。本文根據(jù)SQL化查詢的需要，對(duì)MySQL和Redis的存儲(chǔ)模型架構(gòu)進(jìn)行研究，構(gòu)建合適的存儲(chǔ)模型轉(zhuǎn)換模型，通過(guò)數(shù)據(jù)存儲(chǔ)模型實(shí)現(xiàn)異構(gòu)模型的轉(zhuǎn)換[3]，進(jìn)而實(shí)現(xiàn)數(shù)據(jù)遷移。同時(shí)在數(shù)據(jù)遷移過(guò)程中不斷提高內(nèi)存利用率，并考慮數(shù)據(jù)訪問(wèn)和操作效率。

隨著數(shù)據(jù)的爆炸式增長(zhǎng)，傳統(tǒng)的關(guān)系型數(shù)據(jù)庫(kù)在高并發(fā)模式下存在I/O 瓶頸問(wèn)題，很多關(guān)系型數(shù)據(jù)庫(kù)推出了自己的內(nèi)存化解決方案，內(nèi)存+關(guān)系型[4]數(shù)據(jù)庫(kù)的組合成為趨勢(shì)。主要包括兩個(gè)方向：內(nèi)存數(shù)據(jù)庫(kù)引擎、關(guān)系型內(nèi)存數(shù)據(jù)庫(kù)[5]。

在關(guān)系型數(shù)據(jù)庫(kù)內(nèi)存數(shù)據(jù)庫(kù)引擎方面，Oracle推出的內(nèi)存數(shù)據(jù)庫(kù)Oracle TimesTen 不提供開源技術(shù)支持；2013年IBM新推出的DB2 BLU Acceleration是基于列式的存儲(chǔ)，實(shí)際應(yīng)用中需要做數(shù)據(jù)遷移和模型轉(zhuǎn)換；此外，2016 年微軟推出了SQL Server 2016 In-memory OLTP；SAP 推出了包含內(nèi)存數(shù)據(jù)庫(kù)的SAP HANA，它融合行存儲(chǔ)、列存儲(chǔ)和對(duì)象存儲(chǔ)的數(shù)據(jù)庫(kù)技術(shù)，但系統(tǒng)過(guò)重，配置、操作異常復(fù)雜，應(yīng)用成本很高；MySQL推出的內(nèi)存存儲(chǔ)引擎MySQL MEMORY在數(shù)據(jù)類型上有限制，同時(shí)在數(shù)據(jù)持久化方面存在嚴(yán)重問(wèn)題。

關(guān)系型內(nèi)存數(shù)據(jù)庫(kù)也是解決傳統(tǒng)關(guān)系型數(shù)據(jù)庫(kù)I/O瓶頸的重要方案，它將傳統(tǒng)的關(guān)系型數(shù)據(jù)庫(kù)表搬到內(nèi)存中，內(nèi)存數(shù)據(jù)和數(shù)據(jù)庫(kù)數(shù)據(jù)之間進(jìn)行結(jié)構(gòu)映射。實(shí)際使用可以將熱點(diǎn)數(shù)據(jù)存放在內(nèi)存中，降低和數(shù)據(jù)庫(kù)之間的交互頻率，提升數(shù)據(jù)訪問(wèn)速度；但直接使用也涉及到數(shù)據(jù)遷移，且該技術(shù)生態(tài)尚未完全成熟，直接使用也存在較多限制。

不同的數(shù)據(jù)庫(kù)進(jìn)行轉(zhuǎn)換涉及到不同的數(shù)據(jù)庫(kù)之間不同存儲(chǔ)模型的轉(zhuǎn)換；大量的研究者從事基于不同數(shù)據(jù)庫(kù)和不同存儲(chǔ)模型的存儲(chǔ)模型轉(zhuǎn)換工作，提出了不同模型之間轉(zhuǎn)換的思想和方案。

Lee 等人[6]2015 年提出了通過(guò)MySQL 和HBase 數(shù)據(jù)庫(kù)自動(dòng)進(jìn)行SQL 到NoSQL 模式轉(zhuǎn)換，提供了一個(gè)從SQL 到NoSQL的轉(zhuǎn)換模式。Stanescu 等人[7]2016年提出了將MySQL數(shù)據(jù)模型轉(zhuǎn)換為MongoDB模型的算法，借助Pentaho 集成工具，使用Net Beans Java IDE 實(shí)施了該算法。2017 年，也提出了通過(guò)設(shè)計(jì)數(shù)據(jù)模型轉(zhuǎn)換器將關(guān)系型行存儲(chǔ)轉(zhuǎn)化到文檔存儲(chǔ)MongoDB 中，并通過(guò)SVM對(duì)MongoDB中的數(shù)據(jù)的進(jìn)行快速分析和處理。2018 年，楊明眠等人[8]利用二進(jìn)制日志文件將MySQL的行存儲(chǔ)模型轉(zhuǎn)換為Oracle的行存儲(chǔ)模型切實(shí)可行的方法，實(shí)現(xiàn)關(guān)系模型到關(guān)系模型的轉(zhuǎn)換。同年，Yassine等人[9]在MySQL數(shù)據(jù)轉(zhuǎn)換到MongoDB數(shù)據(jù)庫(kù)做了大量的研究，最終將MySQL的數(shù)據(jù)存儲(chǔ)模型轉(zhuǎn)換為MongoDB的文檔存儲(chǔ)模型后進(jìn)行存儲(chǔ)。賈天宇等人[10]公開了一種關(guān)系型數(shù)據(jù)庫(kù)到MongoDB的模型轉(zhuǎn)換和數(shù)據(jù)遷移方法的專利發(fā)明，該發(fā)明通過(guò)對(duì)關(guān)系型數(shù)據(jù)庫(kù)的日志信息進(jìn)行了挖掘，進(jìn)行更加科學(xué)的模型轉(zhuǎn)換。國(guó)內(nèi)外數(shù)據(jù)遷移[11]工具的研究現(xiàn)狀，是這些遷移工具雖然都可以完成數(shù)據(jù)的遷移工作，但是整體上存在以下幾點(diǎn)問(wèn)題：

（1）對(duì)遷移的數(shù)據(jù)庫(kù)的模式和組織結(jié)構(gòu)有一定的局限性。

（2）數(shù)據(jù)遷移的前期準(zhǔn)備工作復(fù)雜、多樣，配置復(fù)雜，實(shí)施困難。

（3）未長(zhǎng)遠(yuǎn)地考慮到數(shù)據(jù)遷移后的數(shù)據(jù)應(yīng)用。

（4）大多研究都基于開源關(guān)系型數(shù)據(jù)庫(kù)MySQL和文檔存儲(chǔ)數(shù)據(jù)庫(kù)MongoDB，開源關(guān)系型數(shù)據(jù)庫(kù)MySQL和鍵值數(shù)據(jù)庫(kù)的數(shù)據(jù)模型轉(zhuǎn)換還沒有較為成熟的開源方案。

1 關(guān)系型數(shù)據(jù)庫(kù)內(nèi)存化架構(gòu)

在本文內(nèi)存化方案中，MySQL僅用作數(shù)據(jù)源使用，Redis 用于請(qǐng)求訪問(wèn)，首先在數(shù)據(jù)庫(kù)層通過(guò)數(shù)據(jù)初始化模塊初始化Redis中的數(shù)據(jù)。請(qǐng)求通過(guò)訪問(wèn)層訪問(wèn)數(shù)據(jù)層Redis中的數(shù)據(jù)，同時(shí)為了確保數(shù)據(jù)安全，按備份策略調(diào)用備份模塊將Redis 中的數(shù)據(jù)備份到MySQL 中。本文的研究工作重點(diǎn)為數(shù)據(jù)初始化模塊。方案的難點(diǎn)在于MySQL中的熱點(diǎn)數(shù)據(jù)如何遷移到Redis中[13]，并保證數(shù)據(jù)的高效存儲(chǔ)和訪問(wèn)。MySQL數(shù)據(jù)庫(kù)內(nèi)存化架構(gòu)如圖1所示。

圖1 MySQL數(shù)據(jù)庫(kù)內(nèi)存化架構(gòu)Fig.1 MySQL database in-mesmory architecture

2 存儲(chǔ)模型轉(zhuǎn)換流程

內(nèi)存化方案模型轉(zhuǎn)換原型架構(gòu)如圖2 所示。首先通過(guò)MySQL 驅(qū)動(dòng)與MySQL 交互獲取MySQL 中元數(shù)據(jù)MetaData和數(shù)據(jù)Data，然后構(gòu)建存儲(chǔ)模型轉(zhuǎn)換模型，最后以模型轉(zhuǎn)換的結(jié)果為基礎(chǔ)，通過(guò)Java Redis驅(qū)動(dòng)與Redis 服務(wù)器連接實(shí)現(xiàn)自動(dòng)化數(shù)據(jù)遷移[14]。其中，模型轉(zhuǎn)換核心分為MySQL Schema解析和創(chuàng)建Redis Schema，難點(diǎn)在于模型轉(zhuǎn)換，即如何構(gòu)建模型實(shí)現(xiàn)異構(gòu)數(shù)據(jù)庫(kù)存儲(chǔ)模型的轉(zhuǎn)換[15-16]。本文綜合Redis Hash 結(jié)構(gòu)的優(yōu)勢(shì)，構(gòu)建行式鍵值和分段列式交叉鍵值模型實(shí)現(xiàn)存儲(chǔ)模型轉(zhuǎn)換。

圖2 模型轉(zhuǎn)換原型架構(gòu)Fig.2 Prototype architecture of model transformation

3 行式鍵值模型

3.1 模型構(gòu)建流程

行式鍵值模型的核心是將原MySQL庫(kù)表中的每行數(shù)據(jù)轉(zhuǎn)變?yōu)镽edis中的一個(gè)Hash結(jié)構(gòu)。其中key由唯一序列、庫(kù)名、數(shù)據(jù)表名、主鍵名構(gòu)成，唯一序列用于區(qū)分同一個(gè)數(shù)據(jù)表中的不同數(shù)據(jù)行，確保Hash結(jié)構(gòu)中key的唯一性，field為行數(shù)據(jù)的列，value為對(duì)應(yīng)列的值。行式鍵值模型流程如圖3，具體核心步驟如下：

圖3 構(gòu)建行式鍵值模型流程圖Fig.3 Flow diagram of building RB-KVM

3.2 模型構(gòu)建算法

3.2.1 構(gòu)建key

在Redis中，數(shù)據(jù)按照鍵值對(duì)的形式進(jìn)行組織、索引和存儲(chǔ)。利用key去定位value是一個(gè)復(fù)雜度為O(1)的操作，為了保證查詢效率，本文的key 采用String 類型，key由唯一序列、庫(kù)名、數(shù)據(jù)表名、主鍵名構(gòu)成；唯一序列是為了區(qū)分原MySQL 表中的不同記錄，主鍵名用作后期研究不同的數(shù)據(jù)進(jìn)行關(guān)聯(lián)或者查詢的關(guān)鍵樞紐。唯一序列全局唯一，在數(shù)據(jù)遷移過(guò)程中將生成唯一序列號(hào)。key的構(gòu)建原理如圖4所示。

圖4 行式鍵值模型key構(gòu)建原理Fig.4 Key construction principle of RB-KVM

key的構(gòu)建流程描述如下：

（1）定義MySQL 中數(shù)據(jù)庫(kù)名稱DB，利用（1）中的Ti方法在DB中的所有表中選擇任意i∈(count(Tai))表Tai；

（2）若Tai中主鍵PK存在，通過(guò)式（2）中的Pi方法獲取到Tai中的主鍵PKx，否則PKx的值為默認(rèn)值dpk。

（4）利用（3）中的結(jié)果和唯一序列r，通過(guò)M方法得到Ki，其中Ki原MySQL每行數(shù)據(jù)對(duì)應(yīng)到Redis的key-value結(jié)構(gòu)中的key，如公式（4）。

3.2.2 構(gòu)建Field和Value

RB-KVM 的field 為MySQL 行存儲(chǔ)中每行記錄的字段名，value 為字段對(duì)應(yīng)的值，如圖5 所示，在users 表中的userid 列值為“001”的行數(shù)據(jù)遷移到Redis 中構(gòu)建一個(gè)Hash，其中Hash 中的key(K1)是利用3.2.1 小節(jié)中構(gòu)建key 的結(jié)果，Hash 中的field 和value 由原行的所有的列名和值對(duì)應(yīng)構(gòu)成，例如：列“userid”和對(duì)應(yīng)值“001”轉(zhuǎn)換為field 為“userid”，value 為“001”的數(shù)據(jù)。進(jìn)行數(shù)據(jù)遷移時(shí)，為降低內(nèi)存占用率，本文在構(gòu)建存儲(chǔ)轉(zhuǎn)換模型時(shí)，MySQL表中的null值將不被存儲(chǔ)。

圖5 行式鍵值模型field和value構(gòu)建原理Fig.5 Field and value construction principle of RB-KVM

4 分段列式鍵值交叉模型

4.1 模型構(gòu)建流程

結(jié)合列式存儲(chǔ)對(duì)必要列進(jìn)行查詢的優(yōu)點(diǎn)，本節(jié)基于Redis 的Hash 結(jié)構(gòu)，提出構(gòu)建分段列式鍵值交叉模型。其核心思想是將原MySQL庫(kù)表中的每個(gè)表中數(shù)據(jù)轉(zhuǎn)變?yōu)镽edis 中的一個(gè)Hash 結(jié)構(gòu)。其中Hash 中的key 標(biāo)識(shí)表，field值為表中的所有列，每個(gè)field對(duì)應(yīng)的value值為列filed的所有數(shù)據(jù)。但因?yàn)閿?shù)據(jù)較多時(shí)，列式存儲(chǔ)會(huì)造成Redis 中大value 的情況，會(huì)嚴(yán)重影響Redis 的性能。本方案在key中加入分段信息，通過(guò)分段策略將該表分為多個(gè)Hash存儲(chǔ)，拆分大value，保證Redis的性能。

模型構(gòu)建流程與3.1 節(jié)中一致，不同體現(xiàn)在模型構(gòu)建算法不同，具體算法參考4.2節(jié)。

4.2 模型構(gòu)建算法

4.2.1 構(gòu)建key

分段列式鍵值交叉模型中key 的構(gòu)建流程與行式鍵值模型中key的構(gòu)建流程類似，這里不再贅述。不同點(diǎn)在于當(dāng)表中的數(shù)據(jù)量N超過(guò)閾值T，可以自定義分段值T，將表中的數(shù)據(jù)分段存儲(chǔ)為個(gè)Hash，以此拆分大value。其中每個(gè)Hash的key中將每次分段的開始行s和分段結(jié)束行e作為前綴，如公式（5）所示。key中的表名和分段值可以區(qū)別不同的表的數(shù)據(jù)和同表但不同段的數(shù)據(jù)，因此分段列式鍵值交叉模型的key中不需要唯一序列。

啟示：這句諺語(yǔ)告訴我們，人生的道路并不是暢通無(wú)阻的，要坦然面對(duì)阻礙和困境，事到臨頭，必定會(huì)有解決的辦法。但辦法不會(huì)自己出現(xiàn)，還需要我們開動(dòng)腦筋，主動(dòng)思考：遇到山，要會(huì)迂回前進(jìn)，尋找出路；遇到水，要會(huì)積極應(yīng)變，尋找渡水的手段，這樣才能達(dá)到既定的目標(biāo)。

4.2.2 構(gòu)建field和value

在分段列式鍵值交叉模型中，Hash 中的一個(gè)field存儲(chǔ)表中的一個(gè)字段名，每個(gè)field 對(duì)應(yīng)的value 值即為表中某列的所有值的set 集合，為保證每個(gè)列值保持與原行的聯(lián)系，將每個(gè)列數(shù)據(jù)與對(duì)應(yīng)行的主鍵值綁定作為Set 中的元素；這種方案仍然需要一定量的內(nèi)存開銷。在列式存儲(chǔ)模型中同一個(gè)表的字段，若不考慮分段，則只存儲(chǔ)一次；相較于在行式存儲(chǔ)模型中，若原表中有n條記錄，每個(gè)字段將會(huì)被記錄n次，降低了內(nèi)存開銷。field和value的構(gòu)建原理如圖6所示。

圖6 列式數(shù)據(jù)模型構(gòu)建原理Fig.6 Construction principle of PCB-KVM

定義Tbi，數(shù)據(jù)行rt(t∈count(row))，字段列ck(k∈count(col))，數(shù)據(jù)值為v(t,k)；定義表示行rt，即MySQL每行中的主鍵值；定義vtk表示ck列對(duì)應(yīng)的所有數(shù)據(jù)。ck即field，vtk為value，其vtk的構(gòu)建核心步驟如下：

vtk分為當(dāng)前列是主鍵(ck∈pk)和非主鍵(ck?pk)兩種情況。當(dāng)ck∈pk，聚合ck列對(duì)應(yīng)的所有值的集合；當(dāng)(ck?pk)，需要先通過(guò)F函數(shù)融合當(dāng)前列ck與當(dāng)前行主鍵值得到T(t,k)，對(duì)行非主鍵列的值綁定對(duì)應(yīng)行主鍵值。

5 實(shí)驗(yàn)對(duì)比與分析

5.1 物理環(huán)境

本文測(cè)試服務(wù)器系統(tǒng)為Centos5.2，配置源數(shù)據(jù)庫(kù)MySQL 和目的數(shù)據(jù)庫(kù)Redis，其中分布式Redis cluster包括6個(gè)節(jié)點(diǎn)。關(guān)鍵配置如下：

（1）配置6臺(tái)Redis集群服務(wù)器，端口分別為：8001、8002、8003、8004、8005、8006。啟動(dòng)Redis集群。

（2）配置MySQL 數(shù)據(jù)庫(kù)和Redis cluster 集群的連接信息。

5.2 模型對(duì)比與分析

5.2.1 數(shù)據(jù)遷移結(jié)果

將MySQL 的jlabordispatch 庫(kù)（以u(píng)sers 表為例，如圖7）中的100 000 數(shù)據(jù)遷移到Redis 集群中。采用行式鍵值模型遷移后的效果如表1所示，以10 000分段采用分段列式鍵值交叉模型遷移后的效果如表2所示。

表1 RB-KVM數(shù)據(jù)遷移結(jié)果Table 1 Data migration results of RB-KVM

表2 PCB-KVCM數(shù)據(jù)遷移結(jié)果Table 2 Data migration results of PCB-KVCM

圖7 用戶表中部分?jǐn)?shù)據(jù)Fig.7 Partial data of user table

5.2.2 模型分析與結(jié)果對(duì)比

針對(duì)數(shù)據(jù)遷移過(guò)程，若采用行式鍵值模型，需要先獲取MySQL 中需要遷移數(shù)據(jù)的表結(jié)構(gòu)的元信息，再批量獲取同一個(gè)表中的數(shù)據(jù)得到結(jié)果集R，其中包含N條數(shù)據(jù)，對(duì)數(shù)據(jù)進(jìn)行預(yù)處理（主要包括null的預(yù)處理）過(guò)程中，需要對(duì)結(jié)果集R中數(shù)據(jù)逐條處理并存儲(chǔ)結(jié)果，則要額外申請(qǐng)結(jié)果集R的長(zhǎng)度個(gè)空間，其空間復(fù)雜度為O(n)；在進(jìn)行null的預(yù)處理時(shí)，需要遍歷處理R中的所有數(shù)據(jù)，時(shí)間復(fù)雜度為O(n)，空間復(fù)雜度為O(n)，采用多線程處理后（設(shè)定為x個(gè)線程），時(shí)間復(fù)雜度為，空間復(fù)雜度為O(n)；預(yù)處理后的數(shù)據(jù)，進(jìn)行二次構(gòu)建形成新的適合Redis的數(shù)據(jù)結(jié)構(gòu)，并遷移到Redis中，其空間復(fù)雜度為O(1) 。

分段列式鍵值模型的處理流程、處理流程與行式鍵值模型基本一致，數(shù)據(jù)預(yù)處理開銷也一致，只是在構(gòu)建部分的具體構(gòu)建方式不同，主要體現(xiàn)在：當(dāng)數(shù)據(jù)讀取結(jié)果集為R，共有N條數(shù)據(jù)，需要遍歷處理R中的所有字段，時(shí)間復(fù)雜度為O(n2)，空間復(fù)雜度為O(n)，其中N為結(jié)果集R中元素個(gè)數(shù)，采用多線程處理后（設(shè)定為x個(gè)線程），空間復(fù)雜度與原來(lái)一致，時(shí)間復(fù)雜度為O(n2/x)。

RB-KVM 基于最簡(jiǎn)單的Hash 結(jié)構(gòu)，數(shù)據(jù)添加（一般情況）、刪除、修改、讀取的平均時(shí)間復(fù)雜度都為O(1) 。在PCB-KVCM 中，每個(gè)field 對(duì)應(yīng)的value 是一個(gè)HashSet集合，對(duì)于新增、刪除和contains，平均時(shí)間復(fù)雜度為O(1) 。

大數(shù)據(jù)環(huán)境下，數(shù)據(jù)庫(kù)Redis 的性能主要體現(xiàn)在對(duì)海量數(shù)據(jù)的存取效率上，兩種模型保存數(shù)據(jù)到Redis 平均時(shí)間復(fù)雜度都為O(1) 。但在PCB-KVCM中，獲取具體的數(shù)據(jù)之前可以先判斷元素是否存在，存在再對(duì)HashSet進(jìn)行迭代取值，其中迭代的時(shí)間與實(shí)際HashSet的size和HashSet中的capacity之和呈線性關(guān)系，其取數(shù)據(jù)效率低于RB-KVM。

本節(jié)對(duì)MySQL數(shù)據(jù)庫(kù)中表（以u(píng)sers為例，見圖7），對(duì)users表中不同數(shù)量級(jí)（1 000，10 000，100 000，1 000 000）的數(shù)據(jù)分別利用兩種模型完成數(shù)據(jù)遷移，經(jīng)多次測(cè)試后，數(shù)據(jù)占用內(nèi)存如圖8所示。其中分段列式鍵值交叉模型中分段采用10 000分段。

圖8 不同模型數(shù)據(jù)遷移內(nèi)存占用結(jié)果Fig.8 Data migration memory usage results of different models

為了減少數(shù)據(jù)遷移過(guò)程中與Redis 交互次數(shù)，提升數(shù)據(jù)遷移的性能。本文利用Redis 的批量操作方法，以10 000 批量為例，進(jìn)行批量操作，數(shù)據(jù)遷移時(shí)間對(duì)比如圖9所示。

圖9 數(shù)據(jù)遷移時(shí)間對(duì)比Fig.9 Time usage comparison of data migration

對(duì)比不同數(shù)量級(jí)下的運(yùn)用兩種模型進(jìn)行數(shù)據(jù)遷移內(nèi)存占用結(jié)果，有以下結(jié)論：

（1）橫向?qū)Ρ炔煌瑪?shù)量級(jí)的數(shù)據(jù)采用相同的模型算法進(jìn)行數(shù)據(jù)遷移，內(nèi)存占用都隨著數(shù)據(jù)的增多而升高。

（2）縱向?qū)Ρ认嗤瑪?shù)量級(jí)的數(shù)據(jù)采用不同的模型算法進(jìn)行數(shù)據(jù)遷移，隨著數(shù)據(jù)量的上升，行式鍵值交叉模型是分段列式鍵值交叉模型內(nèi)存占用的2倍。

特別地，以10 000 條數(shù)據(jù)量為例批量進(jìn)行數(shù)據(jù)遷移，對(duì)比運(yùn)用兩種模型進(jìn)行數(shù)據(jù)遷移的時(shí)間開銷，隨著數(shù)據(jù)量的上升，分段列式鍵值交叉模型遷移時(shí)間開銷基本為常數(shù)，而行式鍵值交叉模型遷移時(shí)間明顯低于分段式模型。

6 結(jié)論

兩種模型都可以實(shí)現(xiàn)關(guān)系型數(shù)據(jù)庫(kù)（以MySQL 為例）到Redis的數(shù)據(jù)遷移，從而解決大數(shù)據(jù)環(huán)境下海量熱點(diǎn)數(shù)據(jù)的高效存取。大數(shù)據(jù)環(huán)境下，數(shù)據(jù)庫(kù)Redis 的性能主要體現(xiàn)在對(duì)海量數(shù)據(jù)的存取效率上，兩種模型下存數(shù)據(jù)平均時(shí)間復(fù)雜度都為O(1)，一般情況下，RB-KVM取數(shù)據(jù)的效率更高，但PCB-KVCM 具有更高的內(nèi)存利用率（接近兩倍）；在數(shù)據(jù)遷移時(shí)間方面，分段列式鍵值交叉模型的數(shù)據(jù)遷移時(shí)間較行式鍵值交叉模型，隨著數(shù)據(jù)量的增大，遷移時(shí)間優(yōu)勢(shì)越明顯。