轨迹系列——记某真实项目中轨迹存储改造方案

文章版权由作者李晓晖和博客园共有,若转载请于明显处标明出处:http://www.cnblogs.com/naaoveGIS/

1.    方案目标

该方案需要满足以下几点:

支持人员当天轨迹快速获取(查询)。

支持轨迹高并发读、写(实际项目中轨迹高并发读情况很少)。

保证所有(历史)轨迹数据的完整性、不丢失。

2.方案探讨详细描述

2.1支持轨迹快速查询——轨迹日志文件方案

海量数据高效存储、查询,这个场景本身是比较适合NoSQL数据库运用的,但是考虑到该方案实施的难度(对工程实施、维护、研发成本),仅仅为了解决轨迹而采用该方案不是一个最好的选择。

这里,我们引用日志的概念。设想将每天产生的轨迹以日志文本形式来存储,定义好日志的存储规则,那么我们的轨迹查询将变化成轨迹日志文件的检索和解析,磁盘检索的效率将大大提高。

该方案涉及到的核心问题便是,轨迹日志的存储规则。

2.2支持轨迹高并发读、写——轨迹日志存储规则定义

针对每天生成的轨迹建立一个以日期命名的文件夹,应该是可以肯定的。

但是,在日期文件夹中,是针对每个时段建立一个轨迹文件,还是针对每个人建立一个日志文件则是需要我们进一步讨论的。

2.2.1分时段记录优缺点讨论

优点:

a.文件数量少,最多24个,如果保持住每个时段的日志文件连接,写入操作高并发支持会很好。

b.针对以时间段查询、并且不分人员获取所有轨迹的场景,十分合适,适合GPS厂家的需求。

缺点:

a.我们的运用场景更多的是查询单个人员当天的所有轨迹,如果按照这个规则,那么轨迹查询得遍历24个文件,还得解析各文件获取对应人员的轨迹。

2.2.2分人记录优缺点讨论

优点:

a.很符合我们的业务场景,每次单人单天轨迹查询时,只需要按照轨迹存储规则就可以获取到该人员的对应轨迹文件。

b.针对前端轨迹展示业务,可以将轨迹文件视做静态资源而进行静态伺服,前端直接访问解析。

c.针对后台进行轨迹分析,由于该文件大小很小,加载进入后台进行分析也没有IO瓶颈。

缺点:

a.由于人员一般会比较多,如果分人存储,假设有1000个人,那么等于有1000个日志文件。高频率对1000个文件分别进行写入操作,可能出现IO瓶颈。

2.2.3规则总结

经过认真分析,依然选择分天分人规则,原因有以下几点:

a.符合我们的业务场景运用。

b.针对高并发读有很大优势。

c.虽然理论上其有日志文件多、高并发写的劣势。但是这两点都可以进行避免。

日志文件多的问题:由于日志本身只是做记录使用,可以再制定一个定时清理的任务,比如一个月清理一次,那么即使1000个人,一个月3W个日志分布在30个日志文件夹,不是不能接受的。

高并发写的问题:即使我们规定手机上报时间是5S,手机也并不是一个实时写入的过程,而是还有一个批量上传的参数。所以其更可能是两分钟或者更久批量上传一次数据,那么我们后台读取文件、写入批量内容、关闭该文件,对IO的冲击会大大减小。并且,由于是不同文件的操作,排队等待一个文件操作的问题也会大大减小。

2.3历史轨迹数据安全性、完整性——历史轨迹表用作备份

针对我们之前的历史轨迹表,应该继续保留。日志文件本身的安全性是不够的,如果出现误删除等问题,轨迹数据将很容易丢失。

所以历史轨迹表依然保存,定期做数据备份迁移。

3.针对实时轨迹存储的说明

目前的实时轨迹存储逻辑为,手机端批量上传GPS时,将该人员离上传时间最近的GPS点保存(saveorupdate)至tc_patrol_state表中。

该业务逻辑在多个已有项目中没有发现性能瓶颈,可以保留。

4.项目中原有逻辑涉及调整的部分

a.手机端上报轨迹,增加对轨迹日志文件的操作。

b.GIS端的前段轨迹展示、后台轨迹信息挖掘,做相应修改。

c.MIS端如果有跟轨迹表相关联的业务,需要做对应修改。

                         -----欢迎转载,但保留版权,请于明显处标明出处:http://www.cnblogs.com/naaoveGIS/

      如果您觉得本文确实帮助了您,可以微信扫一扫,进行小额的打赏和鼓励,谢谢 ^_^

                                      

时间: 2024-10-10 13:59:31

轨迹系列——记某真实项目中轨迹存储改造方案的相关文章

WPF Step By Step 系列-Prism框架在项目中使用

WPF Step By Step 系列-Prism框架在项目中使用 回顾 上一篇,我们介绍了关于控件模板的用法,本节我们将继续说明WPF更加实用的内容,在大型的项目中如何使用Prism框架,并给予Prism框架来构建基础的应用框架,并且如何来设计项目的架构和模块,下面我们就来一步步开始吧. 本文大纲 1.Prism框架下载和说明 2.Prism项目预览及简单介绍. 3.Prism框架如何在项目中使用. Prism框架下载和说明 Prism框架是针对WPF和Silverlight的MVVM框架,这

Java算法之递归打破及在真实项目中的使用实例

开心一笑 刚才领导问开发:"你觉得这个项目的最大风险是什么",开发说:"加班猝死" , 气氛尴尬了一分钟!!! 提出问题 1.递归算法简单复习 2.如何实现递归算法与真实项目接口??? 3.如何打破递归算法??? 解决问题 1.首先练习下网上一些递归经典题 1 package com.hwy.test; 2 3 /** 4 * 递归函数测试 5 * Created by Ay on 2016/7/2. 6 */ 7 public class RecursionTes

记一次项目中yaml文档引发的惨案 (#yaml文档格式#yaml中'-'的作用)

项目已经在收尾阶段了,然后老大让我去把dockerCompose.yaml文件中公用配置给抽取一下,就是说以后改配置啊什么的就可以直接在抽出来的公用变量里面改就行了, 不用一个模块一个模块地去改(我们这个项目是微服务项目,十多个模块),本来是个很没技术含量的活儿,但是呢,引发了一场切(diao)尸吊的话题,来看下原始的配置 文件: 看下官网的语法: 我抽取的: 然后当然就是报错啦, 再然后就是各种检查顺序啊,检查有没有空格的尝试,然后无果,我就和老大汇报说抽不了,如果能抽我切尸吊俩厘米,然后我老

记一次项目中的css样式复用

本文同步至微信公众号:http://mp.weixin.qq.com/s?__biz=MzAxMzgwNDU3Mg==&mid=401616238&idx=1&sn=3c6e965283c632e9035875be43e6a305&scene=0#wechat_redirect 二维码: 一直觉得css是一个不被重视,或者说是重视不够的饭后甜点.因为它太“简单”,门槛低,不能彰显或提升广大闷骚程序猿的逼格...一直都想聊聊css相关的一些杂碎.正好借最近的一次项目实践来侃侃

Android省市区三级联动滚轮选择(真实项目中提取出来的组件)

最近项目要做一个,类似淘宝手机客户端的,选择收货地址的三级联动滚动选择组件,下面是它的大致界面截图: 在IOS中有个叫UIPickerView的选择器,并且在dataSource中定义了UIPickerView的数据源和定制内容,所以用只要熟悉它的基本用法,要实现这么个三级联动滑动选择是挺简单的. 言归正传,今天讨论的是在Android里面如何来实现这么个效果,那么如何实现呢??? 相信部分童鞋首先想到的是android.widget.DatePicker和android.widget.Time

从真实项目中抠出来的设计模式——第三篇:责任链模式

一:现实场景 有时候在开发的过程中,我们经常会根据某个状态的值,写出很多的ifelse逻辑,比如拿项目里面的案例来说,如果当前发送的是彩信,此种状态需要如何给 实体赋值,如果是短信,邮件又是其他方式的赋值,等等此类,这种情况下一般会写出如下if判断,对吧,真实代码如下: 1 if (leaflet.CommunicationtypeEnum.HasFlag(CommunicationTypeEnum.邮件)) 2 { 3 //第三步:动态生成邮件模板 4 var styleInfo = Cach

记一次项目中的查询汇总

项目要实现查询汇总的功能,针对不同的分组实现不同的汇总.直接上图吧,直观一点.要实现的效果如下图所示. 设计思路:第一,先实现电业局,变电工区,运维站,变电所相同的列名称,能够合并的功能.第二,在合适的位置插入汇总行(即有总计的行). 实现方法,第一,相同的列名称合并的功能,很简单,设置要合并的列的列属性AllowMerge=true,并不总的GridView的AllowMerge设为true即可. 第二,主要难点在怎么实现汇总的功能.数据库中的获取的数据如下图所示: 数据说明: PERSONI

真实项目中VS2015中自建T4模板生成文件的使用

有可能许多小伙伴们发现,vs2015和2012的自带T4模板中的.tt文件改变非常之多,如果仅仅copyEF系统自己生成的模板文件,那可累了.以下是我自己整理的在2012和2015中都可以试用的代码. <#@ template language="C#" debug="false" hostspecific="true"#> <#@ include file="EF.Utility.CS.ttinclude"

从真实项目中抠出来的设计模式——第二篇:过滤器模式

一:实际场景介绍 我们在给用户做订单催付通知的时候,会有这样的一种场景,用户在系统后台设置一组可以催付的规则,比如说订单金额大于xx元,非黑名单用户,来自 哪个地区,已购买过某个商品,指定某个营销活动的人等等这样的条件,如果这时用户在淘宝上下了一个订单,那程序要判断的就是看一下此订单是否满足这 些规则中的某一个,如果满足,我们给他发送催付通知,这种场景是很多做CRM的同学都会遇到的问题,那针对这种场景,如何更好的规划业务逻辑呢? 二:普通的编程代码 在这里我们就不考虑多筛选条件下的性能,而只从代