MongoDB存储服务设计方案.docx

MongoDB存储服务设计方案.docx

《MongoDB存储服务设计方案.docx》由会员分享，可在线阅读，更多相关《MongoDB存储服务设计方案.docx（47页珍藏版）》请在冰豆网上搜索。

MongoDB存储服务设计方案

MongoDB存储服务设计方案

1.需求分析

1.1客车平台和货运平台现有需求

1）实时数据文件存储类

a.实时轨迹数据：

传统文件方式存储，一条轨迹150B，每天上报8640次，一天大约为1M；

轨迹文件格式说明：

偏移经度:

偏移纬度:

GPS时间:

GPS速度:

正北方向夹角:

车辆状态:

报警编码：

经度：

纬度：

海拔：

里程：

累计油耗：

发动机运行总时长：

引擎转速（发动机转速）：

位置基本信息状态位：

报区域/线路报警：

冷却液温度：

蓄电池电压:

瞬时油耗:

行驶记录仪速度:

机油压力:

大气压力:

发动机扭矩百分比:

车辆信号状态:

系统时间\r\n

特点：

数据频率高，数据量大。

b.实时报警数据：

传统文件方式存储，一条报警100B，每天上报8640次，一天大约为800K；

报警文件格式说明：

报警编码：

偏移经度:

偏移纬度：

经度：

纬度：

GPS时间:

GPS速度:

正北方向夹角：

累计油耗:

里程:

报区域/线路报警:

海拔：

系统时间\r\n

特点：

数据频率高，数据量大。

c.驾驶行为事件：

传统文件方式存储，一条驾驶行为事件100B，每天上报不固定，根据实际生产环境观察，平均每天最大300K；

特点：

数据频率不高，数据量小。

d.发动机负荷率：

传统文件方式存储，一条发动机负荷率200B,每天上报360次，一天大约为80K；

特点：

数据频率不高，数据量小。

e.拍照数据，图片文件，每天上报数据量不定

特点：

数据频率不高，数据量小。

f.盲区补传轨迹文件：

轨迹文件统计最大数，这里不做统计；

g.盲区补传报警文件：

报警文件统计最大数，这里不做统计；

2）实时数据传统数据库存储类

Oracle数据库存储

A．存储非法轨迹位置；

B．更新车辆最后位置；

C．存储、更新车辆上下线；

D．存储、更新车辆报警；

MYSQL数据库存储

A．更新车辆最后位置

B．存储、更新车辆报警

3）操作指令传统数据库类

Oracle数据库存储

A.存储、更新下行指令，建议放在MongoDB中，用 CappedCollection来存放。

B.存储车辆多媒体事件

C.存储车辆多媒体信息

D.存储车辆注册，建议放在Oracle数据库中。

E.存储车辆鉴权，建议放在Oracle数据库中，同步到redis中供鉴权服务用。

F.存储车辆注销，建议放在Oracle数据库中。

G.存储车辆事件报告

H.存储车辆信息点播，建议放在Oracle数据库中。

I.存储车辆电子运单，建议放在Oracle数据库中。

J.存储车辆驾驶员信息，建议放在Oracle数据库中，同步到redis，防止二次访问数据库。

K.存储车辆行驶记录仪信息，建议放在Oracle数据库中。

L.存储、更新车辆调度信息，建议放在Oracle数据库中。

M.更新车辆照片信息

N.更新终端参数信息

O.更新路线信息，建议放在Oracle数据库中。

P.更新电子围栏，建议放在Oracle数据库中。

Q.存储、更新终端参数设置，建议放在Oracle数据库中。

R.更新终端版本号，建议放在Oracle数据库中。

S.存储多媒体数据检索

T.存储上行透传信息

U.存储数据压缩透传

V.更新提问应答

MYSQL数据库存储：

A.存储、更新下行指令，建议废弃MySQL，用redis来替代。

B.存储车辆多媒体信息，，建议废弃MySQL，用redis来替代。

4）历史数据查询统计类

A.轨迹回放条件：

GPS时间（开始时间、接收时间）、VID；

B.区域查车（当前区域车辆）条件：

车辆类型、车辆速度、是否报警；

C.区域协查（历史区域车辆）条件：

GPS时间；

D.历史报警条件：

类型、状态、时间；

1.2现有平台存储服务上存在问题

1）盲区补传数据分离问题；

2）跨多天历史轨迹查询的问题；

3）报警数据和GPS实时数据分离的问题；

4）区域查车、区域协查的准确性和计算效率问题；

5）报警数据、CAN总线数据统计分析问题，MongoDB提供MapReduce（一个大规模数据并行计算技术，源于google）服务来进行统计分析；

6）拍照数据问题（统一管理，方便访问）；

7）业务流程、数据流程合理性问题；

8）设计质量问题，如下：

3|[16569481][66064567][241][404][200][20120312/172641]|[16569423][66064545][241][415][199][20120312/172642]

9）集群、负载均衡问题；

10）高可用性问题（在线扩容、故障转移）；

11）运营监控问题（存储实例监控）；

2.方案设计

2.1存储服务方案设计目标

利用MongoDB来一体化解决GPS实时数据（高并发）存储和相关的查询统计业务（如历史轨迹查询），并解决存储服务的长期运营的高可用性问题。

具体包括：

A.解决GPS实时位置信息存储问题（高并发写、高速查询、高速统计分析）；

B.解决GPS报警数据存储问题（高并发写、高速查询、统计分析）；

C.解决司机驾驶行为数据存储问题（高并发写、高速查询、统计分析）；

D.解决拍照数据存储问题（高并发写、自动发布、高速查询）；

E.解决区域查车、区域协查等运算量大的业务统计问题；

F.解决存储服务高可用性问题（如负载均衡、线性扩容、故障转移、灾备恢复、服务监控等）；

最终目标：

简化现有平台业务流程，减少故障节点，提高存储服务的高可用性。

2.2存储方案设计细则

2.2.1GPS实时数据存储设计

针对GPS实时数据存储，存储服务提供C/C++客户端接口，供通信系统调用，可以直接把GPS数据存放在MongoDB中，而调用者无需关系MongoDB的性能和负载问题。

MongoDB采用目前通用的JSON格式，并提供JSON格式的解析和组装包，支持C/C++、Java、JavaScript、Flex等众多主流开发语言，方便平台各层面来使用。

针对MongoDB的数据格式特点，我们把GPS实时数据格式定义为标准JSON格式，其定义如下：

1）GPS实时数据格式定义

详见“附件1“和”附件2“相关定义。

2）司机驾驶行为数据

司机驾驶行为现有平台的数据格式：

驾驶行为类型|[起始位置纬度][起始位置经度][起始位置高度][起始位置速度][起始位置方向][起始位置时间]|[结束位置纬度][结束位置经度][结束位置高度][结束位置速度][结束位置方向][结束位置时间]。

具体数据样例：

3|[16569481][66064567][241][404][200][20120312/172641]|[16569423][66064545][241][415][199][20120312/172642]。

3）发动机负荷率数据

格式：

无固定格式（BASE64后得到）

具体数据：

-00000

MongoDB数据库格式定义（JSON）

{

"VID":

311,

"TS":

ISODate（"2012-02-17T14:

22:

46.777Z"）,

"DAT":

“-00000”

}

JSON格式说明：

车辆编号（VID）、时间戳（DS）、负荷数据（DAT）。

2.2.2拍照数据存储设计

MongoDB提供GridFS特性，用来存储大文件，如图片文件和视频文件。

由通信平台产生的有效拍照图片，可以连同属性信息（如车机ID、时间戳、图片ID、访问路径（http））一起直接存储在MongoDB中，方便前端应用查询。

MongoDB数据库格式定义（JSON）

{

"VID":

311,

"TS":

ISODate（"2012-02-17T14:

22:

46.777Z"）,

“FID”:

“file1”,

“HP”:

“192.168.1.33:

270001/file.jpg”,

"DAT":

“000”

}

JSON格式说明：

车辆编号（VID）、时间戳（DS）、文件名（FID）、发布路径（HP）、图片数据（DAT）。

2.2.3GPS历史数据查询设计

GPS数据查询主要包括：

实时数据查询和历史数据查询。

为解决海量GPS数据查询的效率和并发负载问题，在设计时考虑从3各方面来设计和优化：

1）创建数据索引

MongoDB支持对数据进行索引，即可在设计之初就设计好索引，也可在运营期间来对数据的索引进行调整，建议在采用前者。

针对历史轨迹数据的查询需求条件：

车机ID，起止时间，可以对“VID”、“TS”字段创建索引，来提高GPS历史轨迹数据的查询效率。

针对报警查询查询需求：

起止时间和报警状态，可以对“TS”字段、“VS”字段创建索引。

2）数据读写分离和负载均衡设计

在MongoDB服务部署方案中，我们采用多服务器集群，读写分离的部署架构，即通过部署多个写服务和多个读服务，来解决GPS数据存储的效率和服务可靠性、可扩展性问题。

3）存数据

MongoDB为提高数据查询的效率，也采用了存机制，把大量的热点数据放在存中，来提高数据查询的命中率，我们可以利用这个特性来满足车辆位置查询的需求。

4）GPS数据查询接口设计

a.车辆位置查询接口

提供查询车辆最新位置信息，查询条件为车辆ID，具体实现主要是通过MongoDB的缓存机制来完成。

可提供Java和JavaScript接口，供上层应用调用。

注：

此处与实时服务的功能有些重复，建议由实时服务来统一提供。

b.历史轨迹查询接口设计

提供查询每辆车的历史轨迹数据，查询条件为：

车辆ID、开始时间、结束时间。

返回集应包含去除除Can总线后的数据。

可提供Java和JavaScript接口，供上层应用调用。

注：

查询返回的数据集结果尽量简洁，针对每类业务要求的访问，不必要的信息要剔除掉，减少网络压力、提高查询效率。

c．报警数据查询

2.2.4GPS数据统计设计

1）快照功能

提供查询某个区域、某段时间、都有哪些车辆，查询条件为。

提供查询某个区域、某段时间、都有哪些类型的报警车辆。

2）报警统计

可以按报警类别来统计某个时间段都有哪些报警车辆。

可以统计某辆车在某段时间的报警次数统计，可按总计、按报警类别来统计。

2.2.5拍照数据发布和查询设计

通过MongoDB的插件，与Nginx应用服务代理集成，可以直接把存储在MongoDB中的数据发布成Http图片服务，供Web应用层调用。

在具体应用中的业务流程如下：

方案说明：

A.解决图片文件储存储分布的问题，可以利用MongoDB把gps数据、图片数据、视频数据等都存储在一起，方便管理和维护；

B.解决图片文件便利访问的问题，如文件的属性，文件的存储，文件的访问路径都作为一条记录存储在MongoDB中，方便上层应用获取；

C.解决图片高效访问的问题，如利用Nginx解决图片资源并发访问的问题，利用Squid/Varnishd缓存服务来解决二次访问MongoDB的问题；

2.3存储服务业务流程框架设计

MongoDB存储服务提供C++/C#接口、Java接口和JavaScript接口，分别为通讯层、服务层和应用层提供存储服务。

3.方案部署架构设计

3.1存储服务（MongoDB）部署架构规划设计

为保证MongoDB的高可用性（高并发、高可扩展性、高稳定性），我们采用了ReplicaSet+Sharding部署架构，这是一种可以水平扩展的模式，在数据量很大时特给力，实际大规模应用一般会采用这种架构去构建MongoDB存储系统。

MongoDB存储服务