MongoDB存储服务方案设计.docx
- 文档编号:1045925
- 上传时间:2022-10-16
- 格式:DOCX
- 页数:47
- 大小:516.27KB
MongoDB存储服务方案设计.docx
《MongoDB存储服务方案设计.docx》由会员分享,可在线阅读,更多相关《MongoDB存储服务方案设计.docx(47页珍藏版)》请在冰豆网上搜索。
MongoDB存储服务方案设计
MongoDB存储服务方案设计
2012-03-14
GPS数据存储服务方案设计
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后得到)
具体数据:
-1600
MongoDB数据库格式定义(JSON)
{
"VID":
311,
"TS":
ISODate("2012-02-17T14:
22:
46.777Z"),
"DAT":
“-1600”
}
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”:
“”,
"DAT":
“00”
}
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存储系统。
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- MongoDB 存储 服务 方案设计