MongoDB存储服务方案设计Word格式.docx

1、 机油压力: 大气压力：发动机扭矩百分比: 车辆信号状态：系统时间r特点:数据频率高,数据量大。. 实时报警数据：传统文件方式存储,一条报警10,每天上报640次，一天大约为00;报警文件格式说明：报警编码： 偏移纬度：时间: 速度： 正北方向夹角:累计油耗: 里程: 报区域/线路报警: 海拔:系统时间rc.驾驶行为事件:传统文件方式存储，一条驾驶行为事件B,每天上报不固定,根据实际生产环境观察,平均每天最大300K；特点：数据频率不高，数据量小。d.发动机负荷率：传统文件方式存储，一条发动机负荷率200B,每天上报30次,一天大约为8K;e.拍照数据,图片文件，每天上报数据量不定数据频率不高

2、,数据量小。f.盲区补传轨迹文件:轨迹文件统计最大数，这里不做统计;g.盲区补传报警文件：报警文件统计最大数，这里不做统计；2）实时数据传统数据库存储类数据库存储A存储非法轨迹位置;B更新车辆最后位置;C存储、更新车辆上下线；.存储、更新车辆报警;A更新车辆最后位置B.存储、更新车辆报警3）操作指令传统数据库类A.存储、更新下行指令,建议放在中，用来存放。B.存储车辆多媒体事件C.存储车辆多媒体信息D.存储车辆注册,建议放在数据库中。E.存储车辆鉴权,建议放在数据库中,同步到中供鉴权服务用。F.存储车辆注销,建议放在数据库中。G.存储车辆事件报告H.存储车辆信息点播,建议放在数据库中。I.存储

3、车辆电子运单,建议放在数据库中。J.存储车辆驾驶员信息，建议放在数据库中,同步到，防止二次访问数据库。K.存储车辆行驶记录仪信息,建议放在数据库中。L.存储、更新车辆调度信息,建议放在数据库中。M.更新车辆照片信息N.更新终端参数信息O.更新路线信息,建议放在数据库中。P.更新电子围栏，建议放在数据库中。Q.存储、更新终端参数设置，建议放在数据库中。R.更新终端版本号,建议放在数据库中。S.存储多媒体数据检索T.存储上行透传信息U.存储数据压缩透传V.更新提问应答数据库存储：A.存储、更新下行指令，建议废弃,用来替代。B.存储车辆多媒体信息，,建议废弃，用来替代。4）历史数据查询统计类A.轨迹

4、回放条件：时间（开始时间、接收时间）、;B.区域查车（当前区域内车辆）条件：车辆类型、车辆速度、是否报警;C.区域协查（历史区域内车辆）条件：时间;D.历史报警条件:类型、状态、时间;.2 现有平台存储服务上存在问题1）盲区补传数据分离问题;2）跨多天历史轨迹查询的问题;3）报警数据和实时数据分离的问题;4）区域查车、区域协查的准确性和计算效率问题；5）报警数据、总线数据统计分析问题，提供（一个大规模数据并行计算技术,源于）服务来进行统计分析;6）拍照数据问题（统一管理，方便访问）;7）业务流程、数据流程合理性问题;8）设计质量问题，如下:3|6698166064567214200201202

5、/12641|165692360241151992010312/1429）集群、负载均衡问题；10）高可用性问题（在线扩容、故障转移）；11）运营监控问题（存储实例监控）;2.方案设计21 存储服务方案设计目标利用来一体化解决实时数据（高并发）存储和相关的查询统计业务（如历史轨迹查询）,并解决存储服务的长期运营的高可用性问题。具体包括:A.解决实时位置信息存储问题（高并发写、高速查询、高速统计分析）;B.解决报警数据存储问题（高并发写、高速查询、统计分析）；C.解决司机驾驶行为数据存储问题（高并发写、高速查询、统计分析）;D.解决拍照数据存储问题（高并发写、自动发布、高速查询）；E.解决区域查

6、车、区域协查等运算量大的业务统计问题；F.解决存储服务高可用性问题（如负载均衡、线性扩容、故障转移、灾备恢复、服务监控等）；最终目标:简化现有平台业务流程,减少故障节点,提高存储服务的高可用性。2 存储方案设计细则.2.1 实时数据存储设计针对实时数据存储,存储服务提供客户端接口，供通信系统调用,可以直接把数据存放在中,而调用者无需关系的性能和负载问题。采用目前通用的格式,并提供格式的解析和组装包,支持、等众多主流开发语言，方便平台各层面来使用。针对的数据格式特点，我们把实时数据格式定义为标准格式,其定义如下:1）实时数据格式定义详见“附件1“和 ”附件“相关定义。 2）司机驾驶行为数据司机驾

7、驶行为现有平台的数据格式:驾驶行为类型|起始位置纬度起始位置经度起始位置高度起始位置速度起始位置方向起始位置时间结束位置纬度结束位置经度结束位置高度结束位置速度结束位置方向结束位置时间。具体数据样例:|1564166646724200200312/1724|1656936664215992012031/2642。3）发动机负荷率数据格式：无固定格式（64后得到）具体数据：-1600数据库格式定义（） :311， : （1-02-17T1：22:46.77Z）, ：“1600”格式说明：车辆编号（）、时间戳（）、负荷数据（）。 .22 拍照数据存储设计提供特性，用来存储大文件,如图片文件和视频文

8、件。由通信平台产生的有效拍照图片,可以连同属性信息（如车机、时间戳、图片、访问路径（）一起直接存储在中,方便前端应用查询。 ： 311, （012-02-17T4:46.7Z）, “”:“”,“”，“0”格式说明:车辆编号（）、时间戳（）、文件名（）、发布路径（）、图片数据（）。23 历史数据查询设计数据查询主要包括：实时数据查询和历史数据查询。为解决海量数据查询的效率和并发负载问题,在设计时考虑从各方面来设计和优化:1）创建数据索引支持对数据进行索引，即可在设计之初就设计好索引，也可在运营期间来对数据的索引进行调整，建议在采用前者。针对历史轨迹数据的查询需求条件:车机,起止时间,可以对“”、

9、“”字段创建索引,来提高历史轨迹数据的查询效率。针对报警查询查询需求：起止时间和报警状态,可以对“”字段、“”字段创建索引。2）数据读写分离和负载均衡设计在服务部署方案中，我们采用多服务器集群,读写分离的部署架构,即通过部署多个写服务和多个读服务，来解决数据存储的效率和服务可靠性、可扩展性问题。3）内存数据为提高数据查询的效率,也采用了内存机制，把大量的热点数据放在内存中，来提高数据查询的命中率，我们可以利用这个特性来满足车辆位置查询的需求。4）数据查询接口设计a车辆位置查询接口提供查询车辆最新位置信息,查询条件为车辆,具体实现主要是通过的缓存机制来完成。可提供和接口,供上层应用调用。注：此处

10、及实时服务的功能有些重复,建议由实时服务来统一提供。b.历史轨迹查询接口设计提供查询每辆车的历史轨迹数据，查询条件为：车辆、开始时间、结束时间。返回集应包含去除除总线后的数据。可提供和接口，供上层应用调用。查询返回的数据集结果尽量简洁，针对每类业务要求的访问,不必要的信息要剔除掉，减少网络压力、提高查询效率。c报警数据查询2.2.4 数据统计设计1）快照功能提供查询某个区域内、某段时间、都有哪些车辆,查询条件为。提供查询某个区域内、某段时间、都有哪些类型的报警车辆。2）报警统计可以按报警类别来统计某个时间段内都有哪些报警车辆。可以统计某辆车在某段时间内的报警次数统计，可按总计、按报警类别来统计

11、。22.5 拍照数据发布和查询设计通过的插件,及应用服务代理集成,可以直接把存储在中的数据发布成图片服务,供应用层调用。在具体应用中的业务流程如下:方案说明：A.解决图片文件储存储分布的问题,可以利用把数据、图片数据、视频数据等都存储在一起，方便管理和维护；B.解决图片文件便利访问的问题,如文件的属性,文件的存储,文件的访问路径都作为一条记录存储在中,方便上层应用获取；C.解决图片高效访问的问题，如利用解决图片资源并发访问的问题，利用缓存服务来解决二次访问的问题;.3 存储服务业务流程框架设计存储服务提供接口、接口和接口，分别为通讯层、服务层和应用层提供存储服务。3.方案部署架构设计1 存储服

12、务（）部署架构规划设计为保证的高可用性（高并发、高可扩展性、高稳定性），我们采用了 + 部署架构,这是一种可以水平扩展的模式,在数据量很大时特给力,实际大规模应用一般会采用这种架构去构建存储系统。存储服务方案部署架构设计，如下图所示:存储服务集群架构设计架构图说明：A.分片：分别在台服务器（见上图,3,5）运行一个实例（见上图 11, 2, 31）。B.副本集：分别在3台服务器（见上图,4，）运行一个实例（称为 12, 2, 2），其中：的 12是2的1的副本。4的 2是2的21的副本。的 31是2的1的副本。C.2台服务器,每台服务器（见上图1、3）运行一个实例，作为个,其作用是双机热备。D

13、.3台服务器,每台服务器（见上图2，4，）运行一个路由进程,用于客户端连接。E.线性扩展：可以同时增加台服务器（见上图5、）,其一个作为分片,另一个作为分片的副本和路由。备注说明：1）实例 : 用于存储实际的数据块,实际生产环境中一个 角色可由几台服务器组个一个承担，防止主机单点故障。2） 存储分片集群的的元数据，其中包括在每个实例的基本信息和块信息。每个配置服务器所有块的元数据的副本。通过两次提交来确保在配置服务器信息及块数据的一致性。3） 可以被看作是一个数据和请求分发的中心,使单一的实例组成互相关联的集群。当接收客户端请求, 根据路由到相应的实例（可能是一组）,处理并返回结果。 进程没有

14、持久状态,在启动时和配置服务器建立连接并获取状态,当配置服务器发生任何变化时,会将之传播到每个进程。3.2存储服务（）数据分片规划设计）什么叫分片以及分片的作用?数据分割以及在不同机器存储数据的过程称之为分片。通过在多台机器上分割数据，使得数据库系统能存储更多的数据,和处理更多的负载,在此过程中不需要更多更强大的机器。分片的基本概念是分割集群成更小的块,或是文档。这些分档可以分布于很多的,这样每个负载总数据集得子集。举个例子,思考一下。当你从集合选择一个安装分片时,并使用分割数据。这个称为 。假设你有一个联系人的集合。如果我们选择“姓”作为 ,那么一个分片可以存储“姓”以开头的，下一个分片可以

15、存储“姓”以开头的，最后一个分片存储“姓”以开头的。当你添加和删除分片时，会重新做数据的负载,这样每个分片会获取一定量的流量和实际量的数据。所以在决定什么开始分片呢？考虑一下几个因素：目前的机器的磁盘什么时候用完；希望比单一的处理速度更快;希望在内存中保留更多的数据以改善性能;.3 存储服务（）实例部署规划设计由于本方案是:规划用4到台服务器,多个（6个实例、2个实例、3各实例）实例同时运行在这些服务器上,所以在部署前需要先规划好服务器的地址、实例的名称、实例的分布（在那台服务器上）、实例的端口等，然后再实施。本方案的数据库实例部署规划如下表所示：主机服务名及端口1“0”19.168.1（内网

16、）10.1（外网）11:2701 1:2000 = “02”1921.52（内网）01.1.（外网） 1：27011:3000 = “03”19.165.3（内网）101.1.3（外网） 2：27017 2：2000 “”92.168.（内网）1114（外网） 22:2782:3005=“0”9.168.5.5（内网）10.1.1（外网） 31:70176=”6”92.168.5.6（内网）101.16（外网） 32:2083:3003.4 存储服务（）服务器硬件、网络和操作系统规划设计1）服务器硬件规划要求服务器内存：至少：16G，32G标配,越大越好。硬盘存储空间：1T以上，非格式,越大越

17、好。不建议用磁盘阵列。服务器：至少4核以上，标配8核,核越多越好。网卡：千兆网卡，双网卡；2）网络规划要求服务器集群在一个独立的网段内。集群服务器用千兆交换机连接。3）操作系统 4位企业版操作系统,支持中文字符编码。A关闭文件系统/分区的选项在对应的分区项后面添加1 /3 1 11 4 1 2B.设置文件句柄k+,目前该配置已经集成到启动脚本中。* 6556 5536 6536C不要使用 （不要使用大内存页选项）c:iknowdocsharedatacur_work 大内存页参考:D.用 查看主机的信息。文件系统的选择 采用预分配的大文件来存储数据，我们推荐3系统内核版本网络上对6.33-31

18、 以及26.32 的表现持怀疑度， 而强力推荐.36G线程堆栈的尺寸默认的线程堆栈尺寸为0M,调整为1M,已经集成在启动脚本中。3.5版本规划设计版本号:2.0.3 64位。注:偶数的版本是稳定版,奇数是开发版，例如,.2开头的是稳定版（1.2.0 ,1.2. , 1.2.2 等等） ，1.3开头的开发版（. ， .3.1 ,1.3.2 等。36 存储服务（）运营监控规划设计4.方案实施. 实施步骤1）方案设计2）方案评审3）设计验证4）结论评估5）上线实施4.2 方案整体实施计划附件: 存储服务表（ ）结构设计1.实时数据存储集合（表）结构定义表名：。作用：用于存储车机实时上传数据,并供前端

19、应用查询和统计。具体表结构信息如下所示：编号字段名称中文对照别名字段类型是否索引备注1车辆A整数是时间B不包含时区3经度C偏移后的4纬度D5速度6方向7海拔高度G车辆状态9报警编码H报警编码子集合9.1S1紧急报警192S2超速报警93S3疲劳驾驶S.4S4预警S95S5导航模块故障9.6导航系统天线未接S9.7S导航天线短路S79.88终端主电源欠压S9.S9终端主电源掉电9.10S1终端显示屏故障9.1111语音模块故障S11.12S12摄像头故障29.13S13当天累计驾驶超时139.14S14超时停车S1151进出区域5.1S6进出路线S16.17S17路线行驶时间不足/过长18S18

20、路线偏移报警S1.1S车辆速度传感器故障199.20S20车辆油量异常S29.2121车辆被盗9.22S22车辆非法点火S29.2S23车辆非法位移S3.24S24碰撞侧翻报警S22525严重故障S59.26S6制动气压报警S2692S7油压报警S279.2S28水位低报警8.29S2制动蹄片磨损报警S99.3S3空滤堵塞报警S09.1S31缓速器高温报警信号92S3仓温报警信号29.33S3机滤堵塞信号39.334燃油堵塞信号9.35S机油温度报警信号S593S6燃油警告369.3S37空档滑行告警S39.38S8超长怠速告警38939S怠速空调告警S340发动机超转告警S409.S41急加

21、速报警S19.4242急减速报警S9.34门开报警S3.444冷却液温度过高报警S449.S45蓄电池电压报警49.46S4故障告警S469.7S47关键点报警10I原始经度11原始纬度12里程13累计油耗14发动机运行时长N5引擎转速O16位置状态位17区域/线路报警Q字符串18冷却液温度R1蓄电池电压S2瞬时油耗T1记录仪速度U2机油压力23大气压力W4发动机扭矩百分比X25车辆信号状态Y26系统时间Z建议：为节省实时数据的存储空间，我们建议采用英文首字符缩写方式来定义每个字段的名称，当然也可以用a、b、c、来表示每个字段的名称,这样的好处是节省存储空间,缺点是可读性差,但可以通过相关查询接口函数还原数据项可读性差的问题。2.报警历史数据存储集合（表）结构定义表名:用于车辆报警事件信息的集合（表）,包括报警位置、报警时间、报警附加信息、报警处理信息等。报警2车牌号当班司机编号报警开始时间E经度（起始位置）F1纬度（起始位置）G速度（起始位置）H1方向（起始位置）1