基于MongoDB物流流量分析性能优化研究.docVIP

基于MongoDB物流流量分析性能优化研究 　　摘要：MongoDB是一个开源的文档类型的，基于分布式文件存储的数据库，其在数据存储与分析方面较传统关系型数据库有明显优势。该文在物流订单轨迹流量分析方面进行了探索与相关实验，证明了MongoDB在此类型大数据处理方面具有优势。 　　关键词：MongoDB；物流流量分析；关系型数据库；大数据；性能优化；集群；分片 　　中图分类号：TP311 文献标识码：A 文章编号：1009-3044（2013）33-7627-04 　　目前随着网络信息化、电子商务和物流业的爆炸式发展，我们正加速进入数据快速增长的“大数据”时代，“大数据”已经在各方面对人们的生活带来深刻的影响。而传统的数据存储与分析技术在“大数据”时代也显得力不从心，“大数据”给IT产业带来了新的挑战和机遇。 　　1 概述 　　目前物流行业蓬勃发展，各大物流企业在热点时间段频频爆仓，大量快件滞留在始发站和中转站，给物流企业带来了非常大的管理压力，所以物流订单流量进行实时分析和非实时统计分析成为物流企业规划物流运力和仓储能力重要决策数据。而目前物流企业订单管理系统大部分基于传统关系型数据库，这对于订单跟踪目前还能胜任，但是对于海量的数据统计分析则显得力不从心。 　　1.1问题描述 　　一方面，物流企业的订单管理系统目前主要使用传统关系型数据库如Oracle，SQL Server等。在数据库中存放订单配送的主要数据包括以下两个方面： 　　1）订单的基本信息，包括订单编号、发件人信息、收件人信息、发货时间、发货地点、收货地点等信息。 　　2）订单配送过程的轨迹信息，在关系型数据库中会形成模式如（单号，出发地，到达地，出发时间，到达时间）的多条记录。例如一件物品从上海发往合肥客户，经由轨迹信息就是上海→昆山→南京→合肥。会形成（ID1，上海，昆山，Time1，Time2），（ID1，昆山，南京，Time3，Time4），（ID1，南京，合肥，Time5，Time6）三条记录。 　　由于订单数目巨大，形成的轨迹信息往往是数以亿计，甚至更多。对于统计在某段时间内容从地点A到地点B的总订单数等信息往往要等待很长时间，甚至对于更为复杂的统计分析讲无法给出查询结果。 　　另一方面，目前现有系统已普遍使用，不适合更换现有数据库，我们需要在不更换现有数据库的基础上提供相应的统计分析查询服务。 　　基于以上两方面问题，我们提出基于MongoDB的物流流量分析性能优化方案。 　　1.2 相关技术 　　MongoDB是一个开源的文档类型的，基于分布式文件存储的数据库。旨在为Web应用提供可扩展的高性能数据存储解决方案。MongoDB支持松散式数据结构bson格式，可以存储复杂的数据类型。可贵的是它的查询语言非常强大，可以适用于多种查询场合。 　　MongoDB具有面向集合存储、高可用、高性能的特点，且具备通过 shard模式支持横向扩展性，为大数据存储与处理奠定了基础。 　　2 方案设计 　　2.1处理流程 　　从图1我们可以看出方案处理场景主要包含三部分： 　　1）系统接入时从原Oracle数据库全量批量式导入订单及其轨迹信息进入分布式MongoDB数据库。 　　2）物流订单入库、出库、中转及配送的轨迹信息更新时增量记录于原Oracle数据库及MongoDB数据库。 　　3）物流流量分析人员基于MongoDB数据库内数据实时统计分析流量数据。 　　以上使用场景对MongoDB提出了具有良好数据写入性能和数据查询新能的要求。另一方面该使用场景对于数据的高可靠性没有较高要求，系统的写入和查询性能更为关键。 　　2.2MongoDB的数据写入性能分析 　　MongoDB的数据写入性能测试主要包含以下几个场景模式，包含单机与集群分片的性能比较。 　　2.2.1 正常模式数据写入 　　2.2.2 批量模式数据写入 　　2.2.3 安全模式数据写入 　　2.2.4 数据写入模式的选择 　　通过上述3种写入模式的分析我们可以看出，MongoDB的正常模式写入和批量模式写入具有较好的写入性能，但是批量模式并没有预期上比正常模式有更高的性能，主要原因在于写锁的存在，导致了并没有较好的性能提升。而安全模式为了保证数据的不丢失性，写入性能较差，考虑到我们的使用场景对于单条数据没有较高的数据可靠性要求，所以我们采用MongoDB的正常模式作为系统实现方案。 　　另一方面我们的订单数据是海量的且持续增长的，考虑到单机存在不能满足数据存储的要求，我们采用集群式的分片模式，这样在后期数据增长的情况下可以做到平滑扩容。 　　3 性能优化方案效果分析 　　基于以上方案我们设计实现了该方案，并针对千万级订单、亿级订单轨迹