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/

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