林大杰 董 瑩 顏嘉俊 李昀蓁

（1.逢甲大學運輸科技與管理學系 臺灣臺中40724；2.逢甲大學資訊工程學系 臺灣臺中40724）

0 引 言

近年來，隨著經濟的發(fā)展，私人運具不斷普及，政府大力推行大眾運輸，先進大眾運輸系統(tǒng)（advanced public transport systems，APTS）成為新的焦點話題。而公交動態(tài)信息系統(tǒng)作為其中重要的一環(huán)其關鍵性不言而喻。

隨著大眾運輸基礎建設不斷完善，如今公交路線、車輛的數(shù)量已頗為可觀，造成了公交動態(tài)信息系統(tǒng)需儲存、處理大量數(shù)據的巨大壓力。由于信息需求量越來越大，對公交動態(tài)系統(tǒng)而言，系統(tǒng)的負載也越來越重。為了滿足民眾之需求，系統(tǒng)也需要隨著科技而改變進化。

傳統(tǒng)的關系型數(shù)據庫系統(tǒng)已逐漸不能滿足處理巨量數(shù)據的需求，而與此同時，NoSQL數(shù)據庫的興起引起了各界的關注。因其能夠處理超巨量數(shù)據的特性，NoSQL數(shù)據庫成為了1個極其熱門的新領域，其產品的發(fā)展也非常迅速。筆者在文中探討了2種數(shù)據庫在數(shù)據介接方面的效能優(yōu)劣。

1 數(shù)據庫

數(shù)據庫即1群有關聯(lián)、有組織數(shù)據的集合，以不重復的方式儲存，使用者可透過數(shù)據庫管理系統(tǒng)（database management system，DBMS）進行檢索、排序、計算、組織、查詢等方式，有效轉換成有用的信息。Rick Cattell［1］按照數(shù)據儲存方式之不同，將數(shù)據庫區(qū)分為 Key-value Stores，Document Stores，Extensible Record Stores，以及relation databases。隨著數(shù)據處理模式的演進，數(shù)據結構不斷發(fā)展，按照時間發(fā)展的順序可分為：階層式數(shù)據庫（hierarchical database）、網狀式數(shù)據庫（network database）、關系型數(shù)據庫（relational database），以及面向對象式數(shù)據庫（object-oriented database）、對象關系型數(shù)據庫（object-relational database）［2］。

關系型數(shù)據庫是目前最重要的、應用最廣泛的1種數(shù)據庫模型，采用關系型模型作為數(shù)據的組織方式［3］。關系型數(shù)據庫系統(tǒng)的典型代表有Oracle，IBM的DB2，微軟的 MS SQL Server，以及Informix，ADABASD等。關系型數(shù)據庫為了確保數(shù)據之完整性及正確性，會依照不同的分類而儲存在數(shù)個表格之中，再利用字段之間的參考來建立表格之間的關聯(lián)。每個表格都可以各自進行數(shù)據的新增、修改、查詢和刪除，也可以使用關聯(lián)性在數(shù)個表格中取得所要查詢的數(shù)據。而若要描述對象與對象之間的復雜關系，則必須外建立1個表格來做處理。而且當數(shù)據量越來越多時，必須額外新建更多的表格才足以應付需求。如此，關連式數(shù)據庫無法記錄越來越復雜的數(shù)據結構。而且當系統(tǒng)數(shù)據量越來越大時，透過主鍵（primary key）以及外鍵（foreign key）來查詢與處理數(shù)據，其執(zhí)行效率會大大降低。

非關系型數(shù)據庫（NoSQL），即不同于傳統(tǒng)關系型數(shù)據庫的數(shù)據庫管理系統(tǒng)的統(tǒng)稱。隨著Web2.0時代的興起，傳統(tǒng)的關系型數(shù)據庫在處理超大規(guī)模和高并發(fā)的SNS類型Web2.0純動態(tài)網站時暴露了許多難以克服問題。致力于處理巨量數(shù)據的非關系型數(shù)據庫應運而生。Eric Evans［4］提出了NoSQL的概念，NoSQL主要指非關系型、分布式、不提供ACID的數(shù)據庫設計模式。非關系型數(shù)據庫強調Key-Value Stores和文文件數(shù)據庫的優(yōu)點，并具有極佳的可擴充性。IBM，MICROSOFT，F(xiàn)ACEBOOK以及YAHOO GOOGLE等各大廠商紛紛提出云端架構來儲存巨量數(shù)據以及對巨量數(shù)據進行加值運算?，F(xiàn)有產品包括Cassandra，MongoDB，HBase與Hadoop［5－7］，等等。

總的來說，關系型數(shù)據庫優(yōu)勢在于發(fā)展多年，各種優(yōu)化工作已經做得很深，便于對數(shù)據進行交叉分析，而其劣勢在于可擴充性較差，面臨巨量數(shù)據時，效能較差；非關系型數(shù)據庫的優(yōu)勢在于可擴充性佳，讀寫快速，成本較低；其劣勢也很明顯，未形成一定的標準，支持的特性不夠豐富，提供功能比較有限，各種產品層出不窮，內部混亂，現(xiàn)有產品不夠成熟，還需時間的檢驗。

2 公交數(shù)據交換技術

目前，臺灣已逐漸發(fā)展以XML技術架構為基礎的數(shù)據交換模式，多用于旅行者信息之發(fā)布。

圖1 公交數(shù)據交換流程示意Fig1 Bus data exchange process indicate

公交上設備GPRS Modern將實時行車數(shù)據（包括定時數(shù)據A1，定點數(shù)據A2）透過GPRS基地臺傳送到地區(qū)公交數(shù)據中心，數(shù)據中心再藉由網絡將數(shù)據傳送給公交動態(tài)信息系統(tǒng)，于公交動態(tài)信息系統(tǒng)之數(shù)據庫服務器進行數(shù)據的新增、更新、查詢、刪除。

XML可用來標記數(shù)據、定義數(shù)據類型，是1種允許用戶對自己的標示語言進行定義的源語言，具有彈性結構、容易產生、閱讀及傳送的優(yōu)勢，適于網絡傳輸見圖2。其XML包含3部分，分別為檔宣告（prolog）、根 元 素 （rootelement）以 及 子 元 素 （element）。

范例如下。

圖2 XML數(shù)據結構示意圖Fig2 XML data structure

第1行為文件宣告，「＜BusDynInfo＞，＜／Bus-DynInfo＞」即為根元素，「＜BusInfo＞，＜／BusInfo＞」為子元素。

3 數(shù)據庫測試

3.1 測試設計

現(xiàn)有關系型數(shù)據庫以及非關系型數(shù)據庫并無統(tǒng)一的測試標準與工具，因此本文將參考相關操作書籍［8－11］並盡量仿真數(shù)據庫于公交動態(tài)信息系統(tǒng)中介接數(shù)據之模式，對SQL Server和MongoDB進行統(tǒng)一測試。就應用端而言，數(shù)據介接涉及數(shù)據庫的2個方面，分別為Insert，用戶插入新的數(shù)據，及Update，當用戶編輯或修改數(shù)據庫之數(shù)據。

筆者采用公交的實際數(shù)據作為數(shù)據庫測試數(shù)據，以SQL Server作為關系型數(shù)據庫之代表，以MongoDB作為非關系型數(shù)據庫之代表，從使用者應用端的角度出發(fā)，主要測試2種數(shù)據庫之數(shù)據介接操作的性能：分為數(shù)據庫中有少量數(shù)據以及有大量數(shù)據的情況下，對數(shù)據庫做插入與更新數(shù)據動作，期間測試數(shù)據庫之運行時間，以此作為衡量兩者的標準，分析兩種數(shù)據庫之效能。

本文采取之軟件規(guī)格：SQL Server 2012；MongoDB，版本2.4.6，以及編程軟件 Microsoft Visual C＃2010Express。測試環(huán)境如下：Windows版本，Windows Server 2008R2Enterprise；處理器，Intel（R）Xeon（R）CPU E5-2620 0＠2.00GHz 2.00GHz（2處理器）；內存24.0GB；系統(tǒng)類型，64-bit操作系統(tǒng)。

3.2 測試結果分析

數(shù)據庫內10萬筆數(shù)據量的情況下，插入并更新1，1 000，5 000，10 000，20 000，30 000，40 000，50 000筆數(shù)據，運行時間。

數(shù)據庫內千萬筆數(shù)據量的情況下，插入并更新1，1 000，5 000，10 000，20 000，30 000，40 000，50 000筆數(shù)據，運行時間。

匯總見表1、表2及圖3、圖4。

表1 數(shù)據庫內不同數(shù)據量情況下插入數(shù)據運行時間Tab.1 Running time of insert data under different circumstances of database within different amounts of data

表2 數(shù)據庫內不同數(shù)據量情況下更新數(shù)據運行時間Tab.2 Running time of update data under different circumstances of database within different amounts of data

圖3 不同數(shù)據量插入不同筆數(shù)據運行時間Fig3 Running time of insert different amounts of data under different circumstances of database

圖4 不同數(shù)據量更新不同筆數(shù)據運行時間Fig4 Running time of update different amounts of data under different circumstances of database

由此可以看出，2種數(shù)據庫都隨著插入筆數(shù)的增加，其運行時間也在增加；數(shù)據庫小量數(shù)據的情況下，MongoDB之Insert效能較佳；而千萬筆數(shù)據量基礎上，即大量數(shù)據的情況下，也是MongoDB之Insert效能有較為顯著的優(yōu)勢；也就是說，數(shù)據庫內數(shù)據量越大，則MongoDB在insert方面的優(yōu)勢越明顯。

2種數(shù)據庫之更新筆數(shù)則情況有所不同，隨著執(zhí)行筆數(shù)的增加，運行時間有增加的趨勢，且在數(shù)據庫小量數(shù)據的情況下，SQL Server之update效能較佳，而千萬筆數(shù)據量基礎上，則MongoDB效能有較為明顯的優(yōu)勢，即就update而言，MongoDB在數(shù)據量較大的情況下，具有較佳的效能。

取更新10萬到100萬筆數(shù)據量的情況，比較數(shù)據庫更新10 000筆數(shù)據的運行時間的變化：

表3 數(shù)據庫內不同數(shù)據量情況下更新10 000筆數(shù)據運行時間Tab.3 Running time of update 10 000data under circumstances of database within different amounts of data

圖5 不同數(shù)據量更新10 000筆數(shù)據運行時間Fig4 Running time of update 10 000data under different circumstances of database

由圖5可見，MongoDB更新運行時間隨著數(shù)據庫內數(shù)據量增加，變化并不明顯，而SQL Server隨著數(shù)據庫內數(shù)據量增加，其運行時間不斷增大，二者差距愈加明顯。故可以得出update在小數(shù)據量的情況下SQL Server具有一定優(yōu)勢，但隨著數(shù)據增加，MongoDB的效能會慢慢超越，并且越來越明顯。

4 結束語

當數(shù)據庫內數(shù)據量較少時，insert方面，MongoDB具有優(yōu)勢，而update方面則是SQL Server具有優(yōu)勢，但由于數(shù)據量少，數(shù)據庫運行時間較小，所以各自的優(yōu)勢均并不明顯。

隨著數(shù)據庫內數(shù)據量的增加，MongoDB的優(yōu)勢越來越大，千萬數(shù)量級數(shù)據量情況下，MongoDB具顯著優(yōu)勢。

Update于60萬筆數(shù)據量左右，MongoDB開始反超SQL Server，且也是隨著數(shù)據量的增加，優(yōu)勢越來越明顯，在千萬數(shù)量級數(shù)據量基礎上，MongoDB具有顯著的優(yōu)勢。當然，其臨界值并不一定，而是受實際外在環(huán)境的影響，如硬件環(huán)境等。本文僅探討2種數(shù)據庫的效能特點，變化趨勢。

本文從數(shù)據庫數(shù)據介接所涉及的兩個基本操作insert以及update，驗證非關系型數(shù)據庫較關系型數(shù)據之優(yōu)勢，且其優(yōu)勢會隨著數(shù)據量的增加而增大。

非關系型數(shù)據庫MongoDB，在介接數(shù)據的時候，其運行時間并不會隨著數(shù)據量的增加而大幅增加，這個特性不同于關系型數(shù)據庫SQL Server。

公交動態(tài)信息系統(tǒng)之應用層面上，介接公交數(shù)據中心之大量數(shù)據時，可使用非關系型數(shù)據庫，以達節(jié)省時間，提高系統(tǒng)效能的目的。

［1］ CATTELL R.Scalable SQL and NoSQL data stores［J］.SIGMOD Rec.，2011，（39）：12-27.

［2］ 曾守正.數(shù)據庫系統(tǒng)的回顧與未來研究發(fā)展［D］.桃園：元智大學，1996.ZENG Shouzheng.Review and research development of the database system［D］.Taoyuan：Yuan Ze University，1996.（in Chinese）

［3］ CODD E F.A relational model for large shared data banks［J］.Communications of the ACM，1983（26）：64-69.

［4］ LITH A.MATTSSON J.Investigating storage solutions for large data：A comparison of well performing and scalable data storage solutions for real time extraction and batch insertion of data［D］.G¨oteborg，Sweden：Chalmers University of Technology，2010.

［5］ HUSOO A.SARMA J S，JAIN N，et al，Hive-a petabyte scale data warehouse using Hadoop［C］.Proceedings of the 2010IEEE 26th International Conference on Data Engineering，Anchorage，Alaska：IEEE，2010：996-1005.

［6］ QIU Zhi，LIN Zhaowen，MA Yan.Research of Hadoop-based data flow management system［J］.Science Direct，2011（18）：164-168.

［7］ Kun Liua，Long－jiang Dong.Research on cloud data storage technology and its［J］.Procedia Engineering，2012（29）：133-137.

［8］ 陳春旭，余明興，李建全，譯.數(shù)據庫系統(tǒng)概論［M］.臺北：儒林，1986.CHEN Chunxu，YU Mingxing，LI Jianguan Trans-lated.Database system generality［M］.Taipei：Scholars Books Co.，Ltd，1986.（in Chinese）

［9］ 曾守正.數(shù)據庫系統(tǒng)之理論與實務［M］.臺北：華泰，2007.ZENG Shouzheng.Database Systems Theory and Practice［M］.Taipei：Hwa Tai Publishing Co.，Ltd，2007.（in Chinese）

［10］ 李春雄.數(shù)據庫系統(tǒng)理論：使用 SQL Server 2008實作［M］.臺北：全華，2012.LI Chunxiong.Database systems theory：the use of sql server 2008［M］.Taipei：Chuan Hwa Book Co.，Ltd，2012.（in Chinese）

［11］ 李紹綸.數(shù)據庫系統(tǒng)理論：使用 SQL Server 2012［M］.臺北：上奇信息，2013.LI Shaolun.Database systems theory：the use of sql server 2012［M］.Taipei：GrandTech Information Co.，Ltd.，2013.（in Chinese）