MongoDB存儲服務方案設計

1、MongoDB存儲服務方案設計2012-03-14目錄1.需求分析31.1 客車平臺和貨運平臺現(xiàn)有需求31.2 現(xiàn)有平臺存儲服務上存在問題52.方案設計72.1 存儲服務方案設計目標72.2 存儲方案設計細則7實時數(shù)據(jù)存儲設計7拍照數(shù)據(jù)存儲設計8歷史數(shù)據(jù)查詢設計9數(shù)據(jù)統(tǒng)計設計10拍照數(shù)據(jù)發(fā)布和查詢設計112.3 存儲服務業(yè)務流程框架設計113.方案部署架構設計123.1 存儲服務（MongoDB）部署架構規(guī)劃設計123.2 存儲服務（MongoDB）數(shù)據(jù)分片規(guī)劃設計143.3 存儲服務（MongoDB）實例部署規(guī)劃設計143.4 存儲服務（MongoDB）服務器硬件、網(wǎng)絡和操作系統(tǒng)規(guī)劃設計15

2、3.5 MongoDB版本規(guī)劃設計163.6 存儲服務（MongoDB）運營監(jiān)控規(guī)劃設計164.方案實施174.1 實施步驟174.2 方案整體實施計劃17附件1: 存儲服務表（MongoDB Collection）結(jié)構設計18附件2: 存儲服務（MongoDB）對外接口統(tǒng)一定義262.1更新類接口262.2 查詢類接口312.3 統(tǒng)計接口39附件3: 存儲服務（MongoDB）安裝部署說明413.1 安裝MongoDB413.2 MongoDB分片配置42分片服務器（sharding）配置42副本集（Replica Set）配置43啟動并配置三臺Config Server43部署并配置三臺R

3、outing Server44命令行添加分片44GPS數(shù)據(jù)存儲服務方案設計1. 需求分析1.1 客車平臺和貨運平臺現(xiàn)有需求1) 實時數(shù)據(jù)文件存儲類a. 實時軌跡數(shù)據(jù)：傳統(tǒng)文件方式存儲，一條軌跡150B，每天上報8640次，一天大約為1M；軌跡文件格式說明：偏移經(jīng)度: 偏移緯度: GPS時間: GPS 速度: 正北方向夾角: 車輛狀態(tài): 報警編碼：經(jīng)度：緯度：海拔：里程：累計油耗：發(fā)動機運行總時長：引擎轉(zhuǎn)速（發(fā)動機轉(zhuǎn)速）：位置基本信息狀態(tài)位：報區(qū)域/線路報警：冷卻液溫度：蓄電池電壓: 瞬時油耗: 行駛記錄儀速度: 機油壓力: 大氣壓力: 發(fā)動機扭矩百分比: 車輛信號狀態(tài):系統(tǒng)時間rn特點：數(shù)據(jù)頻

4、率高，數(shù)據(jù)量大。b. 實時報警數(shù)據(jù)：傳統(tǒng)文件方式存儲，一條報警100B，每天上報8640次，一天大約為800K；報警文件格式說明：報警編碼：偏移經(jīng)度: 偏移緯度：經(jīng)度：緯度：GPS時間: GPS 速度: 正北方向夾角：累計油耗: 里程: 報區(qū)域/線路報警: 海拔：系統(tǒng)時間rn特點：數(shù)據(jù)頻率高，數(shù)據(jù)量大。c. 駕駛行為事件：傳統(tǒng)文件方式存儲，一條駕駛行為事件100B，每天上報不固定，根據(jù)實際生產(chǎn)環(huán)境觀察，平均每天最大300K；特點：數(shù)據(jù)頻率不高，數(shù)據(jù)量小。d. 發(fā)動機負荷率：傳統(tǒng)文件方式存儲，一條發(fā)動機負荷率200B,每天上報360次，一天大約為80K；特點：數(shù)據(jù)頻率不高，數(shù)據(jù)量小。e. 拍照數(shù)

5、據(jù)，圖片文件，每天上報數(shù)據(jù)量不定特點：數(shù)據(jù)頻率不高，數(shù)據(jù)量小。f. 盲區(qū)補傳軌跡文件：軌跡文件統(tǒng)計最大數(shù)，這里不做統(tǒng)計；g. 盲區(qū)補傳報警文件：報警文件統(tǒng)計最大數(shù)，這里不做統(tǒng)計；2) 實時數(shù)據(jù)傳統(tǒng)數(shù)據(jù)庫存儲類Oracle數(shù)據(jù)庫存儲A 存儲非法軌跡位置；B 更新車輛最后位置；C 存儲、更新車輛上下線；D存儲、更新車輛報警；MYSQL數(shù)據(jù)庫存儲A 更新車輛最后位置B存儲、更新車輛報警3）操作指令傳統(tǒng)數(shù)據(jù)庫類Oracle數(shù)據(jù)庫存儲A. 存儲、更新下行指令，建議放在MongoDB中，用 Capped Collection來存放。B. 存儲車輛多媒體事件C. 存儲車輛多媒體信息D. 存儲車輛注

6、冊，建議放在Oracle數(shù)據(jù)庫中。E. 存儲車輛鑒權，建議放在Oracle數(shù)據(jù)庫中，同步到redis中供鑒權服務用。F. 存儲車輛注銷，建議放在Oracle數(shù)據(jù)庫中。G. 存儲車輛事件報告H. 存儲車輛信息點播，建議放在Oracle數(shù)據(jù)庫中。I. 存儲車輛電子運單，建議放在Oracle數(shù)據(jù)庫中。J. 存儲車輛駕駛員信息，建議放在Oracle數(shù)據(jù)庫中，同步到redis，防止二次訪問數(shù)據(jù)庫。K. 存儲車輛行駛記錄儀信息，建議放在Oracle數(shù)據(jù)庫中。L. 存儲、更新車輛調(diào)度信息，建議放在Oracle數(shù)據(jù)庫中。M. 更新車輛照片信息N. 更新終端參數(shù)信息O. 更新路線信息，建議放在Oracle數(shù)據(jù)庫

7、中。P. 更新電子圍欄，建議放在Oracle數(shù)據(jù)庫中。Q. 存儲、更新終端參數(shù)設置，建議放在Oracle數(shù)據(jù)庫中。R. 更新終端版本號，建議放在Oracle數(shù)據(jù)庫中。S. 存儲多媒體數(shù)據(jù)檢索T. 存儲上行透傳信息U. 存儲數(shù)據(jù)壓縮透傳V. 更新提問應答MYSQL數(shù)據(jù)庫存儲：A. 存儲、更新下行指令，建議廢棄MySQL，用redis來替代。B. 存儲車輛多媒體信息，建議廢棄MySQL，用redis來替代。4）歷史數(shù)據(jù)查詢統(tǒng)計類A. 軌跡回放條件：GPS時間（開始時間、接收時間）、VID；B. 區(qū)域查車（當前區(qū)域內(nèi)車輛）條件：車輛類型、車輛速度、是否報警；C. 區(qū)域協(xié)查（歷史區(qū)域內(nèi)車輛）條件：GP

8、S時間；D. 歷史報警條件：類型、狀態(tài)、時間；1.2 現(xiàn)有平臺存儲服務上存在問題1） 盲區(qū)補傳數(shù)據(jù)分離問題；2） 跨多天歷史軌跡查詢的問題；3） 報警數(shù)據(jù)和GPS實時數(shù)據(jù)分離的問題；4） 區(qū)域查車、區(qū)域協(xié)查的準確性和計算效率問題；5） 報警數(shù)據(jù)、CAN總線數(shù)據(jù)統(tǒng)計分析問題，MongoDB提供MapReduce（一個大規(guī)模數(shù)據(jù)并行計算技術，源于google）服務來進行統(tǒng)計分析；6） 拍照數(shù)據(jù)問題（統(tǒng)一管理，方便訪問）；7） 業(yè)務流程、數(shù)據(jù)流程合理性問題；8） 設計質(zhì)量問題，如下：3|165694816606456724140420020120312/172641|1656942366064545

9、24141519920120312/1726429） 集群、負載均衡問題；10） 高可用性問題(在線擴容、故障轉(zhuǎn)移)；11） 運營監(jiān)控問題（存儲實例監(jiān)控）；2. 方案設計2.1 存儲服務方案設計目標利用MongoDB來一體化解決GPS實時數(shù)據(jù)（高并發(fā)）存儲和相關的查詢統(tǒng)計業(yè)務（如歷史軌跡查詢），并解決存儲服務的長期運營的高可用性問題。具體包括：A. 解決GPS實時位置信息存儲問題（高并發(fā)寫、高速查詢、高速統(tǒng)計分析）；B. 解決GPS報警數(shù)據(jù)存儲問題（高并發(fā)寫、高速查詢、統(tǒng)計分析）；C. 解決司機駕駛行為數(shù)據(jù)存儲問題（高并發(fā)寫、高速查詢、統(tǒng)計分析）；D. 解決拍照數(shù)據(jù)存儲問題（高并發(fā)寫、自動發(fā)布

10、、高速查詢）；E. 解決區(qū)域查車、區(qū)域協(xié)查等運算量大的業(yè)務統(tǒng)計問題；F. 解決存儲服務高可用性問題(如負載均衡、線性擴容、故障轉(zhuǎn)移、災備恢復、服務監(jiān)控等)；最終目標：簡化現(xiàn)有平臺業(yè)務流程，減少故障節(jié)點，提高存儲服務的高可用性。2.2 存儲方案設計細則針對GPS實時數(shù)據(jù)存儲，存儲服務提供C/C+客戶端接口，供通信系統(tǒng)調(diào)用，可以直接把GPS數(shù)據(jù)存放在MongoDB中，而調(diào)用者無需關系MongoDB的性能和負載問題。MongoDB采用目前通用的JSON格式，并提供JSON格式的解析和組裝包，支持C/C+、Java、JavaScript、Flex等眾多主流開發(fā)語言，方便平臺各層面來使用。針對Mongo

11、DB的數(shù)據(jù)格式特點，我們把GPS實時數(shù)據(jù)格式定義為標準JSON格式，其定義如下：1） GPS實時數(shù)據(jù)格式定義詳見“附件1“ 和 ”附件2“相關定義。 2） 司機駕駛行為數(shù)據(jù)司機駕駛行為現(xiàn)有平臺的數(shù)據(jù)格式：駕駛行為類型|起始位置緯度起始位置經(jīng)度起始位置高度起始位置速度起始位置方向起始位置時間|結(jié)束位置緯度結(jié)束位置經(jīng)度結(jié)束位置高度結(jié)束位置速度結(jié)束位置方向結(jié)束位置時間。具體數(shù)據(jù)樣例：3|165694816606456724140420020120312/172641|165694236606454524141519920120312/172642。3） 發(fā)動機負荷率數(shù)據(jù)格式：無固定格式（BASE64

12、后得到）具體數(shù)據(jù)：MongoDB數(shù)據(jù)庫格式定義（JSON）"VID" : 311,"TS" : ISODate("2012-02-17T14:22:46.777Z"), "DAT" :“”JSON格式說明：車輛編號（VID）、時間戳（DS）、負荷數(shù)據(jù)（DAT）。 MongoDB提供GridFS特性，用來存儲大文件，如圖片文件和視頻文件。由通信平臺產(chǎn)生的有效拍照圖片，可以連同屬性信息（如車機ID、時間戳、圖片ID、訪問路徑（http）一起直接存儲在MongoDB中，方便前端應用查詢。MongoDB數(shù)據(jù)庫格式定義（JS

13、ON）"VID" : 311,"TS" : ISODate("2012-02-17T14:22:46.777Z"), “FID”: “file1”,“HP”: “”,"DAT" :“00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000”J

14、SON格式說明：車輛編號（VID）、時間戳（DS）、文件名（FID）、發(fā)布路徑（HP）、圖片數(shù)據(jù)（DAT）。GPS數(shù)據(jù)查詢主要包括：實時數(shù)據(jù)查詢和歷史數(shù)據(jù)查詢。為解決海量GPS數(shù)據(jù)查詢的效率和并發(fā)負載問題，在設計時考慮從3各方面來設計和優(yōu)化：1） 創(chuàng)建數(shù)據(jù)索引MongoDB支持對數(shù)據(jù)進行索引，即可在設計之初就設計好索引，也可在運營期間來對數(shù)據(jù)的索引進行調(diào)整，建議在采用前者。針對歷史軌跡數(shù)據(jù)的查詢需求條件：車機ID，起止時間，可以對“VID”、“TS”字段創(chuàng)建索引，來提高GPS歷史軌跡數(shù)據(jù)的查詢效率。針對報警查詢查詢需求：起止時間和報警狀態(tài)，可以對“TS”字段、“VS”字段創(chuàng)建索引。2） 數(shù)據(jù)讀

15、寫分離和負載均衡設計在MongoDB服務部署方案中，我們采用多服務器集群，讀寫分離的部署架構，即通過部署多個寫服務和多個讀服務，來解決GPS數(shù)據(jù)存儲的效率和服務可靠性、可擴展性問題。3） 內(nèi)存數(shù)據(jù)MongoDB為提高數(shù)據(jù)查詢的效率，也采用了內(nèi)存機制，把大量的熱點數(shù)據(jù)放在內(nèi)存中，來提高數(shù)據(jù)查詢的命中率，我們可以利用這個特性來滿足車輛位置查詢的需求。4） GPS數(shù)據(jù)查詢接口設計a.車輛位置查詢接口提供查詢車輛最新位置信息，查詢條件為車輛ID，具體實現(xiàn)主要是通過MongoDB的緩存機制來完成。可提供Java和JavaScript接口，供上層應用調(diào)用。注：此處與實時服務的功能有些重復，建議由實時服務來

16、統(tǒng)一提供。b.歷史軌跡查詢接口設計提供查詢每輛車的歷史軌跡數(shù)據(jù)，查詢條件為：車輛ID、開始時間、結(jié)束時間。返回集應包含去除除Can總線后的數(shù)據(jù)。可提供Java和JavaScript接口，供上層應用調(diào)用。注：查詢返回的數(shù)據(jù)集結(jié)果盡量簡潔，針對每類業(yè)務要求的訪問，不必要的信息要剔除掉，減少網(wǎng)絡壓力、提高查詢效率。c報警數(shù)據(jù)查詢1） 快照功能提供查詢某個區(qū)域內(nèi)、某段時間、都有哪些車輛，查詢條件為。提供查詢某個區(qū)域內(nèi)、某段時間、都有哪些類型的報警車輛。2） 報警統(tǒng)計可以按報警類別來統(tǒng)計某個時間段內(nèi)都有哪些報警車輛。可以統(tǒng)計某輛車在某段時間內(nèi)的報警次數(shù)統(tǒng)計，可按總計、按報警類別來統(tǒng)計。通過MongoDB

17、的插件，與Nginx應用服務代理集成，可以直接把存儲在MongoDB中的數(shù)據(jù)發(fā)布成Http圖片服務，供Web應用層調(diào)用。在具體應用中的業(yè)務流程如下：方案說明：A. 解決圖片文件儲存儲分布的問題，可以利用MongoDB把gps數(shù)據(jù)、圖片數(shù)據(jù)、視頻數(shù)據(jù)等都存儲在一起，方便管理和維護；B. 解決圖片文件便利訪問的問題，如文件的屬性，文件的存儲，文件的訪問路徑都作為一條記錄存儲在MongoDB中，方便上層應用獲??；C. 解決圖片高效訪問的問題，如利用Nginx解決圖片資源并發(fā)訪問的問題，利用Squid/Varnishd緩存服務來解決二次訪問MongoDB的問題；2.3 存儲服務業(yè)務流程框架設計Mong

18、oDB存儲服務提供C+/C#接口、Java接口和JavaScript接口，分別為通訊層、服務層和應用層提供存儲服務。3. 方案部署架構設計3.1 存儲服務（MongoDB）部署架構規(guī)劃設計為保證MongoDB的高可用性（高并發(fā)、高可擴展性、高穩(wěn)定性），我們采用了Replica Set + Sharding部署架構，這是一種可以水平擴展的模式，在數(shù)據(jù)量很大時特給力，實際大規(guī)模應用一般會采用這種架構去構建MongoDB存儲系統(tǒng)。MongoDB存儲服務方案部署架構設計，如下圖所示：MongoDB存儲服務集群架構設計架構圖說明：A. 分片cluster：分別在3臺服務器(見上圖Server-1，Ser

19、ver-3，Server-5)運行一個mongod實例（見上圖mongod shard_11，mongod shard_21，mongod shard_31）。B. 副本集：分別在3臺服務器（見上圖Server-2，Server-4，Server-6）運行一個mongod實例（稱為mongod shard12，mongod shard22，mongod shard32），其中：n Server-2的mongod shard12是Server-2的mongod shard_11的副本。n Server-4的mongod shard22是Server-2的mongod shard_21的副本。n

20、Server-2的mongod shard31是Server-2的mongod shard_31的副本。C. 2臺服務器，每臺服務器（見上圖Server-1、Server-3）運行一個mongod實例，作為2個config，其作用是config雙機熱備。D. 3臺服務器，每臺服務器（見上圖Server-2，Server-4，Server-6）運行一個mongos路由進程，用于客戶端連接。E線性擴展：可以同時增加2臺服務器（見上圖Server-5、Server-6），其一個作為分片，另一個作為分片的副本和路由。備注說明：1）mongod實例 : 用于存儲實際的數(shù)據(jù)塊，實際生產(chǎn)環(huán)境中一個shard

21、 server角色可由幾臺服務器組個一個relica set承擔，防止主機單點故障。2）Config Server存儲分片集群的的元數(shù)據(jù)，其中包括在每個mongod實例的基本信息和塊信息。每個配置服務器所有塊的元數(shù)據(jù)的副本。通過兩次提交來確保在配置服務器信息與塊數(shù)據(jù)的一致性。3）mongos 可以被看作是一個數(shù)據(jù)和請求分發(fā)的中心，使單一的mongod實例組成互相關聯(lián)的集群。當接收客戶端請求， mongos根據(jù)Config Server路由到相應的mongod實例(可能是一組mongod)，處理并返回結(jié)果。mongos 進程沒有持久狀態(tài)，在mongos啟動時和配置服務器建立連接并獲取狀態(tài)，當配置

22、服務器發(fā)生任何變化時，會將之傳播到每個mongos 進程。3.2 存儲服務（MongoDB）數(shù)據(jù)分片規(guī)劃設計1）什么叫分片以及分片的作用？數(shù)據(jù)分割以及在不同機器存儲數(shù)據(jù)的過程稱之為分片。通過在多臺機器上分割數(shù)據(jù)，使得數(shù)據(jù)庫系統(tǒng)能存儲更多的數(shù)據(jù)，和處理更多的負載，在此過程中不需要更多更強大的機器。MongoDB分片的基本概念是分割集群成更小的塊，或是文檔。這些分檔可以分布于很多的shards，這樣每個shard負載總數(shù)據(jù)集得子集。舉個例子，思考一下。當你從集合選擇一個key安裝分片時，并使用key分割數(shù)據(jù)。這個key稱為shard key。假設你有一個聯(lián)系人的集合。如果我們選擇“姓”作為shar

23、d key，那么一個分片可以存儲“姓”以A-F開頭的，下一個分片可以存儲“姓”以G-P開頭的，最后一個分片存儲“姓”以Q-Z開頭的。當你添加和刪除分片時，MongoDB會重新做數(shù)據(jù)的負載，這樣每個分片會獲取一定量的流量和實際量的數(shù)據(jù)。所以在決定什么開始分片呢？考慮一下幾個因素：l 目前的機器的磁盤什么時候用完；l 希望比單一的mongod處理速度更快；l 希望在內(nèi)存中保留更多的數(shù)據(jù)以改善性能；3.3 存儲服務（MongoDB）實例部署規(guī)劃設計由于本方案是：規(guī)劃用4到6臺服務器，多個MongoDB（6個mongod實例、2個config實例、3各mongos實例）實例同時運行在這些服務器上，所以

24、在部署前需要先規(guī)劃好服務器的IP地址、實例的名稱、實例的分布（在那臺服務器上）、實例的端口等，然后再實施。本方案的MongoDB數(shù)據(jù)庫實例部署規(guī)劃如下表所示：主機 IP服務名及端口Server_1=“mongodb01”（內(nèi)網(wǎng)）（外網(wǎng)）mongod shard_11:27017mongod config_1:20000Server_2 = “mongodb02”（內(nèi)網(wǎng)）（外網(wǎng)）mongod shard_12:27018mongos_1:30000Server_3 = “mongodb03”192.168.5.

25、3（內(nèi)網(wǎng)）（外網(wǎng)）mongod shard_21:27017mongod config_2:20000Server_4 =“mongodb04”（內(nèi)網(wǎng)）（外網(wǎng)）mongod shard_22:27018mongos_2:30000Server_5=“mongodb05”（內(nèi)網(wǎng)）（外網(wǎng)）mongod shard_31:27017Server_6=”mongodb06”（內(nèi)網(wǎng)）（外網(wǎng)）mongod shard_32:27018mongos_3:300003.4 存儲服務

26、（MongoDB）服務器硬件、網(wǎng)絡和操作系統(tǒng)規(guī)劃設計1）服務器硬件規(guī)劃要求服務器內(nèi)存：至少16G，32G標配，越大越好。硬盤存儲空間：1T以上，非RAID格式，越大越好。注：不建議用磁盤陣列。服務器CPU：至少4核以上，標配8核，核越多越好CPU。網(wǎng)卡：千兆網(wǎng)卡，雙網(wǎng)卡；2）網(wǎng)絡規(guī)劃要求MongoDB服務器集群在一個獨立的網(wǎng)段內(nèi)。集群服務器用千兆交換機連接。3）操作系統(tǒng)RED HAD Linux 64位企業(yè)版操作系統(tǒng)，支持中文字符編碼。A關閉文件系統(tǒng)/分區(qū)的atime 選項Vi /etc/fstab在對應的分區(qū)項后面添加noatime ,nodiratimeLABEL=/1 / ext3 de

27、faults 1 1LABEL=/data1 /data ext4 defaults,noatime,nodiratime 1 2B.設置文件句柄，目前該配置已經(jīng)集成到啟動腳本中。vi /etc/security/limit.conf* soft nproc 65536* hard nproc 65536* soft nofile 65536* hard nofile 65536C.不要使用large vm page （不要使用大內(nèi)存頁選項）Linux 大內(nèi)存頁參考：D.用dmesg 查看主機的信息。E.linux 文件系統(tǒng)的選擇Mongodb 采用預分配的大文件來存儲數(shù)據(jù),我們推薦:ext3

28、,xfs.F.Linux系統(tǒng)內(nèi)核版本G線程堆棧的尺寸默認的線程堆棧尺寸為10M，調(diào)整為1M，已經(jīng)集成在啟動腳本中。3.5 MongoDB版本規(guī)劃設計注：偶數(shù)的版本是穩(wěn)定版，奇數(shù)是開發(fā)版，。3.6 存儲服務（MongoDB）運營監(jiān)控規(guī)劃設計4. 方案實施4.1 實施步驟1） 方案設計2） 方案評審3） 設計驗證4） 結(jié)論評估5） 上線實施4.2 方案整體實施計劃附件1: 存儲服務表（MongoDB Collection）結(jié)構設計1. GPS實時數(shù)據(jù)存儲集合（表）結(jié)構定義表名：gps_his_infos。作用：用于存儲車機實時上傳GPS數(shù)據(jù)，并供前端應用查詢和統(tǒng)計。具體表結(jié)構信息如下所示：編號字段

29、名稱中文對照別名字段類型是否索引備注1VID車輛IDA整數(shù)是2TSGPS時間B整數(shù)是不包含時區(qū)3LON經(jīng)度C整數(shù)是偏移后的4LAT緯度D整數(shù)是偏移后的5SP速度E整數(shù)6DIR方向F整數(shù)7ALT海拔高度G整數(shù)8VS車輛狀態(tài)G整數(shù)9AC報警編碼H報警編碼子集合9.1S1緊急報警S1整數(shù)9.2S2超速報警S2整數(shù)9.3S3疲勞駕駛S3整數(shù)9.4S4預警S4整數(shù)9.5S5導航模塊故障S5整數(shù)9.6S6導航系統(tǒng)天線未接S6整數(shù)9.7S7導航天線短路S7整數(shù)9.8S8終端主電源欠壓S8整數(shù)9.9S9終端主電源掉電S9整數(shù)9.10S10終端顯示屏故障S10整數(shù)9.11S11語音模塊故障S11整數(shù)9.12S1

30、2攝像頭故障S12整數(shù)9.13S13當天累計駕駛超時S13整數(shù)9.14S14超時停車S14整數(shù)9.15S15進出區(qū)域S15整數(shù)9.16S16進出路線S16整數(shù)9.17S17路線行駛時間不足/過長S17整數(shù)9.18S18路線偏移報警S18整數(shù)9.19S19車輛速度傳感器故障S19整數(shù)9.20S20車輛油量異常S20整數(shù)9.21S21車輛被盜S21整數(shù)9.22S22車輛非法點火S22整數(shù)9.23S23車輛非法位移S23整數(shù)9.24S24碰撞側(cè)翻報警S24整數(shù)9.25S25嚴重故障S25整數(shù)9.26S26制動氣壓報警S26整數(shù)9.27S27油壓報警S27整數(shù)9.28S28水位低報警S28整數(shù)9.29

31、S29制動蹄片磨損報警S29整數(shù)9.30S30空濾堵塞報警S30整數(shù)9.31S31緩速器高溫報警信號S31整數(shù)9.32S32倉溫報警信號S32整數(shù)9.33S33機濾堵塞信號S33整數(shù)9.34S34燃油堵塞信號S34整數(shù)9.35S35機油溫度報警信號S35整數(shù)9.36S36燃油警告S36整數(shù)9.37S37空檔滑行告警S37整數(shù)9.38S38超長怠速告警S38整數(shù)9.39S39怠速空調(diào)告警S39整數(shù)9.40S40發(fā)動機超轉(zhuǎn)告警S40整數(shù)9.41S41急加速報警S41整數(shù)9.42S42急減速報警S42整數(shù)9.43S43門開報警S43整數(shù)9.44S44冷卻液溫度過高報警S44整數(shù)9.45S45蓄電池電

32、壓報警S45整數(shù)9.46S46ABS故障告警S46整數(shù)9.47S47關鍵點報警S47整數(shù)10LO經(jīng)度I整數(shù)原始經(jīng)度11LA緯度J整數(shù)原始緯度12MIL里程L整數(shù)13TOW累計油耗M整數(shù)14ETT發(fā)動機運行時長N整數(shù)15ER引擎轉(zhuǎn)速O整數(shù)16LS位置狀態(tài)位P整數(shù)17ALS區(qū)域/線路報警Q字符串18CT冷卻液溫度R整數(shù)19SBV蓄電池電壓S整數(shù)20IOW瞬時油耗T整數(shù)21RSP記錄儀速度U整數(shù)22SD機油壓力V整數(shù)23AD大氣壓力W整數(shù)24ENP發(fā)動機扭矩百分比X整數(shù)25DS車輛信號狀態(tài)Y整數(shù)26ST系統(tǒng)時間Z整數(shù)建議：為節(jié)省GPS實時數(shù)據(jù)的存儲空間，我們建議采用英文首字符縮寫方式來定義每個字段的

33、名稱，當然也可以用a、b、c、d來表示每個字段的名稱，這樣的好處是節(jié)省存儲空間，缺點是可讀性差，但可以通過相關查詢接口函數(shù)還原數(shù)據(jù)項可讀性差的問題。2. GPS報警歷史數(shù)據(jù)存儲集合（表）結(jié)構定義表名：alarm_his_infos。作用：用于車輛報警事件信息的集合（表），包括報警位置、報警時間、報警附加信息、報警處理信息等。具體表結(jié)構信息如下所示：編號字段名稱中文對照別名字段類型是否索引備注1AID報警IDA整數(shù)是2VID車輛IDB整數(shù)是3VNO車牌號C字符串是4DID當班司機編號D整數(shù)5STS報警開始時間E1整數(shù)是6SLON經(jīng)度（起始位置）F1整數(shù)偏移后的7SLAT緯度（起始位置）G1整數(shù)偏

34、移后的8SSP速度（起始位置）H1整數(shù)9SDIR方向（起始位置）I1整數(shù)10SALT海拔（起始位置）J1整數(shù)11SMIL里程（起始位置）K1整數(shù)12STOW累計油耗（起始位置）L1整數(shù)13ETS報警結(jié)束時間E2整數(shù)是14ELON經(jīng)度（結(jié)束位置）F2整數(shù)偏移后的15ELAT緯度（結(jié)束位置）G2整數(shù)偏移后的16ESP速度（結(jié)束位置）H2整數(shù)17EDIR方向（結(jié)束位置）I2整數(shù)18EALT海拔（結(jié)束位置）J2整數(shù)19EMIL里程（結(jié)束位置）K2整數(shù)20ETOW累計油耗（結(jié)束位置）L2整數(shù)21AT報警類型編碼M整數(shù)詳見報警編碼對照表22AS報警源N整數(shù)1：車載終端，2：企業(yè)監(jiān)控平臺，3：政府監(jiān)管平臺，

35、9：其它23BS基本狀態(tài)O1整數(shù)24ES擴展狀態(tài)O2整數(shù)25SAA報警附加信息（開始位置)P1字符串26EAA報警附加信息（結(jié)束位置）P2字符串27ATS報警時間/系統(tǒng)時間Q整數(shù)建議和系統(tǒng)時間合并28APS報警處理狀態(tài)R整數(shù)是-1：未處理；0：不作處理；1：將來處理；2：處理完畢29UID報警處理人S整數(shù)30APTS報警處理時間T整數(shù)是31TODO督辦狀態(tài)U整數(shù)0：未督辦;1：內(nèi)部督辦;2：監(jiān)管平臺督辦建議：為節(jié)省車輛報警數(shù)據(jù)的存儲空間，我們建議采用英文首字符縮寫方式來定義每個字段的名稱，當然也可以用a、b、c、d來表示每個字段的名稱，這樣的好處是節(jié)省存儲空間，缺點是可讀性差，但可以通過相關查

36、詢接口函數(shù)還原數(shù)據(jù)項可讀性差的問題。注：（1）報警類型編碼對照表，如下表所示：報警類型報警編號緊急報警0超速報警1疲勞駕駛2預警3導航模塊故障4導航系統(tǒng)天線未接5導航天線短路6終端主電源欠壓7終端主電源掉電8終端顯示屏故障9語音模塊故障10攝像頭故障11當天累計駕駛超時18超時停車19進出區(qū)域20進出路線21路線行駛時間不足/過長22路線偏移報警23車輛速度傳感器故障24車輛油量異常25車輛被盜26車輛非法點火27車輛非法位移28碰撞側(cè)翻報警29嚴重故障32制動氣壓報警33油壓報警34水位低報警35制動蹄片磨損報警36空濾堵塞報警37緩速器高溫報警信號38倉溫報警信號39機濾堵塞信號40燃油堵

37、塞信號41機油溫度報警信號42燃油警告43空檔滑行告警44超長怠速告警45怠速空調(diào)告警46發(fā)動機超轉(zhuǎn)告警47急加速報警48急減速報警49門開報警50冷卻液溫度過高報警51蓄電池電壓報警52ABS故障告警53關鍵點報警220（2）報警附加信息編碼定義1.超速報警，格式：位置類型|區(qū)域或路段ID類型： 0：無特定位置；1：圓型區(qū)域；2：矩形區(qū)域；3：多邊形區(qū)域；4：路段 當類型為0時，無區(qū)域ID或路段ID值2.進出區(qū)域/路段報警附加信息類型 ，格式：位置類型區(qū)域或線路ID方向 類型： 0：無特定位置；1：圓型區(qū)域；2：矩形區(qū)域；3：多邊形區(qū)域；4：路線方向： 0：進，1：出3.路線行駛時間不足/過

38、長， 格式： 路段ID路段行駛時間結(jié)果 結(jié)果： 0：不足，1：過長3. 司機駕駛行為事件存儲集合（表）結(jié)構定義表名：driver_action_infos。作用：用于存儲司機駕駛行為數(shù)據(jù)的表。具體表結(jié)構信息如下所示：編號字段名稱中文對照別名字段類型是否索引備注1VID車輛IDA整數(shù)是2AID駕駛行為類型B整數(shù)是詳見下表3STSGPS時間（起始位置）C整數(shù)是不包含時區(qū)4SLON經(jīng)度（起始位置）D整數(shù)偏移后的5SLAT緯度（起始位置）E整數(shù)偏移后的6SSP速度（起始位置）F整數(shù)7SALT海拔（起始位置）G整數(shù)8SDIR方向（起始位置）H整數(shù)9ETSGPS時間（結(jié)束位置）I整數(shù)是不包含時區(qū)10ELO

39、N經(jīng)度（結(jié)束位置）J整數(shù)偏移后的11ELAT緯度（結(jié)束位置）K整數(shù)偏移后的12ESP速度（結(jié)束位置）L整數(shù)13EALT海拔高度（結(jié)束位置）M整數(shù)14EDIR方向（結(jié)束位置）N整數(shù)15ST系統(tǒng)時間O整數(shù)注:駕駛行為類型定義 ：駕駛行為類型行為編號加熱器工作1空調(diào)工作2發(fā)動機超轉(zhuǎn)3過長怠速4超經(jīng)濟區(qū)運行5空檔滑行6怠速空調(diào)7二檔起步8檔位不當9超速10疲勞駕駛114. 發(fā)動機負荷率存儲集合（表）結(jié)構定義表名：engine_load_infos。作用：用于存儲車輛的發(fā)動機負荷率數(shù)據(jù)的集合（表）。具體表結(jié)構信息如下所示：編號字段名稱中文對照別名字段類型是否索引備注1VID車輛IDA整數(shù)是2TS時間C整

40、數(shù)是不包含時區(qū)3DAT負荷數(shù)據(jù)D字符串5. 拍照數(shù)據(jù)存儲集合（表）結(jié)構定義表名：photo_infos。作用：用于存儲車輛的拍照圖片數(shù)據(jù)的集合（表）。具體表結(jié)構信息如下所示：編號字段名稱中文對照別名字段類型是否索引備注1VID車輛IDA整數(shù)是2TS拍照時間B整數(shù)是不包含時區(qū)3FN文件名C字符串4HP發(fā)布地址D字符串5DAT圖片E二進制對象6. 上下行指令數(shù)據(jù)集合結(jié)構定義表名：up_down_command_infos。作用：用于存儲車輛的拍照圖片數(shù)據(jù)的集合（表）。具體表結(jié)構信息如下所示：附件2: 存儲服務（MongoDB）對外接口統(tǒng)一定義存儲服務的對外統(tǒng)一接口分為3大類：更新類接口、查詢接口和

41、統(tǒng)計類接口。由于寫操作接口跟通信服務緊密相關，所以優(yōu)先提供C+類型的接口。查詢和統(tǒng)計接口跟上層服務和應用緊密相關，所以提供Java類型的接口和JavaScript接口，這里優(yōu)先提供Java接口。2.1更新類接口1） GPS實時位置數(shù)據(jù)更新接口AGPS實時數(shù)據(jù)插入操作接口int insertGPS（BSONObj& gpsData）；注：BSONObj為MongoDB C+客戶端驅(qū)動的BSON數(shù)據(jù)的基本對象。gpsData參數(shù)的聲明類型為BSONObj其具體格式定義如下"A" : 1175, / 車輛ID“B” : ISODate("2012-02-17T1

42、4:22:46")/ GPS時間"C" : 69838489,/ 經(jīng)度"D" : 23946431,/ 緯度"E" : 59,/ 速度"F" : 234,/ 方向“G”: 1225,/ 海拔高度"VS" : / 車輛狀態(tài)子類（嵌套）“s1” ： / 緊急報警“s2” ： / 超速報警“s3” ： / 疲勞駕駛“s4” ： / 預警“s5” ： / 導航模塊故障“s6” ： / 導航系統(tǒng)天線未接“s7” ： / 導航天線短路“s8” ： / 終端主電源欠壓“s9” ： / 終端主電源掉電

43、“s10” ： / 終端顯示屏故障“s11” ： / 語音模塊故障“s12” ： / 攝像頭故障“s13” ： / 當天累計駕駛超時“s14” ： / 超時停車“s15” ： / 進出區(qū)域“s16” ： / 進出路線“s17” ： / 路線行駛時間不足/過長 “s18” ： / 路線偏移報警“s19” ： / 車輛速度傳感器故障“s20” ： / 車輛油量異常“s21” ： / 車輛被盜“s22” ： / 車輛非法點火“s23” ： / 車輛非法位移“s24” ： / 碰撞側(cè)翻報警“s25” ： / 嚴重故障“s26” ： / 制動氣壓報警“s27” ： / 油壓報警“s28” ： / 水位低

44、報警“s29” ： / 制動蹄片磨損報警“s30” ： / 空濾堵塞報警“s31” ： / 緩速器高溫報警信號“s32” ： / 倉溫報警信號“s33” ： / 機濾堵塞信號“s34” ： / 燃油堵塞信號“s35” ： / 機油溫度報警信號“s36” ： / 燃油警告“s37” ： / 空檔滑行告警“s38” ： / 超長怠速告警“s39” ： / 怠速空調(diào)告警“s40” ： / 發(fā)動機超轉(zhuǎn)告警“s41” ： / 急加速報警“s42” ： / 急減速報警“s43” ： / 門開報警“s44” ： / 冷卻液溫度過高報警“s45” ： / 蓄電池電壓報警“s47” ： / ABS故障告警“s4

45、7” ： / 關鍵點報警"H":395454,/ 經(jīng)度"I" : 1393444,/ 緯度“J” : 1243544,/ 海拔高度“K” : 235679087,/ 里程“L” : 2,/ 位置基本信息狀態(tài)位“M” : “區(qū)域、進”,/ 區(qū)域/線路報警“N” : 55,/ 行駛記錄儀速度“O” : 2,/ 車輛信號狀態(tài)“P” : ISODate("2012-02-17T14:22:46"),/ 系統(tǒng)時間“CAN” : / CAN總線數(shù)據(jù)子類（嵌套）“c1” : 135,/ 累計油耗“c2” : 135,/ 發(fā)動機運行總時長“c3” :

46、 135,/ 引擎轉(zhuǎn)速“c4” : 135,/ 冷卻液溫度“c5” : 135,/ 蓄電池電壓“c6” : 135,/ 瞬時油耗“c7” : 135,/ 機油壓力“c8” : 135,/ 大氣壓力“c9” : 135,/ 發(fā)動機扭矩百分比2） 車輛報警數(shù)據(jù)更新接口A.車輛報警數(shù)據(jù)插入操作接口int insertAlarmData(BSONObj& alarmData)；alarmData參數(shù)的聲明類型為BSONObj其具體格式定義如下："A" : 1175, / 車輛ID“B” : "京B126765"),/ 車牌號碼“C” : 3376,/ 當班司機編號“P1” : / 報警開始位置信息（子類）“a1” : ISODate("2012-02-17T14:22:46")/ 報警開始時間（GPS時間）"a2" : 69838489,/ 經(jīng)度"a3" : 23946431,/ 緯度"a4" : 59,/ 速度"a5" : 234,/ 方向“a6”: 1225,/ 海拔高度&quo