MongoDB存储服务设计方案.docVIP

MongoDB存储服务设计方案 需求分析 1.1 客车平台和货运平台现有需求 1) 实时数据文件存储类 a. 实时轨迹数据：传统文件方式存储，一条轨迹150B，每天上报8640次，一天大约为1M； 轨迹文件 偏移经度: 偏移纬度: GPS时间: GPS 速度: 正北方向夹角: 车辆状态: 报警编码：经度：纬度：海拔：里程：累计油耗：发动机运行总时长：引擎转速（发动机转速）：位置基本信息状态位：报区域/线路报警：冷却液温度：蓄电池电压: 瞬时油耗: 行驶记录仪速度: 机油压力: 大气压力: 发动机扭矩百分比: 车辆信号状态:系统时间\r\n 特点：数据频率高，数据量大。 b. 实时报警数据：传统文件方式存储，一条报警100B，每天上报8640次，一天大约为800K； 报警文件 报警编码：偏移经度: 偏移纬度：经度：纬度：GPS时间: GPS 速度: 正北方向夹角：累计油耗: 里程: 报区域/线路报警: 海拔：系统时间\r\n c. 驾驶行为事件：传统文件方式存储，一条驾驶行为事件100B，每天上报不固定，根据实际生产环境观察，平均每天最大300K； 特点：数据频率不高，数据量小。 发动机负荷率：传统文件方式存储，一条发动机负荷率200B,每天上报360次，一天大约为80K； 特点：数据频率不高，数据量小。 拍照数据，图片文件，每天上报数据量不定 特点：数据频率不高，数据量小。 盲区补传轨迹文件：轨迹文件统计最大数，这里不做统计； 盲区补传报警文件：报警文件统计最大数，这里不做统计； 2) 实时数据传统数据库存储类 Oracle数据库存储 存储非法轨迹位置； 更新车辆最后位置； 存储、更新车辆上下线； D．存储、更新车辆报警； MYSQL数据库存储 更新车辆最后位置 B．存储、更新车辆报警 3）操作指令传统数据库类 Oracle数据库存储 存储、更新下行指令?Capped Collection来存放。 存储车辆多媒体事件 存储车辆多媒体信息 存储车辆鉴权，建议放在Oracle数据库中，同步到redis中供鉴权服务用。 存储车辆注销，建议放在Oracle数据库中。 存储车辆事件报告 存储车辆电子运单，建议放在Oracle数据库中。 存储车辆驾驶员信息，建议放在Oracle数据库中，同步到redis，防止二次访问数据库。 存储车辆行驶记录仪信息，建议放在Oracle数据库中。 存储车辆调度信息 更新车辆照片信息 更新终端参数信息 更新电子围栏，建议放在Oracle数据库中。 存储、更新终端参数设置，建议放在Oracle数据库中。 更新终端版本号，建议放在Oracle数据库中。 存储多媒体数据检索 存储上行透传信息 存储数据压缩透传 更新提问应答 存储、更新下行指令，建议废弃MySQL，用redis来替代。 存储车辆多媒体信息，，建议废弃MySQL，用redis来替代。 4）历史数据查询统计类 轨迹回放条件：GPS时间（开始时间、接收时间）、VID； 区域查车（当前区域内车辆）条件：车辆类型、车辆速度、是否报警； 区域协查（历史区域内车辆）条件：GPS时间； 历史报警条件：类型、状态、时间； 1.2 现有平台存储服务上存在问题 盲区补传数据分离问题； 跨多天历史轨迹查询的问题； 报警数据和GPS实时数据分离的问题； 区域查车、区域协查的准确性和计算效率问题； 报警数据、CAN总线数据统计分析问题，MongoDB提供MapReduce（一个大规模数据并行计算技术，源于google）服务来进行统计分析； 拍照数据问题（统一管理，方便访问）； 业务流程、数据流程合理性问题； 设计质量问题，如下： 3|[241][404][200]172641]|[241][415][199]172642] 集群、负载均衡问题； 高可用性问题(在线扩容、故障转移)； 运营监控问题（存储实例监控）； 方案设计 2.1 存储服务方案设计目标 利用MongoDB来一体化解决GPS实时数据（高并发）存储和相关的查询统计业务（如历史轨迹查询），并解决存储服务的长期运营的高可用性问题。 具体包括： 解决GPS实时位置信息存储问题（高并发写、高速查询、高速统计分析）； 解决GPS报警数据存储问题（高并发写、高速查询、统计分析）； 解决司机驾驶行为数据存储问题（高并发写、高速查询、统计分析）； 解决拍照数据存储问题（高并发写、自动发布、高速查询）； 解决区域查车、区域协查等运算量大的业务统计问题； 解决存储服务高可用性问题(如负载均衡、线性扩容、故障转移、灾备恢复、服务监控等)； 最终目标：简化现有平台业务流程