文章版权由做者李晓晖和博客园共有,若转载请于明显处标明出处:http://www.cnblogs.com/naaoveGIS/前端
该方案须要知足如下几点:数据库
支持人员当天轨迹快速获取(查询)。安全
支持轨迹高并发读、写(实际项目中轨迹高并发读状况不多)。微信
保证全部(历史)轨迹数据的完整性、不丢失。并发
海量数据高效存储、查询,这个场景自己是比较适合NoSQL数据库运用的,可是考虑到该方案实施的难度(对工程实施、维护、研发成本),仅仅为了解决轨迹而采用该方案不是一个最好的选择。高并发
这里,咱们引用日志的概念。设想将天天产生的轨迹以日志文本形式来存储,定义好日志的存储规则,那么咱们的轨迹查询将变化成轨迹日志文件的检索和解析,磁盘检索的效率将大大提升。性能
该方案涉及到的核心问题即是,轨迹日志的存储规则。spa
针对天天生成的轨迹创建一个以日期命名的文件夹,应该是能够确定的。日志
可是,在日期文件夹中,是针对每一个时段创建一个轨迹文件,仍是针对每一个人创建一个日志文件则是须要咱们进一步讨论的。blog
优势:
a.文件数量少,最多24个,若是保持住每一个时段的日志文件链接,写入操做高并发支持会很好。
b.针对以时间段查询、而且不分人员获取全部轨迹的场景,十分合适,适合GPS厂家的需求。
缺点:
a.咱们的运用场景更多的是查询单我的员当天的全部轨迹,若是按照这个规则,那么轨迹查询得遍历24个文件,还得解析各文件获取对应人员的轨迹。
优势:
a.很符合咱们的业务场景,每次单人单天轨迹查询时,只须要按照轨迹存储规则就能够获取到该人员的对应轨迹文件。
b.针对前端轨迹展现业务,能够将轨迹文件视作静态资源而进行静态伺服,前端直接访问解析。
c.针对后台进行轨迹分析,因为该文件大小很小,加载进入后台进行分析也没有IO瓶颈。
缺点:
a.因为人员通常会比较多,若是分人存储,假设有1000我的,那么等于有1000个日志文件。高频率对1000个文件分别进行写入操做,可能出现IO瓶颈。
通过认真分析,依然选择分天分人规则,缘由有如下几点:
a.符合咱们的业务场景运用。
b.针对高并发读有很大优点。
c.虽然理论上其有日志文件多、高并发写的劣势。可是这两点均可以进行避免。
日志文件多的问题:因为日志自己只是作记录使用,能够再制定一个定时清理的任务,好比一个月清理一次,那么即便1000我的,一个月3W个日志分布在30个日志文件夹,不是不能接受的。
高并发写的问题:即便咱们规定手机上报时间是5S,手机也并非一个实时写入的过程,而是还有一个批量上传的参数。因此其更多是两分钟或者更久批量上传一次数据,那么咱们后台读取文件、写入批量内容、关闭该文件,对IO的冲击会大大减少。而且,因为是不一样文件的操做,排队等待一个文件操做的问题也会大大减少。
针对咱们以前的历史轨迹表,应该继续保留。日志文件自己的安全性是不够的,若是出现误删除等问题,轨迹数据将很容易丢失。
因此历史轨迹表依然保存,按期作数据备份迁移。
目前的实时轨迹存储逻辑为,手机端批量上传GPS时,将该人员离上传时间最近的GPS点保存(saveorupdate)至tc_patrol_state表中。
该业务逻辑在多个已有项目中没有发现性能瓶颈,能够保留。
a.手机端上报轨迹,增长对轨迹日志文件的操做。
b.GIS端的前段轨迹展现、后台轨迹信息挖掘,作相应修改。
c.MIS端若是有跟轨迹表相关联的业务,须要作对应修改。
-----欢迎转载,但保留版权,请于明显处标明出处:http://www.cnblogs.com/naaoveGIS/
若是您以为本文确实帮助了您,能够微信扫一扫,进行小额的打赏和鼓励,谢谢 ^_^