《MongoDB存储服务方案设计》由会员分享，可在线阅读，更多相关《MongoDB存储服务方案设计（49页珍藏版）》请在金锄头文库上搜索。
1、MongoDB存储服务方案设计2012-03-14目录1 .需求分析3.1.1 客车平台和货运平台现有需求31.2 现有平台存储服务上存在问题52 .方案设计7.2.1 存储服务方案设计目标7.2.2 存储方案设计细则7.2.2.1 GPS实时数据存储设计72.2.2 拍照数据存储设计8.2.2.3 GPS历史数据查询设计92.2.4 GPS数据统计设计1.02.2.5 拍照数据发布和查询设计1.12.3 存储服务业务流程框架设计1.13 .方案部署架构设计1.23.1 存储服务(MongoDB部署架构规划设计123.2 存储服务(MongoDB数据分片规划设计143.3 存储服务(Mongo
2、DB实例部署规划设计153.4 存储服务(MongoDB服务器硬件、网络和操作系统规划设计163.5 MongoDB版本规划设计1.73.6 存储服务(MongoDB运营监控规划设计174 .方案实施184.1 实施步骤1.84.2 方案整体实施计划18附件1:存储服务表(MongoDBCollection)结构设计19附件2:存储服务(MongoDB)对外接口统一定义262.1 更新类接口272.2 查询类接口322.3 统计接口.40附件3:存储服务(MongoDB)安装部署说明413.1 安装MongoDB413.2 MongoDB分片酉己置423.2.1 分片服务器(sharding)
3、配置433.2.2 副本集(ReplicaSet)配置443.2.3 启动并配置三台ConfigServer.443.2.4 部署并配置三台RoutingServer.453.2.5 命令行添加分片45GPS数据存储服务方案设计1 .需求分析1.1 客车平台和货运平台现有需求1）实时数据文件存储类a.实时轨迹数据：传统文件方式存储，一条轨迹150B,每天上报8640次，一天大约为1M轨迹文件格式说明：偏移经度：偏移纬度：GPS时间：GPS速度：正北方向夹角：车辆状态：报警编码：经度：纬度：海拔：里程：累计油耗：发动机运行总时长：引擎转速（发动机转速）：位置基本信息状态位：报区域/线路报警：冷却
4、液温度：蓄电池电压：瞬时油耗：行驶记录仪速度：机油压力：大气压力：发动机扭矩百分比：车辆信号状态：系统时间rn特点：数据频率高，数据量大。b.实时报警数据：传统文件方式存储，一条报警100B,每天上报8640次，一天大约为800K报警文件格式说明：报警编码：偏移经度：偏移纬度：经度：纬度：GPS时间：GPS速度：正北方向夹角：累计油耗：里程：报区域/线路报警：海拔：系统时间rn特点：数据频率高，数据量大。C.驾驶行为事件：传统文件方式存储，一条驾驶行为事件100B,每天上报不周定，根据实际生产环境观察，平均每天最大300K特点：数据频率不高，数据量小。d.发动机负荷率：传统文件方式存储，一条发
5、动机负荷率200B,每天上报360次，一天大约为80K;特点：数据频率不高，数据量小。e.拍照数据，图片文件，每天上报数据量不定特点：数据频率不高，数据量小。f.盲区补传轨迹文件：轨迹文件统计最大数，这里不做统计；g.盲区补传报警文件：报警文件统计最大数，这里不做统计；2）实时数据传统数据库存储类Oracle数据库存储A.存储非法轨迹位置；B.更新车辆最后位置；C.存储、更新车辆上下线；D.存储、更新车辆报警；MYSQ数据库存储A.更新车辆最后位置B.存储、更新车辆报警3）操作指令传统数据库类Oracle数据库存储A.存储、更新下行指令，建议放在MongoDB中，用CappedCollecti
6、o昧存放。B.存储车辆多媒体事件C.存储车辆多媒体信息D.存储车辆注册，建议放在Oracle数据库中。E.存储车辆鉴权，建议放在Oracle数据库中，同步到redis中供鉴权服务用。F.存储车辆注销，建议放在Oracle数据库中。G.存储车辆事件报告H.存储车辆信息点播，建议放在Oracle数据库中。I.存储车辆电子运单，建议放在Oracle数据库中。J.存储车辆驾驶员信息，建议放在Oracle数据库中，同步到redis,防止二次访问数据库。K.存储车辆行驶记录仪信息，建议放在Oracle数据库中。L.存储、更新车辆调度信息，建议放在Oracle数据库中。M.更新车辆照片信息N.更新终端参数信
7、息O.更新路线信息，建议放在Oracle数据库中。P.更新电子围栏，建议放在Oracle数据库中。Q.存储、更新终端参数设置，建议放在Oracle数据库中。R.更新终端版本号，建议放在Oracle数据库中。S.存储多媒体数据检索T.存储上行透传信息U.存储数据压缩透传V.更新提问应答MYSQ数据库存储：A.存储、更新下行指令，建议废弃MySQL用redis来替代。B.存储车辆多媒体信息，建议废弃MySQL用redis来替代。4）历史数据查询统计类A.轨迹回放条件：GPS寸问（开始时间、接收时间）、VID;B.区域查车（当前区域内车辆）条件：车辆类型、车辆速度、是否报警；C.区域协查（历史区域内
8、车辆）条件：GPS寸问；D.历史报警条件：类型、状态、时间；1.2现有平台存储服务上存在问题1） 盲区补传数据分离问题；2） 跨多天历史轨迹查询的问题；3） 报警数据和GPS时数据分离的问题；4） 区域查车、区域协查的准确性和计算效率问题；5） 报警数据、CAN、线数据统计分析问题，MongoDB供MapReduce（一个大规模数据弁行计算技术，源于google）服务来进行统计分析；6） 拍照数据问题（统一管理，方便访问）；7） 业务流程、数据流程合理性问题；8） 设计质量问题，如下：3|165694816606456724140420020120312/172641|165694236606
9、454524141519920120312/1726429） 集群、负载均衡问题；10）高可用性问题（在线扩容、故障转移）；11）运营监控问题（存储实例监控）；2.方案设计2.1 存储服务方案设计目标利用MongoDB一体化解决GPS；时数据（高并发）存储和相关的查询统计业务（如历史轨迹查询），并解决存储服务的长期运营的高可用性问题。具体包括：A.解决GP砥时位置信息存储问题（高并发写、高速查询、高速统计分析）；B.解决GPS艮警数据存储问题（高并发写、高速查询、统计分析）；C.解决司机驾驶行为数据存储问题（高并发写、高速查询、统计分析）；D.解决拍照数据存储问题（高并发写、自动发布、高速查询
10、）；E.解决区域查车、区域协查等运算量大的业务统计问题；F.解决存储服务高可用性问题（如负载均衡、线性扩容、故障转移、灾备恢复、服务监控等）；最终目标：简化现有平台业务流程，减少故障节点，提高存储服务的高可用性。2.2 存储方案设计细则2.2.1 GPS实时数据存储设计针对GP砥时数据存储，存储服务提供C/C+珞户端接口，供通信系统调用，可以直接把GP漱据存放在MongoD升，而调用者无需关系MongoDB勺性能和负载问题。MongoD睬用目前通用的JSONB式，并提供JSONB式的解析和组装包，支持C/C+、Java、JavaScript、Flex等众多主流开发语言，方便平台各层面来使用。针
11、对MongoDB勺数据格式特点，我们把GP豉时数据格式定义为标准JSON格式，其定义如下：1） GPS实时数据格式定义详见“附件1“和”附件2”相关定义。2）司机驾驶行为数据司机驾驶行为现有平台的数据格式：驾驶行为类型|起始位置纬度起始位置经度北起始位置高度起始位置速度起始位置方向起始位置时间|结束位置纬度结束位置经度北结束位置高度结束位置速度结束位置方向结束位置时间。具体数据样例：3|165694816606456724140420020120312/172641|165694236606454524141519920120312/172642。3）发动机负荷率数据格式：无固定格式（BASE
12、6名得到）具体数据：-1600000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000MongoD嗷据库格式定义（JSONVID”:311,TS:ISODate（2012-02-17T14:22:46.777Z”）,DAT:-16000000000000000000000000000000000000000000000000
13、00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000JSON&式说明：车辆编号（VID）、时间戳（DS、负荷数据（DAT。2.2.2 拍照数据存储设计MongoDB供GridFS特性，用来存储大文件，如图片文件和视频文件。由通信平台产生的有效拍照图片，可以连同属性信息（如车机ID、时间戳、图片ID、访问路径（http）一起直接存储在MongoDB,方便前端应用查询。VID:311,TS:ISODate（2012
14、-02-17T14:22:46.777Z）,FID：filel”，HP：http:192.168.1.33:270001/file.jpg”，DAT:60000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000”JSON格式说明：车辆编号（VID）、时间戳（DS）、文彳名（FID）、发布路径（HP）、图片数据（DAT。2.2
15、.3 GPS历史数据查询设计GP缴据查询主要包括：实时数据查询和历史数据查询。为解决海量GP漱据查询的效率和并发负载问题，在设计时考虑从3各方面来设计和优化：1） 创建数据索引MongoD或持对数据进行索引，即可在设计之初就设计好索引，也可在运营期间来对数据的索引进行调整，建议在采用前者。针对历史轨迹数据的查询需求条件：车机ID,起止时间，可以对“VID、“TS字段创建索引，来提高GPS9J史轨迹数据的查询效率。针对报警查询查询需求：起止时间和报警状态，可以对“TS字段、VS字段创建索引。2） 数据读写分离和负载均衡设计在MongoDEK务部署方案中，我们采用多服务器集群，读写分离的部署架构，即通过部署多个写服务和多个读服务，来解决GP缴据存储的效率和服务可
