MongoDB在期刊數(shù)據(jù)庫(kù)日志管理應(yīng)用的探析
——以上海圖書館《全國(guó)報(bào)刊索引》全文庫(kù)為例

王靜

（上海圖書館，上海 200031）

0 引言

圖書館電子文獻(xiàn)數(shù)據(jù)庫(kù)每天都有很多用戶訪問和下載文獻(xiàn)，后臺(tái)記錄用戶信息、行為的日志信息大量增長(zhǎng)，并發(fā)量也急劇增大。本文以上海圖書館《全國(guó)報(bào)刊索引》平臺(tái)為例，為全文數(shù)據(jù)庫(kù)系統(tǒng)的日志管理提供一種解決方案。

上海圖書館《全國(guó)報(bào)刊索引》平臺(tái)日志數(shù)據(jù)記錄了用戶信息、登錄信息、全文下載信息和數(shù)據(jù)庫(kù)檢索信息等。平臺(tái)日志數(shù)據(jù)特點(diǎn)：①數(shù)據(jù)量大，機(jī)構(gòu)用戶900多家，個(gè)人用戶近2萬(wàn)人；平均日登錄數(shù)1萬(wàn)多次，日檢索信息70多萬(wàn)條，日全文下載量2萬(wàn)多條，總?cè)罩緮?shù)量級(jí)上億。②數(shù)據(jù)結(jié)構(gòu)松散，不同數(shù)據(jù)調(diào)取和統(tǒng)計(jì)分析，需要提供不同的報(bào)表。③讀寫操作的高并發(fā)性，隨著個(gè)人服務(wù)功能的上線，對(duì)數(shù)據(jù)庫(kù)訪問的并發(fā)性要求也日益增強(qiáng)。④開發(fā)要更加敏捷：開發(fā)周期短，平臺(tái)日志管理系統(tǒng)開發(fā)需在短時(shí)間內(nèi)完成。

傳統(tǒng)使用關(guān)系數(shù)據(jù)庫(kù)，在日志數(shù)據(jù)管理上結(jié)果松散、讀寫效率不高。為了優(yōu)化日志數(shù)據(jù)的存儲(chǔ)，提高報(bào)表效率，逐步建設(shè)開放報(bào)表中心的需求，要建立一個(gè)有效的日志數(shù)據(jù)管理系統(tǒng)。

1 MongoDB簡(jiǎn)介

MongoDB是一個(gè)基于文檔模型的，支持索引、復(fù)制、事務(wù)、分片水平擴(kuò)展的數(shù)據(jù)庫(kù)，非常適用于分析和管理日志。第一，它易擴(kuò)展，靈活的文檔數(shù)據(jù)模型使得處理數(shù)據(jù)更加直觀；第二，它類似于關(guān)系型數(shù)據(jù)庫(kù)，有豐富的數(shù)據(jù)查詢語(yǔ)言，可建立索引和分布式可擴(kuò)展設(shè)計(jì)；第三，它的數(shù)據(jù)以文件形式加載在內(nèi)存中，其插入和查詢效率要優(yōu)于關(guān)系型數(shù)據(jù)庫(kù)。

2 上海圖書館《全國(guó)報(bào)刊索引》平臺(tái)采用MongoDB的原因

《全國(guó)報(bào)刊索引》平臺(tái)日志管理系統(tǒng)實(shí)驗(yàn)調(diào)研了非關(guān)系型數(shù)據(jù)庫(kù)MongoDB和關(guān)系型數(shù)據(jù)庫(kù)MySQL，來確定哪種更為適應(yīng)需求。

2.1 實(shí)驗(yàn)設(shè)計(jì)和結(jié)果分析

2.1.1 測(cè)試目的

因?yàn)槿罩咀钪饕菍懭肱c查詢操作，實(shí)驗(yàn)就關(guān)注日志數(shù)據(jù)存儲(chǔ)記錄越來越多的時(shí)候，其插入和查詢效率將會(huì)受到怎樣的影響。

2.1.2 測(cè)試條件

服務(wù)器，Xeon E5-2630，16 G內(nèi)存，Win2008 64位。MongoDB版本:3.0，無任何優(yōu)化配置，單機(jī)測(cè)試；MySQL版本:5.1.49，無任何優(yōu)化配置，單機(jī)測(cè)試。數(shù)據(jù)庫(kù)接口驅(qū)動(dòng)：Mon?goDB:PyMongo 2.1.1；MySQL:MySQLdb 1.2.3。

2.1.3 測(cè)試方法和結(jié)果

模擬一個(gè)用戶登錄信息的格式數(shù)據(jù)，數(shù)據(jù)庫(kù)中已備有1億條數(shù)據(jù)，在此基礎(chǔ)上向數(shù)據(jù)庫(kù)里插入數(shù)據(jù)。本次測(cè)試，插入數(shù)據(jù)量為1，20，50，100，1000，5000，10000，100000，200000。

插入性能測(cè)試，如圖1所示。

圖1 插入速率數(shù)據(jù)

分析：如圖1所示，MongoDB的批量插入性能要優(yōu)于MySQL，隨著插入數(shù)據(jù)量的增大，兩者的速率差距越大。在插入數(shù)據(jù)量小于10000條時(shí)，兩者速率基本持平。上漲到10000條以上時(shí)，兩者拉開差異，MySQL比MongoDB要慢很多。

查詢功能測(cè)試，如圖2所示。

圖2 查詢速率數(shù)據(jù)

分析：如圖2所示，在讀取的數(shù)據(jù)規(guī)模不大時(shí)，MongoDB和MySQL都能滿足用戶的需求，但在讀取數(shù)據(jù)規(guī)模變大后，MongoDB的查詢性能明顯優(yōu)于MySQL，甚至相差2倍。

查詢穩(wěn)定性測(cè)試，如圖3所示。

圖3 查詢穩(wěn)定性比較

分析：不同數(shù)量級(jí)下面每1000條數(shù)據(jù)查詢的時(shí)間：縱坐標(biāo)是每查詢1000條數(shù)據(jù)所需要的時(shí)間；橫坐標(biāo)是查詢時(shí)數(shù)據(jù)庫(kù)的數(shù)量，分別為1萬(wàn)，10萬(wàn)，20萬(wàn)，50萬(wàn)和100萬(wàn)。MySQL的穩(wěn)定性強(qiáng)于Mon?goDB。

MongoDB穩(wěn)定性雖弱于關(guān)系型數(shù)據(jù)庫(kù)，但隨著數(shù)據(jù)量的增大，MongoDB插入查詢效率更高，且存儲(chǔ)結(jié)構(gòu)靈活。最終選取MongoDB做《全國(guó)報(bào)刊索引》平臺(tái)的日志數(shù)據(jù)管理系統(tǒng)。

3 《全國(guó)報(bào)刊索引》平臺(tái)日志管理系統(tǒng)的設(shè)計(jì)規(guī)劃

《全國(guó)報(bào)刊索引》平臺(tái)日志數(shù)據(jù)庫(kù)結(jié)構(gòu)，如圖4所示。

圖4 報(bào)表結(jié)構(gòu)

幾種類型的表設(shè)計(jì)：

（1）個(gè)人用戶信息表。存儲(chǔ)用戶信息。一對(duì)一關(guān)系，userId作為主鍵。

（2）組織用戶信息表。一個(gè)組織可以包含多個(gè)用戶，一個(gè)用戶只能屬于一個(gè)組織。一對(duì)多的關(guān)系，兩張表，用戶表和組織表，在用戶表中設(shè)計(jì)Orgid字段，通過其關(guān)聯(lián)用戶與組織關(guān)系。

（3）用戶下載報(bào)表。一個(gè)用戶可以下載多個(gè)數(shù)據(jù)庫(kù)的文章，一個(gè)數(shù)據(jù)庫(kù)的文章也可以被多個(gè)用戶下載。多對(duì)多的關(guān)系，采用嵌套的設(shè)計(jì)方案：兩張表，Download表存儲(chǔ)下載該數(shù)據(jù)庫(kù)的所有用戶。User表存儲(chǔ)用戶所有下載的數(shù)據(jù)庫(kù)。

4 《全國(guó)報(bào)刊索引》平臺(tái)應(yīng)用MongoDB日志管理后的成效

4.1 服務(wù)功能改善

日志管理系統(tǒng)建成后，管理員可以查看用戶在網(wǎng)站的任何行為，也可以查看每個(gè)模塊的操作情況，如查詢、新建、刪除、編輯等。系統(tǒng)每月自動(dòng)生成訪問報(bào)表，郵件形式發(fā)送。也可根據(jù)管理員的需要，設(shè)定特定條件，生成報(bào)表。例如本月、上月新增機(jī)構(gòu)用戶數(shù)、總的機(jī)構(gòu)用戶數(shù)，本月機(jī)構(gòu)原文索取金額、個(gè)人原文索取金額等。

4.2 圖形化呈現(xiàn)和分析功能

報(bào)表設(shè)計(jì)了圖形化顯示，更直觀生動(dòng)的體現(xiàn)數(shù)據(jù)趨勢(shì)。管理員分析數(shù)據(jù)時(shí)，一眼就看清新增用戶的增長(zhǎng)趨勢(shì)或是各類用戶的數(shù)據(jù)庫(kù)使用情況。如圖5所示。

圖5 圖形化報(bào)表樣例

5 《全國(guó)報(bào)刊索引》平臺(tái)采用MongoDB日志管理遇到的問題及解決方案

5.1 數(shù)據(jù)量、并發(fā)量增大的問題

運(yùn)行一段時(shí)間后，數(shù)據(jù)量與并發(fā)量快速增長(zhǎng)，對(duì)存儲(chǔ)帶來了一定壓力。雖然MongoDB帶有自動(dòng)分片功能，但目前還沒有太多的數(shù)據(jù)需要分片，所以采用副本集來保證自動(dòng)故障轉(zhuǎn)移。

日志數(shù)據(jù)有一個(gè)明顯的特性，就是隨著時(shí)間的增加，其價(jià)值變得越來越小?；谶@個(gè)特性，日志存儲(chǔ)日益增大的問題，解決方案是按照一定的周期進(jìn)行詳情歸檔，再把具體明細(xì)移到其他地方存儲(chǔ)。

目前是每日歸檔，把用戶的登錄信息按日匯總，縮小數(shù)據(jù)量，提高統(tǒng)計(jì)效率，降低存儲(chǔ)成本。

5.2 Mongo DB的時(shí)間問題

在按日期統(tǒng)計(jì)用戶登錄信息時(shí)，歸檔數(shù)量總與實(shí)際數(shù)量不一致。通過查找資料，發(fā)現(xiàn)可能是MongoDB的“時(shí)差”問題。當(dāng)MongoDB保存到數(shù)據(jù)庫(kù)的時(shí)候，默認(rèn)為UTC時(shí)間（世界標(biāo)準(zhǔn)時(shí)間），北京時(shí)間比UTC時(shí)間早8小時(shí)，即UTC時(shí)間1月21日中午12：00，北京時(shí)間是1月21日20：00。解決方法開始是在RoboMongo通過“Options”-“Display Dates in...”-“Local Timezone”來設(shè)置顯示本地時(shí)間。但在每次讀取的時(shí)，都需要來回進(jìn)行轉(zhuǎn)換，比較麻煩。后來發(fā)現(xiàn)MongoDB本身提供了解決方法：［BsonDateTimeOptions（Kind=DateTimeKind.Local）］public DateTime OperTime{get;set;}。經(jīng)過處理后，歸檔的數(shù)量與實(shí)際數(shù)量終于一致了。

最后結(jié)果如圖6所示。

圖6 MongoDB時(shí)差解決方法

6 結(jié)語(yǔ)

MongoDB性能的各項(xiàng)實(shí)驗(yàn)，它具備的高性能、高擴(kuò)展性、類SQL的豐富查詢和索引等特性，非常適用于上海圖書館《全國(guó)報(bào)刊索引》的后臺(tái)日志管理系統(tǒng)。系統(tǒng)建立后，提高了用戶日志數(shù)據(jù)分析的能力，滿足了業(yè)務(wù)發(fā)展隨時(shí)響應(yīng)的需求，提供了專業(yè)報(bào)表服務(wù)和圖形化呈現(xiàn)。同時(shí)，支持PC端與移動(dòng)端，增強(qiáng)了基于數(shù)據(jù)記錄基礎(chǔ)上的統(tǒng)計(jì)功能，增加詞頻分析功能，完全將讀者的檢索詞形成詞云，保存待進(jìn)一步分析和利用等。

本文通過MongoDB在上海圖書館《全國(guó)報(bào)刊索引》日志管理系統(tǒng)中的應(yīng)用，證明它在文獻(xiàn)數(shù)據(jù)庫(kù)日志管理上的應(yīng)用可顯著提高文獻(xiàn)數(shù)據(jù)庫(kù)日志的管理系統(tǒng)性和查詢效率，而且成本較低。