论文部分内容阅读
摘 要：随着我国汽车数量的迅猛增长，城市拥堵、交通事故等交通问题日益凸显。以往人工现场查验和视频识别的方式获取信息效率低、信息利用率差，也难以支持涉车动态精确信息采集和管理。交通信息系统以交通数字化信息的整个流动过程为主线，综合采用多种先进技术为现有的交通问题提供了一种解决思路。然而，采用传统关系型数据库的系统无法满足海量交通信息的快速存储、高效分析的要求，为此本文给出了一种基于NoSQL的交通数据模型设计方案。
关键词：云计算；交通；NoSQL；MongoDB
中图分类号：G613文献标识码： A
The Design of Traffic Data Model Based on NoSQL
LiNing,ZhangQi*,LiuYucai
(Anticounterfeiting Dept,The 3rd Research Institute of Ministry of Public Security,Shanghai 201204,P.R.China)
Abstract：With the rapid growth in the number of cars in our country, city traffic problems, traffic accidents have become increasingly prominent. Manual inspection and identification efficiency of the previous way of video information is low, the bad utilization of information is also difficult to support the vehicle dynamic and accurate information acquisition and management. Traffic information system to the flow process of traffic information as the main line, using a variety of advanced technology provides a solution for the existing traffic problems. However, the system adopting traditional relational database can not meet the rapid storage, mass traffic information analysis performance requirements, this paper gives a design scheme of traffic data model based on NoSQL.
Keywords: cloud computing; traffic; NoSQL；MongoDB
引言
隨着人们经济收入的提高及汽车产业的迅速发展，我国在上世纪末跨进了“汽车社会”，至2012年底全国汽车保有量已超过1.2亿辆。我国汽车社会高速发展的同时，城市拥堵、假牌套牌车、肇事逃逸、交通事故、车险诈骗等各种影响社会和谐发展的问题正日益凸显。据零点研究咨询集团统计，2009年，北京每月平均人均拥堵成本335.6元，每月仅北京市的拥堵成本就高达60亿元。另据公安部统计，2010年开展的机动车涉牌涉证违法行为专项整治行动中，共查处347.3万起。长期以来，我国主要采用人工现场查验和视频识别的方式获取传统车辆信息。这种方式的主要问题是获取信息效率低、信息利用率差等。同时，传统系统难以支持涉车动态精确信息采集和管理，如车辆动态出行管理、城市区域拥堵收费、违法信息现场记录处置等，也难以满足多行业、多警种的个性化信息需求，各地政府和公安交通管理业务部门对此反映强烈。交通信息系统可以有效地利用现有交通设施、减少交通负荷和环境污染、保证交通安全、提高运输效率。它的突出特点是以信息的收集、处理、发布、交换、分析、利用为主线，为交通参与者提供多样性的服务。本文通过分析交通信息系统的应用环境与基本功能，建立一个基于NoSQL的交通数据模型。
1基于关系型数据库的交通信息系统所遇到的瓶颈
虽然关系型数据库在30多年的实践完善中已成长为成熟且具有稳固地位的数据库模式，但是由于其与生俱来的几个限制，令其很难满足交通海量数据需求，具体体现如下[1]：
1）难以承受大量数据同时写入：关系型数据库高并发的写入操作会让数据库不堪重负，当写并发达到上万次的时候，硬盘IO将无法承受。且每秒产生的信息量之大也使得增加多台主数据库进行互相关联复制的方法失效。
2）不易扩展：数据量的规模增加对服务器性能将提出更高要求，现行的集中式架构无法动态扩充，需要将应用整体迁移至更优的服务器来实现。如采用水平扩展，则要求程序员修改程序，必要时会停止服务。
3）读写速度慢：关系型数据库逻辑复杂，当系统数据量达到一定规模时，容易出现死锁等并发问题，导致其读写速度迅速下降。
4）支撑容量有限：目前还没有支撑类似搜索引擎的海量数据存储的关系型数据库解决方案。
5）建设成本高：关系型数据库对服务器性能要求高，且企业级数据库的许可证价格也较贵，系统具备一定规模时成本问题更加突出。
6）无法提供精确的决策依据：关系型数据库数据分析处理速度较慢，因此传统决策分析系统往往是从海量数据中提取大量样本数据进行分析,难以全面描绘整体运营状况。
云计算代表了信息领域规模化的方向，而许多互联网巨头公司也纷纷开发出用于云计算环境的新型数据库，包括谷歌的Bigtable,10Gen的Mongo等，这些被统称为NoSQL的数据库所具有的规模运算存储的特性使得其顺其自然成为交通信息系统的优先考虑方案之一。本文将使用时下用得较多的MongoDB数据库对交通数据模型进行设计[2]。
2数据模型需求
2.1数据模型功能
交通信息系统最基本的任务是解决城市道路交通拥堵问题，并为交通民警提供执法依据和便利手段，它还可开放接口为保险等行业提供服务。因此，交通数据模型主要有以下几点功能：
1）提供路段拥堵状况信息：通过分析通过路段车辆的速度判断该路段是否拥堵，可分为十分拥堵、拥堵、正常、畅通四个级别，并将信息快速提供给驾驶员和该区域负责的交警。
2）提供路段临时封堵信息：由于施工或保障特殊车辆的绿色通道而进行临时封路的信息要快速提供给驾驶员。
3）提供查询功能：可以追溯肇事车辆或嫌疑车辆的运行轨迹。
4）提供统计功能：可对特定车辆统计出它的运行规律和对各路段统计出事故或其它异常状况的频发程度，为交警及道路设计部门提供决策依据。
5）提供实时监控功能：交警部门可随时监控路段交通情况。
6）提供报警功能：当车辆超速或被列入黑名单的车辆出现在系统的车辆行驶记录中时，系统给予报警。
2.2其它非功能性需求
模型具有一定的抗破坏能力，能长期在安全、稳定的状态下运行，并在数据遭到破坏时能及时恢复，不影响系统的正常工作。
3数据模型设计
3.1架构设计
交通数据模型主要由MongoDB数据库和Web前端显示两部分组成。如图1所示。
图1 模型架构设计
MongoDB数据库以三种方式为Web UI显示提供数据。第一种直接以简单的查询方式，第二种采用MapReduce计算模型，即将大批量的工作（数据）分解（Map）执行，然后再将结果合并成最终结果（Reduce）。第三种对数据进行分析挖掘后进行显示[3] [4]。
在Web前端显示中，采用jQuery框架库。它与MongoDB都采用JSON数据格式，使得与MongoDB间的数据交互很方便，且jQuery在Web UI中具有强大的表现功能[5]。
3.2数据库设计
首先，MongoDB进行分布式存贮，其次做好异地容灾备份工作以确保系统可靠性。
数据库Collection结构设计则如下[6]：
1、过车记录（时间，地点，方向，车辆信息{车牌号，车牌颜色，车身颜色}，驾驶员信息{姓名，驾驶证号}，抓拍图片）
2、车辆信息（车牌号，车牌颜色，车主，车主联系地址，车主联系电话，车身颜色，发动机号,保险信息{交强险，盗抢险，车损险}，有效位）
3、驾驶员信息（姓名，驾驶证号，性别，家庭住址，联系电话，有效位）
4、黑名单(黑名单车辆或黑名单驾驶员姓名，标志黑名单车辆或驾驶员的标志位，布控时间)
5、异常事件（异常事件名称，发生地段,时间，车辆信息{车牌号1，车牌颜色1，车身颜色1; 车牌号2，车牌颜色2，车身颜色2……}，驾驶员信息{姓名1，驾驶证号1；姓名2，驾驶证号2}，抓拍照片）
6、封路信息（封路信息，信息发送范围）
7、路段负责交警信息（{交警姓名1，手机号1；交警姓名2，手机号2 }）
过车记录、异常事件Collection中的车辆信息字段和驾驶员字段及车辆信息Collection中的保险信息字段是复合字段，其中保险信息的内容根据实际情况可能有0项或多项，异常事件车辆信息和驾驶员信息为1项至多项。由于交警在查询过车记录时，时常先通过时间、地點、车牌号、车牌颜色、车身颜色或驾驶员姓名、驾驶证号确定嫌疑车辆或驾驶员，有详细了解的需要才会了解车辆详细信息，为了加快信息查找速度，过车记录、异常事件Collection中的车辆信息、驾驶员信息与车辆信息Collection和驾驶员信息Collection之间有数据冗余。
3.3实现流程
1、车辆信息、驾驶员信息、路段负责交警信息、黑名单由系统用户手动输入。
2、当车辆通过某信息采集点时，交通信息系统自动采集信息形成过车记录存储在数据库中。遇到黑名单车或黑名单驾驶员通过时，系统自动以声音和弹出窗口的形式报警。
3、当某地段发生交通事故等异常事件时，由执勤民警使用便携设备将异常信息写入系统数据库。例如，2013年05月06日9点30分民生路发生沪A12345（驾驶员张三，身份证310117197508072745）和沪H54321（驾驶员李四,身份证320115198606012821）两车相撞事故,则在数据库中新增一条异常事件记录（两车相撞，民生路，2013年05月06日9点30分，{沪A12345,蓝底白字，银白; 沪H54321,蓝底白字，黑},{张三,310117197508072745;李四，320115198606012821}，D:\科苑路抓拍照片\001.jpg）
4、系统每10秒对所有路段最后通过路口的两辆车进行路段车速判断，例如高科西路科苑路近10秒内最后通过的一辆车是沪A12345，它进入高科西路罗山路的时间是2013年12月8日13:46:00，通过科西路科苑路路口的时间是2013年12月8日13:50:00,两路口相距200米，则沪A12345通行速度为50米/分，同样对倒数第二辆车的车速进行计算，若两辆车车速都小于某个低速阀值，则判断该路段十分拥堵,系统自动生成拥堵信息并根据路段负责交警信息将拥堵信息发送到负责交警的手机上，也可同时通过显示屏在附近路口进行提醒显示，及通过交通信息服务网站显示。
5、封路信息可由系统用户手动输入，输入后将通过显示屏在附近路口进行显示并可通过交通信息服务网站显示。
6、系统提供车辆运行轨迹查询功能，输入车牌号和时间段后，车辆运行轨迹在地图上以反显色线段方式给出。
7、系统提供统计功能，比如每小时、每日、每周、每月、每年路口的车流量情况，使用MapReduce实现。并对车辆及路段情况进行数据分析,挖掘出过车记录中潜在的规律，例如某辆车在近几个月内经常经过银行门口前的某个路段。
8、系统提供实时监控功能，对路口进行实时视频监控，并显示最后一个过车的详细信息及抓拍图片。
9、过车记录、异常事件及实时监控功能可作为保险公司赔付的参考依据。
4总结
NoSQL的内在含义是Not Only SQL。在交通数据量和访问量逐渐增大的大背景下，将数据分离到不同的机器或者增加服务器数目，不是长久之计。采用新兴的NoSQL数据库，可以解决上述问题。本文设计的基于MongoDB的交通数据模型实现了大数据思想下交通信息系统的基本功能，但下一步仍需在实际交通背景中经受海量数据的考验，进行优化。
参考文献：
[1]Stonebraker,Michael.SQL Databases v. NoSQL Database[C] ASSOC COMPUTING MACHINERY,2 PENN PLAZA,STE 701,NEW YORK,NY 10121-0701 USA,ACM,2010
[2]Neal Leavitt.Will NoSQL Databases Live Up to Their Promise?[J]Computer.2010:12-14
[3]孙广中等.MapReduce模型的调度及容错机制研究[J].微电子学与计算机，2007,24（9）178~180
[4]姜文.基于Hadoop平台的数据分析和应用[D].北京：北京邮电大学，2011
[5]JQuery[EB/OL]http://jquery.com/
[6]MongoDB官方网站：http://www.mongodb.org
关键词：云计算；交通；NoSQL；MongoDB
中图分类号：G613文献标识码： A
The Design of Traffic Data Model Based on NoSQL
LiNing,ZhangQi*,LiuYucai
(Anticounterfeiting Dept,The 3rd Research Institute of Ministry of Public Security,Shanghai 201204,P.R.China)
Abstract：With the rapid growth in the number of cars in our country, city traffic problems, traffic accidents have become increasingly prominent. Manual inspection and identification efficiency of the previous way of video information is low, the bad utilization of information is also difficult to support the vehicle dynamic and accurate information acquisition and management. Traffic information system to the flow process of traffic information as the main line, using a variety of advanced technology provides a solution for the existing traffic problems. However, the system adopting traditional relational database can not meet the rapid storage, mass traffic information analysis performance requirements, this paper gives a design scheme of traffic data model based on NoSQL.
Keywords: cloud computing; traffic; NoSQL；MongoDB
引言
隨着人们经济收入的提高及汽车产业的迅速发展，我国在上世纪末跨进了“汽车社会”，至2012年底全国汽车保有量已超过1.2亿辆。我国汽车社会高速发展的同时，城市拥堵、假牌套牌车、肇事逃逸、交通事故、车险诈骗等各种影响社会和谐发展的问题正日益凸显。据零点研究咨询集团统计，2009年，北京每月平均人均拥堵成本335.6元，每月仅北京市的拥堵成本就高达60亿元。另据公安部统计，2010年开展的机动车涉牌涉证违法行为专项整治行动中，共查处347.3万起。长期以来，我国主要采用人工现场查验和视频识别的方式获取传统车辆信息。这种方式的主要问题是获取信息效率低、信息利用率差等。同时，传统系统难以支持涉车动态精确信息采集和管理，如车辆动态出行管理、城市区域拥堵收费、违法信息现场记录处置等，也难以满足多行业、多警种的个性化信息需求，各地政府和公安交通管理业务部门对此反映强烈。交通信息系统可以有效地利用现有交通设施、减少交通负荷和环境污染、保证交通安全、提高运输效率。它的突出特点是以信息的收集、处理、发布、交换、分析、利用为主线，为交通参与者提供多样性的服务。本文通过分析交通信息系统的应用环境与基本功能，建立一个基于NoSQL的交通数据模型。
1基于关系型数据库的交通信息系统所遇到的瓶颈
虽然关系型数据库在30多年的实践完善中已成长为成熟且具有稳固地位的数据库模式，但是由于其与生俱来的几个限制，令其很难满足交通海量数据需求，具体体现如下[1]：
1）难以承受大量数据同时写入：关系型数据库高并发的写入操作会让数据库不堪重负，当写并发达到上万次的时候，硬盘IO将无法承受。且每秒产生的信息量之大也使得增加多台主数据库进行互相关联复制的方法失效。
2）不易扩展：数据量的规模增加对服务器性能将提出更高要求，现行的集中式架构无法动态扩充，需要将应用整体迁移至更优的服务器来实现。如采用水平扩展，则要求程序员修改程序，必要时会停止服务。
3）读写速度慢：关系型数据库逻辑复杂，当系统数据量达到一定规模时，容易出现死锁等并发问题，导致其读写速度迅速下降。
4）支撑容量有限：目前还没有支撑类似搜索引擎的海量数据存储的关系型数据库解决方案。
5）建设成本高：关系型数据库对服务器性能要求高，且企业级数据库的许可证价格也较贵，系统具备一定规模时成本问题更加突出。
6）无法提供精确的决策依据：关系型数据库数据分析处理速度较慢，因此传统决策分析系统往往是从海量数据中提取大量样本数据进行分析,难以全面描绘整体运营状况。
云计算代表了信息领域规模化的方向，而许多互联网巨头公司也纷纷开发出用于云计算环境的新型数据库，包括谷歌的Bigtable,10Gen的Mongo等，这些被统称为NoSQL的数据库所具有的规模运算存储的特性使得其顺其自然成为交通信息系统的优先考虑方案之一。本文将使用时下用得较多的MongoDB数据库对交通数据模型进行设计[2]。
2数据模型需求
2.1数据模型功能
交通信息系统最基本的任务是解决城市道路交通拥堵问题，并为交通民警提供执法依据和便利手段，它还可开放接口为保险等行业提供服务。因此，交通数据模型主要有以下几点功能：
1）提供路段拥堵状况信息：通过分析通过路段车辆的速度判断该路段是否拥堵，可分为十分拥堵、拥堵、正常、畅通四个级别，并将信息快速提供给驾驶员和该区域负责的交警。
2）提供路段临时封堵信息：由于施工或保障特殊车辆的绿色通道而进行临时封路的信息要快速提供给驾驶员。
3）提供查询功能：可以追溯肇事车辆或嫌疑车辆的运行轨迹。
4）提供统计功能：可对特定车辆统计出它的运行规律和对各路段统计出事故或其它异常状况的频发程度，为交警及道路设计部门提供决策依据。
5）提供实时监控功能：交警部门可随时监控路段交通情况。
6）提供报警功能：当车辆超速或被列入黑名单的车辆出现在系统的车辆行驶记录中时，系统给予报警。
2.2其它非功能性需求
模型具有一定的抗破坏能力，能长期在安全、稳定的状态下运行，并在数据遭到破坏时能及时恢复，不影响系统的正常工作。
3数据模型设计
3.1架构设计
交通数据模型主要由MongoDB数据库和Web前端显示两部分组成。如图1所示。
图1 模型架构设计
MongoDB数据库以三种方式为Web UI显示提供数据。第一种直接以简单的查询方式，第二种采用MapReduce计算模型，即将大批量的工作（数据）分解（Map）执行，然后再将结果合并成最终结果（Reduce）。第三种对数据进行分析挖掘后进行显示[3] [4]。
在Web前端显示中，采用jQuery框架库。它与MongoDB都采用JSON数据格式，使得与MongoDB间的数据交互很方便，且jQuery在Web UI中具有强大的表现功能[5]。
3.2数据库设计
首先，MongoDB进行分布式存贮，其次做好异地容灾备份工作以确保系统可靠性。
数据库Collection结构设计则如下[6]：
1、过车记录（时间，地点，方向，车辆信息{车牌号，车牌颜色，车身颜色}，驾驶员信息{姓名，驾驶证号}，抓拍图片）
2、车辆信息（车牌号，车牌颜色，车主，车主联系地址，车主联系电话，车身颜色，发动机号,保险信息{交强险，盗抢险，车损险}，有效位）
3、驾驶员信息（姓名，驾驶证号，性别，家庭住址，联系电话，有效位）
4、黑名单(黑名单车辆或黑名单驾驶员姓名，标志黑名单车辆或驾驶员的标志位，布控时间)
5、异常事件（异常事件名称，发生地段,时间，车辆信息{车牌号1，车牌颜色1，车身颜色1; 车牌号2，车牌颜色2，车身颜色2……}，驾驶员信息{姓名1，驾驶证号1；姓名2，驾驶证号2}，抓拍照片）
6、封路信息（封路信息，信息发送范围）
7、路段负责交警信息（{交警姓名1，手机号1；交警姓名2，手机号2 }）
过车记录、异常事件Collection中的车辆信息字段和驾驶员字段及车辆信息Collection中的保险信息字段是复合字段，其中保险信息的内容根据实际情况可能有0项或多项，异常事件车辆信息和驾驶员信息为1项至多项。由于交警在查询过车记录时，时常先通过时间、地點、车牌号、车牌颜色、车身颜色或驾驶员姓名、驾驶证号确定嫌疑车辆或驾驶员，有详细了解的需要才会了解车辆详细信息，为了加快信息查找速度，过车记录、异常事件Collection中的车辆信息、驾驶员信息与车辆信息Collection和驾驶员信息Collection之间有数据冗余。
3.3实现流程
1、车辆信息、驾驶员信息、路段负责交警信息、黑名单由系统用户手动输入。
2、当车辆通过某信息采集点时，交通信息系统自动采集信息形成过车记录存储在数据库中。遇到黑名单车或黑名单驾驶员通过时，系统自动以声音和弹出窗口的形式报警。
3、当某地段发生交通事故等异常事件时，由执勤民警使用便携设备将异常信息写入系统数据库。例如，2013年05月06日9点30分民生路发生沪A12345（驾驶员张三，身份证310117197508072745）和沪H54321（驾驶员李四,身份证320115198606012821）两车相撞事故,则在数据库中新增一条异常事件记录（两车相撞，民生路，2013年05月06日9点30分，{沪A12345,蓝底白字，银白; 沪H54321,蓝底白字，黑},{张三,310117197508072745;李四，320115198606012821}，D:\科苑路抓拍照片\001.jpg）
4、系统每10秒对所有路段最后通过路口的两辆车进行路段车速判断，例如高科西路科苑路近10秒内最后通过的一辆车是沪A12345，它进入高科西路罗山路的时间是2013年12月8日13:46:00，通过科西路科苑路路口的时间是2013年12月8日13:50:00,两路口相距200米，则沪A12345通行速度为50米/分，同样对倒数第二辆车的车速进行计算，若两辆车车速都小于某个低速阀值，则判断该路段十分拥堵,系统自动生成拥堵信息并根据路段负责交警信息将拥堵信息发送到负责交警的手机上，也可同时通过显示屏在附近路口进行提醒显示，及通过交通信息服务网站显示。
5、封路信息可由系统用户手动输入，输入后将通过显示屏在附近路口进行显示并可通过交通信息服务网站显示。
6、系统提供车辆运行轨迹查询功能，输入车牌号和时间段后，车辆运行轨迹在地图上以反显色线段方式给出。
7、系统提供统计功能，比如每小时、每日、每周、每月、每年路口的车流量情况，使用MapReduce实现。并对车辆及路段情况进行数据分析,挖掘出过车记录中潜在的规律，例如某辆车在近几个月内经常经过银行门口前的某个路段。
8、系统提供实时监控功能，对路口进行实时视频监控，并显示最后一个过车的详细信息及抓拍图片。
9、过车记录、异常事件及实时监控功能可作为保险公司赔付的参考依据。
4总结
NoSQL的内在含义是Not Only SQL。在交通数据量和访问量逐渐增大的大背景下，将数据分离到不同的机器或者增加服务器数目，不是长久之计。采用新兴的NoSQL数据库，可以解决上述问题。本文设计的基于MongoDB的交通数据模型实现了大数据思想下交通信息系统的基本功能，但下一步仍需在实际交通背景中经受海量数据的考验，进行优化。
参考文献：
[1]Stonebraker,Michael.SQL Databases v. NoSQL Database[C] ASSOC COMPUTING MACHINERY,2 PENN PLAZA,STE 701,NEW YORK,NY 10121-0701 USA,ACM,2010
[2]Neal Leavitt.Will NoSQL Databases Live Up to Their Promise?[J]Computer.2010:12-14
[3]孙广中等.MapReduce模型的调度及容错机制研究[J].微电子学与计算机，2007,24（9）178~180
[4]姜文.基于Hadoop平台的数据分析和应用[D].北京：北京邮电大学，2011
[5]JQuery[EB/OL]http://jquery.com/
[6]MongoDB官方网站：http://www.mongodb.org