信息查询处理（精选9篇）
信息查询处理 篇1
信息查询是管理信息系统必备的基本功能, 信息查询操作则是管理信息系统最常见的基本操作之一。在B/S模式下, 信息查询功能实现的基本原理与操作步骤是:①用户在浏览器端填写查询表单, 以确定待查找信息所应满足的条件;②用户通过单击“查找”按钮 (或功能类似的按钮) , 将查找信息的请求提交到服务器端;③服务器根据查找请求在相关数据库表中搜索符合条件的记录或信息, 并进行相关处理;④服务器将搜索与处理的结果传送至浏览器端, 供用户浏览。基于Web的信息查询功能的设计和实施, 主要是针对相关数据库和数据表设计信息查询表单界面及信息查询处理网页对应的程序代码, 并将相关的文件保存在主目录或与某个虚拟目录对应的实际目录下。这样, 用户就可以利用浏览器软件运行相关网页代码, 以执行相应的查询操作。
1 数据库与数据表的结构
信息查询是对已存在数据库表中的记录或数据进行查询, 所以信息查询设计的前提是掌握相关数据库的类型及数据表的结构。对会计科目查询设计而言, 就是要弄清楚账务处理数据库中会计科目数据表的结构。假定账务处理数据库和会计科目数据表是利用Microsoft Office Access建立的, 账务处理数据库的文件名为zwcl.mdb, 会计科目数据表名为kjkm, 并假定kjkm数据表的结构如表1所示, 表内已保存了相关会计科目的记录。
2 查询表单界面及相关网页代码设计
2.1 查询表单界面与查询请求
查询界面可设计成不同的形式, 但应满足简明、易用、美观等界面设计原则, 并尽可能提供较多的检索途径。本文所设计的会计科目查询界面如图1所示, 其中待查询的项目可从下拉列表框中选择, 包括与kjkm数据表中的字段相对应的选项, 分别为科目编号、科目名称、借贷方向、期初余额, 默认的选项为“科目名称”。从下拉列表选择相应的项时, 在待查询的值所对应的区域可输入与待查询的项目对应的数据, 若单击“查找”按钮, 应能够将表单界面上的数据所对应的查询请求传递到服务器进行相关处理 (例如, 选择待查询项目为“科目名称”, 输入待查询值为“现金”, 则单击“查找”按钮时, 就会将查询“科目名称”为“现金”的请求传递到服务器进行处理) ;若单击“重填”按钮, 则可使表单重置为如图1所示的界面, 以便于继续选择待选查询项目和输入待查询的值。
2.2 查询界面对应的网页代码
可以利用UltraEdit、EditPlus或Windows操作系统中自带的“记事本”等任一文本编辑软件, 建立会计科目查询界面对应的网页文件AccountItemSearch.htm, 并将该文件保存在计算机硬盘的一个实际目录下, 再在“Internet信息服务”控制台中将该实际目录设置为虚拟目录kemu。文件AccountItemSearch.htm中的网页代码对应如下:
2.3 查询界面网页代码的有关说明
文件AccountItemSearch.htm所述代码的运行结果是如图1所示的信息查询界面。其中,
标记对之间的代码定义了一个表单,
参考文献
[1]李国红.基于Web的会计科目输入处理的设计与实现[J].中国管理信息化, 2008 (13) :4-8.
[2]陈建伟, 等.ASP动态网站开发教程[M].第2版.北京:清华大学出版社, 2005.
信息查询处理 篇2
交巡警一大队金水区东明路顺河路向西150米路北
交巡警二大队中原区中原西路119号
交巡警三大队二七区铭功路116豫港大厦北
交巡警四大队管城区紫荆山路与金城街向东100米路南交巡警五大队金水区丰庆路与国基路交叉口向北100米路西交巡警六大队郑东新区东风东路与熊儿河路交叉口西200米交巡警九大队河医立交桥转盘建设东路方向东50米路北郑少高速交警大队郑少高速郑州西南收费站右侧院内
信息查询处理 篇3
关系数据库系统不仅在最初预期的商业环境,而且在许多结构化数据如个人的、社会的,甚至科学信息等其他领域中得到普遍的应用[1]。然而,因为数据的创新和使用通过WEB网络,移动手机和其他技术变得越来越大众化,科学技术的限制越加明显。关系数据库管理系统对它们存储的数据做了几个关键的关于正确性、完整性和无歧义性的假设。当这些假设不被赞成,相关的系统会对用户的请求返回不正确的和不完整的应答,如果它们返回任何应答的话。
在关系数据库模型中,主要包括查询操作和插入、删除和修改操作两大部分。其中,因为关系的查询表达能力很强,是关系数据库操作中最主要的部分。然而,传统关系数据库中存储的数据都是结构化的,其查询也多为精确匹配。当数据库中所存信息不完整或需语义理解时,数据库常会对查询返回一个错误的应答。因此,仅仅依靠机器是不能应答所有的查询的。处理这些查询需要人的输入,以提供丢失的信息或加入人的判断。
现有的两种明显的状况是,数据不完整或需要对语义进行分析理解时。其中,数据不完整即信息的缺失。例如查询:
Select*from Student
Where name=”Wang Fan”;
会返回一个空的应答,如果在当时的数据库中,Student表中不包含一个“Wang Fan”的记录。这样一个记录的缺失,原因有多种:
1)遗漏。当录入Student表信息的时候,可能由于人为的输入而造成遗漏;
2)删除。可能在某些操作过程中,无意中删除了这一记录;
3)输入有误。如在本例中,“Wang Fan”这一记录,有可能被错误的输入为“Wang Fen”。
另一个问题是需要对语义进行分析理解时,例如查询:
Select*from SS
Where name=”CS”;
会返回一个空的应答,如果在当时的数据库中,“CS”被输入为“Computer Science”。对于人来讲,能够快速识别“CS”和“Computer Science”在现实世界中指的是同一实体,但对于机器而言,却无法进行识别。这其实也是判断的一种。另一种判断是,如查询:
Select idea from paper
Order By practical LIMIT 5;
找到5个最具实践性的想法,传统的关系数据库系统无法应答这样的查询,除非关于这些想法的实践性已经事先获得并存储在数据库中。
以上这些查询仅仅通过机器是不能被应答的,但可以容易的被人所应答。机器和人各有所长,因此,通过引入众包,来借助人的网络去完成不适合计算机执行的任务,从而有效的扩展传统关系数据库系统的信息处理能力。
2 众包
2.1 众包
众包是继长尾理论后又一重要的商业概念,近年来得到广泛的关注。众包(crowdsourcing)这一概念是由美国《连线》杂志的记者杰夫·豪(Jeff Howe)在2006年6月提出的[2]。杰夫·豪对“众包”的定义是:“一个公司或机构把过去由员工执行的工作任务,以自由自愿的形式外包给非特定的(而且通常是大型的)大众网络的做法。具有低成本生产、联动潜在生产资源、提高生产效率,以及满足用户个性化需求等优势。
自众包概念提出以来,学术界对众包的定义一直没有公认的统一的界定。但是,从学者们对众包的概念分别从大众、企业、外包以及价值等多角度所进行的界定,我们可以总结出众包的基本特征:
1)通过公开的方式来召集网络大众;
2)众包任务一般是计算机单独难以完成的工作;
3)大众通过协作或者独立的方式完成任务;
4)是一种分布式的问题解决机制。
2.2 众包的工作流程
众包的参与者主要有任务请求者[3],众包平台以及任务完成者。任务请求者需要通过众包平台来完成自己的任务,其工作流程为:
1)产生任务;
2)通过众包平台发布任务,等待任务的答案;
3)拒绝或接受任务完成者的答案;
4)整理任务完成者所返回的答案,完成自己的任务。
任务完成者的工作流程:
1)查找任务;
2)接受任务;
3)执行任务;
4)提交答案。
其具体流程如图1所示:
2.3 众包应用于关系数据库系统
人类擅长某些特定的任务(如图像识别),但相对而言不擅长其他的一些任务(如数值计算)。同样,机器也有擅长与不擅长的工作。因此人和机器的能力可很好的相互补充。通过在传统的关系数据库系统中引入众包,可以很好的应答关系数据库系统无法应答的查询。
现有的微任务众包平台如亚马逊的土耳其机器人(AMT)[4]可以使人们以一种随需应变的方式来访问众包。这个平台提供基础设施,连通性和支付机制,允许成千上万的人在互联网上进行有偿工作。它提供了一种请求和管理工作的应用程序界面,其中任务请求者提供任务,工作者接受和执行任务。在我们这个基于众包的混合数据库系统中,通过使用一小部分请求人机输入的运算符来扩展传统的查询引擎,从而更好的使用这个平台。
3 基于众包的数据库信息查询处理方法
在基于众包的数据库信息查询处理系统中,我们采用人机结合的处理模式,并采用类SQL语句来进行查询处理。
3.1 数据库系统的体系结构框架
图2展示了基于众包的数据库系统的体系结构的总体框架[5]。如果可能的情况下,会首先使用存储在本地表格的数据去应答查询,否则会调用众包。也即我们图中的机器可自动完成的传统数据库部分和需要人工输入的人工部分。如果传统机器数据库部分可以正确应答,则查询返回结果;否则,使用人工部分来调用众包,并且将通过众包所获得的数据存储在数据库中以便在未来的使用中无需重复操作。
如图中中间的传统数据库部分所示,众包数据库合并了传统数据库的解析器、优化器和执行部件,这些部件被扩展到处理人为的输入。在图中右半部分,是与众包平台相互作用的新部件。
工作关系管理器,在众包的使用中涉及人类工作者,与计算机处理器不同,因此众包工作者是不可代替的资源,并且任务请求者与任务工作者的关系会随着时间而发生改变,所以应注意培养和维持一个有效的工作池。工作关系管理器模块协助请求者及时的支付工人工资、发放奖金和报告并应答一些工人的意见。从长远来看,在改进结果质量,更好的反应时间和更低的代价方面起到很重要的作用。
与物理IO请求相比,众包的接口数据由自然语言的HTML表单和指令组成。Crowd DB用可获得的数据库模式信息生成HTML表单。这三个组件,UI设计,表格编辑器,UI模板管理器,负责创建、管理和编辑用户界面模板。
任务管理器提供了一个抽象层,它管理混合数据库与众包平台之间的交互。它实例化用户界面,使应用程序界面发布任务,评估他们的地位,并获得结果。任务管理器也与存储器进行交互,获取值预先加载到用户界面,并最终存储来自众包的应答结果。
3.2 类SQL语句
在基于众包的数据库系统中,由于众包的引入,在对数据库进行操作时,我们采用SQL语言的一个小的扩展即类SQL语句[6]。类SQL语句与SQL语句的编写代码以基本相同的方式。即在大多数情况下,开发人员不需要知道他们的代码涉及众包。
对于传统数据库中数据不完整而导致查询错误的情况,有两种处理方式。第一,元组的特定属性可以被众包。第二,整个元组可以被众包。通过在SQL语言中添加关键字CROWD,即可完成这两种情况的处理。
例1:众包某一属性:在本例中的院系表中,URL属性被标记为众包。这种模型适合于新的院系自动生成时,其中,URL常不提供但可在其他的地方获得。
例2:众包表:本例中模拟一个教师名单为一个众包表。这个例子对于人们只希望代表性的获得一个部分的教师的子集是适用的。即,如果要求处理特定的查询,那么众包数据库需要通过众包增加更多的教师。
为了表示众包列中还没有获得的值,类SQL语言扩展了SQL语言中的NULL为CNULL,它与NULL等价,用于表示当第一次使用它的时候该值应该被众包。另外,删除和更新语句在类SQL语句中没有改变。而对于查询语句,允许两个众包表格的连接和子查询。
除了找到不完整的数据,在基于众包的数据库系统中,另一个主要的应用是客观的进行比较。为了支持这种函数的功能,众包数据库新建了两个函数Crowdequal和Crowdorder。Crowdequal有两个参数(左值和右值),并访问Crowd去决定两个值是否相等。正如语法所说的,使用~=和一个插入表示法。正如在下列中显示的:
例3:当需要查询关于“CS”的所有信息时,可形成包含“~=”符号的查询,在数据库中,查询的编写者用可能的计算机科学的名称去请众包平台来进行解析。
Select*from SS
Where name~=”CS”;
当排序或整理结果需要众包时,会用到Crowdorder。如以下例子:
例4:当需要查询最具实践性的5个想法时,可通过Crow⁃dorder来实现。
当完成这些查询时,其结果将会被存储在数据库中,以便众包被相同的查询只访问一次,从而提高系统的效率。
4 结束语
本文中,数据库和新兴的众包技术是我们研究的重要领域。基于众包的数据库信息查询处理方法的提出,很好地解决了传统数据库系统中无法应答的查询请求,有效的扩展了数据库系统的信息处理能力。人机结合来处理问题是未来应该关注的重要发展方向,具有很好的应用前景。
摘要：为解决传统数据库系统中,数据不完整或需语义理解时系统返回错误应答的问题,提出了基于众包的数据库信息查询处理方法。研究给出了基于众包的数据库系统的体系结构框架,并给出适用于该系统查询的类SQL语句,有效提高了数据库系统的信息处理能力。
关键词：众包,数据库系统,SQL语句,类SQL语句
参考文献
[1]Franklin M,Kossmann D,Kraska T,et al.Crowd DB:AnsweringQueries with Crowdsourcing[C].In SIGMOD,2011:61-72.
[2]HOWEJ.The rise of crowdsourcing[J].Wired Magazing,2006,14(6):176-183.
[3]冯剑红,李国良,冯建华.众包技术研究综述[J].计算机学报,2014,37(106):1-16.
[4]Feng M,Franklin D,Kossmann T,et al.Crowd DB:QueryProcessing with the VLDB Crowd[C].Proceeding of the VLDBEndowment,2011,12(4).
[5]Trushkowsky B,Kraska T,Franklin M J.A Framework for Adap-tive Crowd Query Processing[C].AAAI,2013.
网站信息查询工具精选 篇4
Just-Ping.com是一个全面的网站可连接性探测服务。它可以从世界上26个不同的地点连接制定的网站，并显示每个地点访问该网站的速度以及丢包率。其中有一个地点是上海，所以也可以用它来检测网站是否被墙。
WhoIsTheOwner.net是一个聚合式的Whois服务，它可以从全球350多个Whois服务器上获取网站的注册及注册人信息。
YouGetSignal.com这个工具可以帮你查询某一个网站所在的服务器上还有哪些其它的网站。很多时候，对于危险网站会使用IP封锁，通过它你就可以知道自己网站有没有被殃及可能。用它我们也可以从一个侧面了解服务商是否提供了优质的服务，一个放置了成千上万个网站的服务器很难让人放心。
WhoIsHostingThis.com可以告诉你，网站所在的服务器属于哪家公司，
如果你想知道一个网站的服务器和带宽是由谁来提供的，就可以用它来查询。
SocialMeter.com可以同时查询网站在Del.icio.us、Digg、Furl、Google、Reddit、Spurl、Technorati、Yahoo My Web等服务中被连接的状况，便于从一个侧面了解网站的流行程度。
Popuri.us的作用和SocialMeter差不多，所查询的数据中包括了Google PageRank、Alexa排名、Compete排名、搜索引擎反向链接数、Bloglines订阅数、Whois、DNS等信息。
BuiltWith.com是一个非常强大的网站技术信息查询及分析工具。它可以分析的网站信息非常全面，包括网站代码的基本SEO信息、通过XFN及FOAF链接到网站的其它网页、网站所使用的第三方统计服务、网站所安装的Widget、网站所使用的内容发布工具、网站所使用的编程语言、网站的广告服务商、为网站提供内容的其它服务、网站支持的同步服务、网站的编码等等。一个网站几乎所有的技术细节都可以用BuiltWith查到。
信息查询处理 篇5
近年来,一些数据密集的应用已经广为人知,这些应用中数据的到达非常快速,并且会随时间而变,甚至可能是无法预测的,数据量看起来也是无界的,这样的应用例子有:金融应用、网络监测、安全、通讯数据管理、Web应用和制造和传感网络等。这些应用中,数据源会不断地产生出大量的数据,比如股票交易中,股票的交易数据会不断涌入,这种类型的数据应该被视为易逝的数据流[1]。
在数据流模型中,不支持对部分或全部数据的随机访问,而是以持续数据流的形式到达。概括地说,与传统存储关系模型不同,数据流主要有如下几个方面的特征:
实时性数据流中的数据元素是在线到达的,并要求对它的处理也是近乎实时的;
无序性系统无法控制将要处理的新到达的数据元素的顺序,不论是对一个数据流还是在多个数据流之间;
无穷性流式数据本身就意味着数据量的无限大,而系统存储的数据相对数据流大小则是非常有限的;
瞬时性流中的数据一旦经过处理,要么被丢弃,要么被归档存储。但被丢弃的数据元素可能需要再次被访问。
时序性数据流模型中查询是相对静止不变的,而数据是时刻变化的。
对持续数据流的查询和对传统数据库的查询类似,但数据流模型下的查询具有两个一般数据库系统所没有的特点:
第一个特点是存在一次性查询和持续查询的区别。一次性查询是根据某个时间点数据集的状态计算查询结果,再把结果返回给用户。传统的数据库管理系统(DBMS)查询通常都属于一次性查询。相反,持续查询是在数据流持续到达情况下的持续计算。在数据流模型下,持续查询比一次性查询更普遍,持续查询的答案是基于时间的,它反映了到目前为止已到达的数据流的情况。当新的数据到达时,持续查询的结果可以被存储或更新。有时候查询结果本身也可表现为持续的数据流。数据流模型下一次采用一次性查询还是持续查询,得根据具体应用环境确定。例如,需要多次执行,但每次执行只产生少量的查询结果的聚集查询适合存储数据库模型下的一次性查询;而连接查询往往只需执行一次,但执行一次需要很长时间,并且产生持续的、海量的查询结果,更适合使用数据流模型下的持续查询。
第二个特点是存在预定义查询和特定查询的区别。预定义查询是指在任何相关数据到达前就已经提交给数据流管理系统的一种查询。虽然一次性查询也可以被预先定义,但预定义查询通常是持续查询。与此相反,特定查询是指在数据流已经到达后的在线查询。由于特定查询不能提前预知,因此无法找出不同查询间的公共子表达式从而对查询进行优化;计算特定查询有时需要引用数据流中历史的数据元素,而这些数据很可能已经丢弃了。
此外,传统数据库查询的数据对象是相对稳定的,至少在查询进行的过程中被认为是不变的;而数据流查询的数据对象则不断的变化,持续增长。传统查询执行的过程中可以利用索引、排序或分类等技术对数据对象进行随机存取,查询执行的次数完全取决于应用系统;而数据流查询对于持续输入的数据流只能采取线性扫描算法,在数据对象过期之前进行有限次数的查询[2]。
由于数据流在容量上可能是无限的,为了计算数据流查询的精确结果,所需的存储器容量也会无限制地增长。传统的处理数据集的算法不适合于数据流应用系统,因为它不支持持续查询。由于存储器的容量是有限的,对无限的数据流查询就不可能总是产生精确的结果,用高质量的近似结果来替代准确结果往往是可以接受的。数据流问题的近似算法在近年来已成为一个富有成效的研究领域,这其中高效查询的优化处理就成为其中的一个热点。
1 优化处理算法模块设计
当前数据流系统中存在如下几个显著的特征[3]:
(1)DS系统中存在着大量的查询,系统应该尽快地找到关心该数据的查询。
(2)对单个查询而言最优的查询计划未必对全局来说是最优的。
(3)大量查询中存在着的共同特征,查询分组技术已经在传统DBMS和一些DSMS中被证明为一种非常有效的技术。
(4)数据流系统的执行效率不仅和输入数据的速率有关,还和系统中算子的数量有关,和实际引发的查询的数量有关。如何尽量减少系统中存在的活动算子的数量也是优化需要考虑的一个问题。
基于此,设计优化模块时提出的基本目标就是:充分利用查询之间的共同特征,尽可能在查询之间实现共享;另外,调度器采用高效的调度算法使得运行时的开销最小;追求系统整体性能的提高[4]。
优化处理算法模块的组成结构如图1所示。
图1中查询优化的输入是解析后的查询树。DSMS以访问内存数据为主,且查询的数量非常庞大,因此DSMS系统的主要优化方向是减少DSMS系统中实际引发的查询的数量。连接运算代价非常大,因此DSMS将连接运算向下压,先进行连接运算,多个查询共享一个连接运算,减少了实际引发的连接操作的数量。因此,优化处理模型中的优化首先对连接进行分组,以便较大程度地在不同的连接之间共享中间结果,节约了DSMS系统中最为宝贵的主存资源。完成连接分组后,再对谓词进行分组,将相同结构的谓词组织在一个表结构中,这样实际引发的查询的数量就会大大减少[5]。
2 基于连接谓词约束的等值连接分组算法
目前为止,虽然对连接查询提出了大量的优化算法,但是针对多查询优化的连接分组优化算法却未见应用于数据流系统中,这里实现的是基于连接谓词约束的等值连接分组算法。
2.1 连接分组算法设计
连接分组的输入条件是Get Table Link中的表列和Get Where中的等值连接条件。输出结果是网络节点。如果一个节点表示一个用户查询的话,则就称该节点为终端节点,在用户明确地将查询删除以前,终端节点是不能删除的,与之相对应的是非终端节点,非终端节点没有对应的用户查询,只是保存连接的中间结果,当连接计划改变后非终端节点可能会被删除。我们的连接分组连接结果都只是增加一个基本表(流),采用类似System R优化器的结构,也特别适合流水线处理,而对于数据流来说,所需的处理方式正是流水处理方式。
基于连接谓词约束的等值连接分组算法中,连接运算的优化分为两个阶段;第一阶段为增量分组阶段;每当一个新的查询提交后,系统查找当前存在的分组,检测是否存在一个分组与新提交的查询对应,如果存在则不用创建任何分组,只需要把这个分组的引用次数加一即可;如果不存在则需要创建新的分组与这个查询对应,新的分组可以利用已经存在的分组作为自己实现的一部分。
连接运算查询优化的第二阶段为动态重分组阶段;增量分组对新加入的查询进行分组而不对存在的查询进行重分组,尽管这种查询也是有效的,可扩展的,但是它可能导致只是局部的优化,已经存在的查询没有在新查询加入时为了适应新的全局优化要求而获得重新分组的机会。
随着增量分组的进行,系统中创建了很多分组,但是对当前存在的所有查询来说,有一些分组是不必要的,或者说是冗余的,冗余分组的计算消耗了系统很多资源,因此应该动态地把这些冗余分组删除,重新创建系统的分组图,使系统尽可能地达到全局最优。
2.2 连接分组算法实现
2.2.1 基本数据结构
所有的连接节点在逻辑上是一个有向无环图,图中的每个节点都代表一个分组计划中的一个连接表达式,该节点的结构为:
2.2.2算法表示
1)增量分组Increment Group
输入:int tableids,连接约束A(目前实现的是等值连接),inttime＿t。
输出:目的节点。
示意代码实现如下所示:
该算法的过程是:
Find MaxGroup:用于找到输入的连接对应的最大连接分组,输入是表列tableids和连接约束条件,以及时间窗口。连接的中间结果都是通过索引结构记录下来,因此,Find Max只需按照哈希表的长度由大到小地遍历哈希表即可,一旦找到就停止。由于,目前为止我们规定表的最大长度为10,因此这一步的开销并不是很大。另外,目前的连接约束条件只包含等值连接,只有符合约束的连接才会被用到。
Get Constraint:得到节点B的连接约束条件,B是A的一个子集。
Get Left Table Id:得到剩余表的列表。
Ramdom Join:利用约束条件Left Constraint在node和剩下的表列随机生成连接结果(也可以按照刷新频率由小到大的次序选择基本表)。
2)动态重分组Re Group
当系统经过一段时间时,查询有的是新加入的,有的则运行一段时间后便从系统中注销,因此这时候系统的状态不一定是最优的。因此,运行一段时间后就需要对系统进行重新分组。
输入:不同长度的哈希表。
输出:重新分组优化后的查询网络。
动态重分组中,首先按照长度从大到小的规律遍历哈希表,因为终端节点是不能删除的,因此首先检查每个终端节点,如果该终端节点的父母节点的孩子节点不是此终端节点,就用子节点代替这个孩子节点,代替的过程同时检查约束条件,只有符合约束条件才能替代。检查完终端节点后,再检查非终端节点,如果发现非终端节点的引用计数等于零,就将其删除,因为已经没有父母节点引用该节点的结果了。
由于动态重分组每次都遍历哈希表,因此代价很高,可以在系统空闲的时候进行这个操作。
3 谓词分组算法
谓词分组技术在很多系统中都有应用[5],将具有相同结构的过滤条件组织在一起(通常采用索引),当数据到来时,对该分组进行过滤操作,使用高效的组织手段,因此分组过滤操作执行效率可能会比较高(相对于单独执行时)。
Argus系统中谓词分组的输入是连接分组的结果网络节点和查询解析器解析的Wheres子句的内容,它将结构相似的谓词组织在一个称为常数表的结构中,当数据到来时查找该常数表,然后找到其目的节点。
下面我们讨论一下谓词的标记以及常数表的结构和基于常数表的连接算子。
3.1 谓词的标记
为了更简便,我们以下面的两个查询为例子来说明谓词的标记:
查询1:
我们比较一下这两个查询,两者的其它部分都相同,唯一不同的就是选择常数一个是pku,另外一个是nju。我们称这两个查询的标记相同。谓词的标记由下面几个部分生成:数据源,关系操作符。
3.2 常数表结构
常数表就是存放相同查询标记的查询常数值的一个结构。常数表的结构如表1所示。
常数表的第一列是常数值,第二列是引用次数,比如可能有两个查询的常数值是“云计算”,这个“云计算”的引用次数是3,第三列是目的算子的地址。
3.3 算法实现
在对数据流管理系统模型进行多查询优化时,预先对数据流进行连接,其实现如图2所示。
图2中每条数据流都有多个谓词分组,一个谓词分组对应一条或多条(有部分重复的)查询。再通过这些谓词分组生成查询计划,使整体代价较小,并且记录或删除查询不需要更改其它查询的谓词分组[6]。
算法的实现包括查询的更新和撤销两部分。算法的更新查询部分复杂度为O(n×m3),其中n为两流之间最大的不同连接因子数,m为数据流的查询连接数。而算法的撤销部分复杂度为O(m)。由于参与连接的数据流一般不会太多(少于10条),所以记录和撤消查询的算法复杂度是可接受的。
谓词分组算法的过程是:首先根据pre＿node和pre＿node的谓词找到对应的常数表,用哈希表保存常数表的地址,因此查找的速度通常会很快。如果没有对应的常数表,则创建一个常数表Create Table。然后在该表中查找是否具有取值等于过滤常数的一行,如果没有,则新生成一行,直接插入,并返回插入新行的目的网络节点的地址。如果找到对应的行,则将该行的引用计数值增1,然后返回改行对应的网络节点的地址。
3.4 常数表连接算子
由于有了常数表将所有结构相同的查询组织在一起,这样每次流A中的数据到来的时候,不用分别每次调用Filter算子,只要根据元组的相应列在常数表中查找就是了,将该查找工作用一个特定的算子Join Const实现。元组是以队列的形式存放的,和常数表的结构类似,该查找操作和连接操作很相似,我们称之为常数表连接算子Join Const。
4 实验及结果分析
查询优化的输出是查询网络,底层的调度器调度该网络上的算子节点。查询用测试用例如下所示:
4.1 实验参数说明
1)查询的总数N系统中注册的连续查询的总数量,是系统扩展性的一个重要量度。
2)算子的数量系统中存在的算子的数量。由于大量的查询可能会共享相同的算子,因此如果优化器能够实现这些计算之间的共享,算子的数量并不会和查询数量成正比。
3)数据源生成数据的速度当数据源的速度过高时可能会超出系统的处理能力,使得元组积累,内存消耗增加,从而性能急剧降低。因此采用了模拟的数据源,使数据生成速度随时可调。
4.2 优化前的算子数量对比优化后算子的数量
优化算法分别对连接和过滤操作进行分组,图3所示表示了改进前后算子数量的变化情况。
图3中由于结构相似,每个查询都会分解为数目相同的算子,因此未优化时算子的增长为直线。在采用优化方案后,由于大量的过滤算子共享同一个常数表连接算子,因此算子的数量增加很缓慢,当查询的数量足够多时(例如大于400),则算子呈直线上升,斜率约等于1,即只是增加每个查询的Map算子(投影共享),其他算子增加幅度相对减少。
另外,在很多的连接查询条件下,一条查询的优化可能会牵涉到其它许多的查询,迫使它们修正正在执行的查询计划。而查询计划的调整是非常复杂和耗资源的。这种情况在记录大量查询并频繁更新的数据流管理系统是不愿看到的[6]。如果记录查询的数量是n,本优化算法复杂度为O(lnn),而且对一条查询的优化对一条查询的优化基本不会牵涉到其它查询,性能也在可接受的范围内。
本文提出的高效查询优化处理算法的优化很简单,对一条查询的优化基本不会牵涉到其它查询。为考察该算法的性能,设计了一个实验模拟数据流的连接查询,实验结果与预期的基本吻合,有效地验证了算法的性能。本算法同样适用于硬件处理的查询计划生成,因硬件希望查询计划相对稳定。当然,它更适合应用于查询的更新频率很高的系统。
5 结语
详细讨论了用于高效查询的优化处理模型的算法。该算法的追求目标是尽量在查询之间的共享计算,优化算法采用的主要方法是分组,包括连接分组和谓词分组,分组方法是基于索引的。连接分组在大量的连接之间共享中间结果,一方面减少了内存需求,另一方面减少了连接的计算量。谓词分组将标记相同的谓词组织在一起,采用常数表将其存储起来,这样,多个过滤操作转化为数据源和常数表之间的连接操作,大大减少了系统引发的数量,并减少了系统的存储空间。
实验结果表明,本查询子系统在效率和资源节约上都取得了比较好的效果,初步可以应对网络环境中海量用户查询的挑战。
数据流产生的数据是有始无终的,而且很多环境下查询的数量是海量的,从而对硬件的资源要求很高,这就和我们有限的硬件资源产生了冲突,因此,数据化简技术也成为人们关注的焦点,数据化简技术的目标就是在查询准确性和硬件资源之间取得权衡,如果能够高效地将这些技术应用到DSMS中,会给DSMS提供更强大的效率和功能。
摘要：提出一种新颖的优化方案。方案采用了查询谓词分组和连接分组技术,在众多的查询之间实现了计算共享,较大地节约了系统中存在的算子的数量并提高了处理速度。连接分组首先检查系统当前有无可以利用的中间结果,在这个基础上进行后续连接操作。谓词分组将相同结构的谓词组织在一起,通过引入常数表的这个数据结构将这些查询组织在一起,并将多个过滤操作转化为连接操作,减少了过滤算子的数量。实验结果表明,该方法不仅节约了内存空间,而且还较好地提高了系统的运行效率。
关键词：数据流,滑动窗口,连接分组,常数表,谓词分组
参考文献
[1]左利云,马英杰.基于数据流处理模型的多查询优化算法[J].计算机工程与科学,2009,31(3):71-74
[2]陈磊松.面向高速网络的数据流处理模型研究[J].漳州师范学院学报:自然科学版,2006(2):31-33.
[3]谭博阅,刘宁.数据流中的近似查询技术[J].世界科技研究与发展,2006(4):57-60.
[4]Silberschatz A,等.数据库系统概念[M].杨冬青,唐世渭,等译.北京:机械工业出版社,2000.
[5]游凤荷,黄樟灿,李亮,等.具有物理模型数据处理的多目标优化及其算法[J].武汉大学学报:理学版,2001,47(1):57-60.
基于依存关系匹配的长难查询处理 篇6
目前,商业和学术搜索引擎主要基于关键词匹配的方法进行检索。传统的检索方法往往存在两个问题:(1)用户查询时输入的有限词语并不能完全准确表达其检索的真正意图,查询本身存在的歧义性导致搜索引擎返回大量与用户需求无关的文档[1]。该问题可以通过应用查询扩展和相关反馈等技术得到改善。(2)另一方面,用户有时往往会输入长难查询,提供给搜索引擎的查询词的长度发生了变化,其长度正在不断增长[2]。例如:在MSN日志中,大约10%的查询词长度都是在5个词以上[3]。长难查询就是词与词之间包含一定的语法语义关联的较复杂的查询,长难查询往往包含大量的具有语法意义的词,能更详细周全地表达用户的信息需求。与此同时,长难查询也经常会包含一些和用户需求无关联的词,传统的搜索引擎对待长难查询总是力不能及,导致长难查询的检索结果偏离查询主题。Tellex等学者[4]认为忽略关键字之间的重要关系是导致当前词汇匹配被错误判断的主要原因。许多不相关的文档和相关文档一样都包含相同的查询词,但在不相关文档中这些词之间的关系是不同于查询词之间的关系的。下面通过表1中例子来说明这一问题,即词汇匹配不会得到正确的返回结果。表中句子1是正确的返回结果,句子2虽然包含了许多和查询中相同的词,但也是不相关的返回结果。
本文认为在处理长难查询的时候,要充分考虑其自身特点,即充分利用长难查询自身具有的良好句法和语法结构,加以处理和分析。句法分析的任务是根据给定的语法,自动推导出句子的语法结构。句法分析性能的提高对信息检索、信息抽取以及机器翻译等应用产生重要的推动作用。在句法分析的研究中,依存语法以其形式简洁、易于标注、便于应用等优点,逐渐受到研究人员的重视[5]。本文的方法中使用了依存语法分析技术对长难查询进行处理。
本文内容将按如下方式组织:本文第二节介绍长难查询处理的现状以及句法分析技术;第三节简单介绍依存句法和查询重构技术以及语言模型;第四节阐述基于依存关系的查询重构模型;第五节展实验设置。第五节介绍实验设置及结果分析;最后第六节将对本文工作进行总结并对未来的研究工作进行展望。
2 相关工作
对长难查询的处理,在之前的工作中[2,6,7,8,9,10,11,13]的方法可以归结为两类:查询词的重新加权(query re-weighting)和缩短查询词(query reduction)。查询词的重新加权,即对查询词中的每个词赋予不同的权重,再对新查询进行检索;缩短查询词,即通过一些方法来去掉查询词中一些无用的词,减少初始查询词中词的数量,然后对修剪后的查询进行检索[9]。
M.Bendersky等[8]利用有监督机器学习技术来找到长难查询中的关键概念,达到缩短查询词的目的。G.Kumaran等[2]找到初始长查询的所有子查询,若一个初始长查询长度为n,则其所有子查询有2n个,并选择了大量的特征,基于这些特征对初始长查询的所有子查询进行排序,然后选择打分最高的子查询代替原始长查询。他们把对长难查询的简化问题转为了排序初始长查询的所有子查询的问题。但此方法中用到了大量的特征,比如Query Clarity方法的花销很大。G.Kumaran等[13]向用户提供了缩短查询词技术的交互平台。他们用互信息这个单一特征选择了排在前十位的子查询展现给用户,供用户自己选择。然而此方法需要额外的用户的认知力,比较繁琐。
句法分析[5]是自然语言理解的一个关键组成部分,是对自然语言进行进一步语义分析的基础。随着自然语言应用的日益广泛,特别是对文本处理需求的进一步增加,句法分析的作用愈加突出,它几乎成为大多数自然语言处理应用的关键因素。句法分析的结果可直接用于机器翻译、自动问答、信息抽取等应用。目前的机器翻译主要依据短语对齐的结果,而准确高效的句法分析可以提高短语对齐的准确率,改善机器翻译的效果。在基于自然语言的自动问答中,查询扩展以及答案匹配均需要对句子进行深入的理解和分析。已有的一些工作将依存分析用于自动问答的问题分类中,取得了较好的效果,也证明了句法分析对自动问答所起的重要作用。句法分析的另一个应用是信息抽取。为了从非结构化的文本中自动抽取特定的结构化信息,句法分析的作用至关重要,Surseanu等人在句法分析的基础之上进行信息抽取,提高了信息抽取、特别是事件抽取系统的性能。
3 一种基于依存关系的查询重构
3.1 依存语法简介
句法分析,就是指根据给定的语法,自动地识别出句子所包含的句法单位和这些句法单位之间的关系[12]。句法分析的输入是一个词串(可能含词性等属性),输出是句子的句法结构。在句法分析的研究中,依存语法以其形式简洁、易于标注、便于应用等优点,逐渐受到研究人员的重视[5]。依存句法分析可以反映出句子中各成分之间的语义修饰关系,它可以获得长距离的搭配信息,并与句子成分的物理位置无关。
本文采用了斯坦福自然语言处理组的the Stanford Parser。下面举例说明,例句通过该依存句法分析器的分析,句子各成分之间的依存关系如图1所示。
例句:there was some change in the order.
有了句子的依存结构信息,就可以据它来计算句子间的相似度,从而计算长查询与文档之间的相似度。
3.2 查询重构技术
查询重构也就是查询扩展,指的是利用计算机语言学,信息学等多种技术,把与原查询相关的词语或者与原查询语义相关联的概念以逻辑或方式添加到原查询,得到新查询后检索文档,以改善信息检索效果,解决信息检索领域长期困扰的词不匹配问题,弥补用户查询信息不足的缺陷。查询扩展技术即指实现查询扩展的方法和手段,其核心问题是如何设计和利用扩展词的来源。目前扩展词的来源有三种:一是来自初检中认为相关的文档;二是用某种技术如聚类技术,文本挖掘技术等从文献集或查询日志中找出与原查询相关的词语作为扩展词;三是来自某种包含词与词间相关信息的资源,这种资源可以是人工生成的,也可以是利用大规模语料通过统计的方法自动生成[14]。
本文即是利用来自词与词间相关信息的资源来进行查询重构。首先利用句法分析器对数据长难查询进行处理,得到句中词间的依存关系,利用这种关系对长难查询进行重构。
3.3 语言模型
语言模型是关于某种语言中所有句子或者其他语言单位的概率分布,也可以将它看作是生成某种语言文本的统计模型。这里所说的语言可以是常见的自然语言,比如中文、英文等,也可以是程序设计语言等其他逻辑语言。语言模型的基本思想如下:假设用户有一个信息检索需求(Information Need),此时用户的头脑中会构造出一个能够满足这个信息需求的理想文档,之后用户从这个理想文档中抽取出一定的词汇(Term)作为查询串,而用户所选择的查询能够将这个理想文档同文档集合中其他文档区分开来,也就是说可以将查询串看作是由理想文档生成的能够表达这个理想文档的文本序列。
本文进行查询重构后对每个文档进行打分,然后对此得分和语言模型的初始检索文档的得分进行插值平滑处理,得到最终分值并依此分值对文档进行重排序。
4 利用依存关系查询重构方法重排初检结果
4.1 抽取依存关系对
本文利用the Stanford Parser得到依存关系对,以表1中查询为例,分析结果列于表2,此查询返回的正确文档的分析结果列于表3,此文档由两句话构成。由于空间有限,没有把所有的分析结果列出。
其中以aux(produce,does)为例来说明这种表示形式的含义。关系标签aux表示的是括号中词does是produce的助动词。关系标签prep_of表示的是介词of关系,nsubj表示名词性主语关系,等等。Stanford Parser中定义了52种关系标签,本文只抽取了20种关系标签来进行查询重构。
4.2 查询重构模型与重排序
本文首先按传统查询扩展方法进行初始检索,选择初始检索文档的前1000篇文档,记录这1000篇文档的排名得分,由词袋模型得到启发,本文把文档看成为“句袋”,也就是把文档看成是由一个个句子构成的,分析长难查询和文档中每个句子的句法结构,据句法结构特征来计算两者之间的相似度得分,此方法记为tri Parse。
在利用依存文法进行相似度计算时,若对全部依存关系进行完全匹配的话,所花费的代价是巨大的。通过我们的实验验证若考虑全部的依存关系,实验结果并不好。所以这里只考虑那些有效搭配对之间的相似程度。所谓有效搭配对是指全句核心词和直接依存于它的有效词组成的搭配对,这里有效词定义为动词、名词以及形容词,它是由分词后的词性标注决定的[15]。本文把一个搭配对关系看成是一个三元组,则一个有效搭配对则为一个有效三元组。
假设有两个三元组:(1)(Reli,word1i,word2i);(2)(Relj,word′1j,word′2j)。三元组(1)表示文档中第i个有效三元组,三元组(2)表示查询中第j个有效三元组。我们约定Reli=Relj为A事件,word1i=word′1j为B事件,word2j=word′2j为C事件。
Scorei()同理。公式中P()表示事件A不发生、事件B发生、事件C不发生的概率,i表示文档生成的有效三元组中第i个有效三元组。
Scorei()同理。
若有效三元组中均不能匹配,则得分为0。
则文档和查询的相似度得分用Sim Score(q,d)表示,如下:
依此对初始检索结果实现重排序。
以表2中查询和表3中结果文档为例,说明得分计算过程。表2中查询筛选出的有效三元组为nn(cheese,nation),prep_of(per-cent,cheese),nsubj(produce,California)。表3结果文档的全部有效三元组为prep_in(palpable,California),nsubj(produce,farmers),nn(cheese,nation),prep_of(percent,cheese),nsubj(palpable,outrage),nsubj(produce,California),nn(produce,cheese),prep_in(state,nation),prep_of(produce,state)。这里没有对这些三元组进行词干还原处理。对于文档中有效三元组prep_in(palpable,California),只和查询中的nsubj(produce,California)匹配上了一个词,所以Score1(AˉBˉC)=0.05。对于有效三元组nsubj(produce,farmers),和查询中的nsubj(produce,California)匹配上了关系和一个词,所以Score2(ABCˉ)=0.5。同理可得nn(cheese,nation)和prep_of(percent,cheese)匹配得分均为1,nsubj(palpable,outrage)匹配得分为0。以此类推,最后得到结果文档和查询的匹配得分为0.05+0.5+1+1+0=3.75。
得到初检结果文档和查询的匹配得分后,最后利用此得分和初始检索得分进行插值,得到最终分值并依其对初检结果的前1000篇文档进行重排序。
5 实验结果与分析
5.1 实验设计
本文的初次检索使用indri搜索引擎工具来建立索引和检索,检索模型使用统计语言模型应用于检索中的查询似然模型,Dirichlet平滑参数μ设置为1000,记为LM。本文实验采用的是TREC标准语料集Robust 2004作为检索文档集,共包含250个公开的查询主题和528155篇文档,文档来自the Financial Times、the Federal Register、the LA Times、和FBIS。TREC的Topic由title,description,和narrative组成,其中title长度通常是1至4个词的长度,description长度通常是3至30个词的长度。本文实验中使用TREC的description查询做为长难查询。
5.2 实验结果与分析
为了体现实验结果评价的公正性,本文使用了TREC标准评测工具来对结果进行评价。抽取的十个查询的插值情况如表4,此表是对三元组进行词干还原处理后的结果数据。作为对比,表5是没有对其三元组进行词干还原处理的结果数据。表6为剔除了含有停用词的三元组的结果数据。其中α为插值参数。
对实验结果进行分析可看出,平均MAP值基本在一个量级,但对于单个的查询,大部分查询的MAP值都有提高。通过观察发现,这些查询都是低召回率的查询,其中tri Parse方法在691查询、699查询上表现突出,MAP值如图2,P@N如图3。
由实验分析可得,图中query的初始检索的召回率均是在38.1%以下,由此可得出本方法对于召回率域值在38.1%以下的query初检结果性能有明显优化作用。
6 结论与未来工作
目前,用户查询词长度呈现逐渐增长的趋势,并且一般的搜索引擎对长难查询会导致偏离查询主题的错误,以致检索结果不尽人意。之前的工作对长难查询的处理,或者是对查询词重新加权或者是缩短查询词的方法,都没有利用长难查询具有较好的句法语法特征这一特点,因此本文从该角度出发,将依存句法分析引入进来充分挖掘长难查询的依存句法信息。利用此方法在标准TREC数据集上的实验验证了本文方法的有效性,尤其是对于低召回率的查询,在MAP评价指标和P@N指标上都有很大提升。
信息查询处理 篇7
作为一种新出现的计算模式,云计算(Cloud Computing)提供安全、可靠的数据存储,可以对海量数据管理提供有效支持。云计算就是使用构建于低成本硬件和网络设备基础上的大规模计算机集群,资源可在集群用户之间实现动态分配[1]。云计算具有以下特点:
(1)超大规模。
“云”具有相当的规模,Google 云计算已经拥有100 多万台服务器,Amazon、IBM、微软、Yahoo 等的“云”均拥有几十万台服务器。企业私有云也一般拥有数百上千台服务器。“云”能赋予用户前所未有的计算能力。
(2)虚拟化。
云计算支持用户在任意位置、使用各种终端获取应用服务。所请求的资源来自“云”,而不是固定的、有形的实体。应用在“云”中某处运行,但实际上用户无需了解、也勿需担心应用运行的具体位置。
(3)高可靠性。
“云”使用了数据多副本容错、计算节点同构可互换等措施来保障服务的高可靠性。
(4)通用性。
云计算不针对特定的应用,在“云”的支撑下可以构造出千变万化的应用,同一个“云”可以同时支撑不同的应用运行。
(5)高可扩展性。
“云”的规模可以动态伸缩,满足应用及用户数量增长的需要。
目前,TB/PB级海量数据的查询处理技术已逐渐引起世界各国数据库领域的研究学者和工业界人士的关注重视。人们在此领域开展了一定的研究工作。但是从数据库的角度,系统的研究工作还较为少见,除了在TB/PB级海量数据的数据存储、查询语言等方面取得了一些成果外[2],在海量数据的代数操作及其实现技术、海量数据的查询处理和优化技术等方面并未获得显著进展。传统的数据库系统既不能提供针对TB/PB 级数据的有效存储与索引,也难以提供专门针对TB/PB 级海量数据的高性能基本数据操作算法以及高性能查询处理技术。数据网格查询处理的研究虽然取得了一定的进展,但是大多数查询处理器都是针对特定应用的。数据网格查询处理的研究工作主要集中在查询处理的体系结构、基于服务思想的分布式查询处理、基于语义本体的分布式查询处理等几个方面,而却没有从数据库系统的角度进行进一步研究。由于云计算系统能够提供可靠、安全的数据存储,以及对TB/PB级海量数据的管理提供稳固、有利的支持。目前,基于云计算环境的TB/PB 级海量数据查询处理技术的相关研究工作还处于初期阶段,研究成果还未形成规模,在针对TB/PB 级海量数据的存储与索引、各种数据操作算法、查询优化处理等方面,还有大量的理论和技术问题需要解决,研究工作任重道远。
基于此,开展研究基于云计算环境的TB/PB级海量数据查询处理的关键技术和理论研究,包括TB/PB级海量数据的存储与索引、数据的高效操作算法,查询优化与处理技术具有很大的学术价值和实际意义。
1 云计算系统概述
目前,将计算和存储从客户的PC端移动到大规模的服务平台(数据中心)的思想逐渐流行,而为学术界熟悉与接受。这种态势一方面可以利于用户对个人数据的管理,用户不需要对数据进行配置或备份操作,并且只要能连接到Internet就可以随时随地获得数据;另一方面也可以方便服务供应商提供更好的服务,因为供应商可以通过随时更新软件来提高数据中心的服务质量。数据中心可以实现用户以较低的代价成本获得较高质量的服务。基于这种服务模式,工业界近年来设计了众多云计算系统,用于支持网络自身服务所需的数据管理功能。
GFS[3]集群由一个master和大量的chunkserver构成。文件被分成固定大小的块。每个块由一个不变的、全局唯一的64位的chunk-handle标识,chunk-handle是在块创建时由master分配的。ChunkServer将块当作Linux文件存储在本地磁盘并可以读/写由chunk-handle和位区间指定的数据。每一个块均可复制到多个chunkserver上。Master维护文件系统所有的元数据(metadata),包括名字空间、访问控制信息、从文件到块的映射以及块的当前位置。GFS是Google网络服务的后台数据存储系统。BigTable[4]是由Google提出的、构建于GFS之上的用于管理结构化数据的分布式数据模型,其管理的数据规模可以达到PB级。Google的众多应用都构建于BigTable之上,如网络索引、Google地球、Google商务等。BigTable数据模型使用行值、列值和时间标识作为哈希键值来定位结构化的目标数据。在分布式文件系统GFS和数据模型BigTable的基础上,Google设计了并行编程模型MapReduce[5]用来在大规模集群环境中并行地处理TB/PB级数据。MapReduce将计算任务划分成若干Map和Reduce过程,由用户编写Map和Reduce功能代码。系统提供自动的并行化处理、计算节点状态检测、任务调度、负载平衡、容错性。MapReduce为并行编程提供了很大的便利。MapReduce使用BigTable作为数据存储模型,并将数据以及中间计算结果存储在GFS中。
Amazon成功设计了Dynamo[1],将其作为具有高可靠性的分布式存储系统,其存储数据格式为
作为Yahoo!公司的云计算平台,PNUTs[7]重点关注了可扩展性和高可靠性,而放松了对一致性的要求。PNUTs只保证提供最终一致性,即用户可以更新数据的任何一个副本,并最终可以将更新应用到该数据的所有副本。PNUTs系统分布在全球多个数据中心,具有可扩展性,可支持记录数由几万条直至几亿条。数据容量增加不会影响性能。数据格式使用key/value存储,保持数据的弱一致性,并提供了容错机制。文献[2]介绍了Yahoo!设计使用的其他网络服务系统,包括云计算系统PNUTs[7]、ad-hoc分析查询语言Pig、云平台服务设计系统AppForce、网络信息提取系统Purple Sox、GUESTS等。文献[8]介绍了Yahoo!设计的Pig Latin查询语言,该语言作用于MapReduce[3]系统中,使用类似SQL的声明语法,并实现了MapReduce机群中数据分析查询的各种基本操作。Pig Latin提供了相应的调试组件,用以提高生产效率。
Dryad[9]是微软分布式并行计算基础平台,程序员可以利用数据中心的服务器集群对数据进行并行处理。Dryad程序员在操作数千台机器时,无需关心并行处理的细节。Dryad则设计为伸缩于各种规模的计算平台:从单台多核计算机、到由几台计算机组成的小型集群,直至拥有数千台计算机的数据中心。Dryad执行引擎负责处理大型分布式、并行应用程序中可能出现的各种难题:对计算机和其中的CPU进行调度,从通信或计算机的失败中恢复,以及数据在节点之间的传递等等。微软设计了可扩展的声明语言SCOPE[10](Structured Computations Optimized for Parallel Execution),用于分析大规模数据集合。SCOPE无需用户显式的定义并行操作,实现了机群中的自动并行化。SCOPE使用关系数据和类似SQL语言的语法,并提供选择操作、内连接、外连接和聚集操作功能,同时还支持用户自定义的函数功能以及表达式的嵌套。
威斯康辛大学开发了Clustera[11]系统,用于提供具有可扩展性的系统功能,使得系统适用于不同的工作负载,包括计算密集型的任务、长期任务以及大规模数据集上的负载SQL查询等。Clustera使用服务器和数据库管理系统来管理工作负载信息和系统状态,以此获得通用性、可扩展性和更高性能。加利福尼亚大学设计实现了分布式文件系统Ceph[12]。Ceph在存储数据时区分数据和中间结果,并使用伪随机数据分布代替了数据定位表,以此获取更好的性能和可靠性。Ceph Client 是 Ceph 文件系统的用户。Ceph Metadata Daemon 提供了元数据服务器,而 Ceph Object Storage Daemon 提供了实际存储(对数据和元数据两者)。最后,Ceph Monitor 提供了集群管理。需要注意的是,Ceph 客户,对象存储端点,元数据服务器(根据文件系统的容量)可以有许多,而且至少有一对冗余的监视器。
文献[12]针对MapReduce在处理异构数据以及关系数据连接操作时的相应缺点,将MapReduce编程模型做以改进,使其发展成为Map-Reduce-Merge模型。Map-Reduce-Merge在MR后期加入了一个Merge过程。Map-Reduce-Merge能够表达关系代数中的各种操作以及一些连接算法。
综上所述,现有的系统缺乏对海量数据复杂查询处理功能的支持,只能提供基于键值的有效查询处理。
2 云计算系统中数据管理的研究工作
MapReduce被工业界广泛接受,除了设计者Google使用MapReduce之外,Yahoo!使用开源的项目Hadoop实现了MapReduce的功能,并作为内部数据并行处理的基础结构。大量研究人员在MapReduce系统中展开工作,研究各种数据管理技术在MapReduce中的实现方法以及MapReduce在数据管理领域的功能角色。如文献[13]设计了高级的数据流系统Pig,设计目标是在SQL和MapReduce之间建立联系通道。Pig系统实现了MapReduce系统中各种SQL基本操作的具体实现。文献[14]在MapReduce系统中提出了大规模数据集上的学习树模型的并行算法框架PLANET,定义了一系列分布式计算并在MapReduce中实现了其中的一个算法。文献[15]同样致力于MapReduce中SQL 语言的实现,并且实现了Aster Data System nCluster数据库系统,支持多种用户自定义函数功能。文献[16]评估了MapReduce在多核或者多处理器系统中的适用性,并设计了Phoenix作为MapReduce在共享内存系统中的改进版本,其功能主要包括自动管理进程建立、动态任务调度、数据划分以及处理器之间的容错性。文献[17]讨论了并行数据库和MapReduce之间的关系。文章指出并行数据库和MapReduce是互补型技术,两者可以互相借鉴,获取更好的工作效率。并行数据库和MapReduce都不能完全取代对方。文献[18]研究了MapReduce系统中的自动优化问题,用以减轻调节系统的复杂性。文献[19]通过测试研究MapReduce的系统性能,发现通过调整五种主要的设计因素,MapReduce的系统性能可以获得大幅提升(2.5-3.5倍),而与并行数据库系统的性能差异则明显缩小。文献[20]在MapReduce中使用三个阶段的Map-Reduce方法实现了并行集合的相似性连接操作。算法通过有效的数据划分平衡了工作负载并且实现了最小化备份参数。文献[20]给出了算法在内存资源不足情况下的实现方法。文献[21]讨论了在现有云计算平台(如Amazon的EC2)中部署数据管理系统的约束限制及机遇场合。论文提出如下观点,大规模数据分析、决策支持系统与事务处理数据库系统相比,更能利用云计算系统的优势。同时指出,利用二者结合的无共享并行数据库是云系统中数据库研究的切实有效的出发点。文献[22]使用大规模数据分析任务剖析比较了并行数据库和MapReduce的性能。与MapReduce相比,并行数据库的优势主要表现在数据模式的支持,索引等提升性能的技术,SQL语言的表达能力。而MapReduce的优势在于自动的并行化,任务的灵活性,高可靠的容错能力,在异构环境中的运行能力。实验表明,在集群同构且节点不发生失效的情况下,并行数据库的性能要远远优于MapReduce。而在节点频繁失效的情况下,并行数据库的性能就会出现显著下降,而MapReduce的性能影响则较小。HadoopDB[23]将数据库管理系统和MapReduce结合,使用PostgreSQL开源数据库管理系统作为MapReduce节点管理系统,而且使用Hadoop提供的MapReduce框架连接系统中的节点。HadoopDB具有较快的单机处理速度优势,并且兼有MapReduce的异构有效性、容错性的优势。HadoopDB支持SQL语言。
3 无线传感器网络上数据聚集调度的研究工作
文献[24]提出了云计算数据存储系统中批量插入数据的有效方法,系统中的数据按照key值范围水平划分并分布在各个存储节点中。文献[24]考虑了在数据插入过程中的数据迁移代价和插入后系统吞吐量之间的折中,而且也证明了问题属于NP-hard问题。文献[25]研究了如何在系统中有效的并行化范围查询的问题。本文考虑到存储系统的客户应用消耗数据的速度与查询获取结果的速度之间的差异,通过动态适应的方式增加或减少并行处理范围内实现而需查询的节点个数,以此使得系统并行获取足够的查询结果发送到客户应用。文献[26]实现了在MapReduce中构建分布式数据流处理的系统。文献[27]研究了在大规模分布式数据管理系统中使用索引和视图的机制。本文使用两种视图,即远程视图表和本地视图表,并以此提供了系统吞吐量和视图更新速度之间的折中处理,同时也给出了构建和维护式图标以及使用视图回答聚集查询、连接查询、选择查询的方法。文献[28]设计了可扩展的分布式关系表系统Crescando用以支持大量的查询和更新,并提供可预测的操作延迟。Crescando使用并行协作的扫描指令以及数据流中“查询-数据”连接技术保证工作负载的反应时间和结果的新度。Crescando在处理各种工作负载时不能取得最优性能,但是在工作负载未知,而且变化的情况下,Crescando却具有独特优势。文献[29]设计了云计算数据存储系统Spinnaker,在数据的可获取性和一致性之间达到了更新的折中。Spinnaker使用一致性备份协议取得了高可获取性和timeline一致性,并在元组级的事务处理中实现了ACID。与Dynamo相比,Spinnaker具有更好的数据一致性,而只需付出较小的性能代价。文献[30]设计了云计算平台测试的模拟软件CloudSim,用于简化云计算中应用开发的性能评估。文献[31,32]设计了云计算平台中的单维索引CG-Index,用以支持key查询和范围查询。CG-Index通过两级索引结构,在本地构建B-Tree索引并选择若干B-Tree节点发布为全局索引。系统中的节点则组织成BATON Overlay结构,其发布的全局索引负责回答系统中收到的查询。文献[33]设计了ecStore,将数据对象分布并备份于云计算集群环境中。文献[34]设计了P2P数据管理系统中在线近似聚集的处理算法,通过不断获取数据,提高计算结果的精度。文献[35]比较了现有云计算平台的架构对构建云数据库的影响,其主要研究对象是在线事务处理而不是在线分析处理。结果表明现有的主流云计算系统具有不同的架构,对于相同的工作负载也具有不同的性能。文献[36]提出了一种分布式的B树索引。该索引结构将数据索引缓存在各个存储节点中,回答查询时,首先检查缓存内容是否过期,如果还未过期,则直接在本地回答查询,否则需要执行相应更新操作。这种索引结构在数据更新快的情况下,效率严重下降。
4 结束语
目前,云计算系统中数据管理方面的研究已经引起广泛关注和浓厚兴趣,而查询处理和优化技术则是其中最为基础、且最为重要的研究内容,对此已经开展了较为详尽与深入的研究工作。本文中,归纳并总结了云计算系统、数据管理以及查询和索引技术等方向已有的研究,并对可能的研究方向进行了简要的分析与阐述。
摘要：云计算系统中的查询及优化技术是近年来倍受关注的热点研究领域,综合了并行计算、分布式计算和查询处理及优化技术等方面的研究成果,具有广阔的应用前景。云计算系统中的查询和优化是一项基础而重要的操作,被研究者们所广泛关注,也涌现出了很多研究工作。总结了近年来云计算系统中的查询处理和查询优化方向的研究工作,讨论了现有工作的内容和需要进一步研究的方向,并提供了广泛的参考文献。
信息查询处理 篇8
1 模块实现
1.1 软件环境介绍
Delphi是一种具有功能强大、开发效率高和代码执行速度快等优点的可视化快速应用开发工具。在Delphi中制作报表通常有三种方法：一是采用Crystal Report制作报表，二是采用挪威QuSoft公司专门为Delphi编写的QuickReport，三是采用Re portBuilder，四是采用FastRepor。其中FastReport综合了Crystal Report和QuickReport及Re portBuilder的优点，个头小，速度快，并带有全部源码。本文正是看到了它的优良的特性，所以采用了FastRepor3.0来设计要打印的报表。将通过按钮直接调用FastReport3.0设计的报表进行打印。
1.2 硬件介绍
1.2.1 打印机
煤炭行业常用的打印机有松下公司生产的KX-P1121、KX-P1122、KX-P1131和方正公司生产的A321、A1000、A3000及柯尼卡美能达公司生产的1350W、2500W等系列。在进行信息化改造之前，松下公司生产的KX-P1131是目前公司主要使用的硬件之一。它的接口可以采用并行和串行两种方式，而并行方式又是使用的主流。其中，并行接口在计算机和打印机之间传送资料的方式以centronics为标准。
规格如下：
数据传输率：每秒最少1000个字符
同步：外部strobe脉冲
逻辑级：tt1(晶体管-晶体管-逻辑电器)
握手信号：bust和ack信号
接口插座类型：57-30360(amphenol)或等效插座
T1……0.5微妙(最小);T2……0.5微妙(最小);T3……0.5微妙(最小);T4……大约8微妙;T5,T6……大约4微妙T7……缓冲区未满时为1毫秒或更少,缓冲区满时为1秒或更少
电缆：使用1.95m(6'5")或更短的屏蔽电缆
接收正常时间的时序图如图2所示。
1.2.2 视频采集卡
系统视频采集接口运用的是市面上普及的天敏SDK2500系列视频采集卡，支持NTSC和PAL.SECAM制式，提供动态AVI图像捕获，可采集单场，单帧，连续帧，间隔几帧，连续相邻帧的图像，实现自定义区域抓拍，并且提供功能全面二次开发包，广泛应用于银行、医疗、社区、交通、农业监控及远程通信等方面的系统开发。
1.3 软件实现
作为整个计量监控系统中数据查询打印模块,在界面上是通过对话框来设置打印机的类型及打印份数等相关信息的。在第一次开启查询打印界面之前应先在打印设置界面设置打印相关信息，之后的打印中系统将采用上次的设置结果进行打印。其参数设置及主要软件界面如下图3，图4所示。
1.4 数据查询打印模块设计
1.4.1 变量设置
1.4.2 打印机初始化主要程序
打印机的初始化参数在点击按钮进行报表打印时进行。当打开查询打印业务窗口进行数据打印的时候，软件后台将自动读取打印机设置界面的配置参数，进行初始化工作。主要代码如下。
1.4.3 数据选择及查询界面主要程序
当打开查询打印界面并点击打印榜单按钮时，将触发BitBtn2的Click事件，在该事件处理中将先初始化打印机并调用相关的报表进行打印。事件主要代码如下：
2 结论
本文所涉及的煤炭分布式计量监控系统，是整个公司企业信息化建设的核心和关键环节，而数据查询打印模块更是重中之重，若打印模块无法正常工作，将直接影响信息化建设的效果。此系统能够有效利用企业原有硬件资源，为企业的信息化建设节约成本，并取得良好的应用效果;该方法同样适用于其它系统的设计，对于在其它行业领域具有相关应用的工程实施也具有一定的参考价值。目前该系统模块已在福建某有限责任公司十多个业务现场正常使用中，并在启用初期，就通过对数据的查询分析，成功发现一些原有的业务舞弊现象，为企业挽回了几十万元的损失。
摘要：计量监控系统是指在称重的过程中能够通过软件的监控设备对车量的停车位置、车牌号等进行监控拍照并储存于系统的数据库中,以供日后查询检查使用的系统。该文对在Delphi平台下开发的计量监控系统,在数据查询与打印时遇到的不同品牌打印机配置,报表的任意设计等问题进行了深入研究,提出了有效的解决方案,为企业在信息化实施过程中因系统升级、打印机更换、报表设计与更改而遇到的相关问题提供了参考。
关键词：计量,Delphi,查询,打印,打印机配置
参考文献
[1]梁水,赛奎春.Delphi开发典型模块大全[M].北京:人民邮电出版社,2009.
[2]梁水,李钟尉,吕双.Delphi技术方案宝典[M].北京:人民邮电出版社,2008.
[3]明日科技.Delphi开发经验技巧宝典[M].北京:人民邮电出版社,2007.
[4]张仿彦,赛奎春.Delphi接口技术开发实例解析[M].北京:机械工业出版社,2007.
[5]钟军,汪晓平.Delphi网络通信协议分析与应用实现[M].北京:人民邮电出版社,2003.
[6]Danchin A.The Delphic boat:what genomes tell us/Q75/D173[M].translated by Alison Query.Harvard University Press,2002.
[7]Ayres J.Delphi Win32核心API参考[M].北京:中国电力出版社,2004.
信息查询处理 篇9
关键词：计算密集型,存储技术,索引机制,查询技术,并行编程模型
随着社会的数字化变革、因特网的蓬勃发展及国民经济的迅猛崛起,全球各个领域的数据呈爆炸式增长。数据作为信息的载体,已成为包括金融经济、交通物流、国家安全和社会生活等各个领域最核心、最有价值的资源。因此,为了发现数据背后隐藏的巨大价 值,从商业应 用领域到 科学计算 领域,面对海量数 据的计算 密集型应 用需求日 益增加,许多电子商务网站和社交网站需要存储海量异构的页面信息、用户信息以及访问日志等,并对这些数据进行快速而准确地访问以及面向商业市场前景的智能计算。这些典型的计算需求包括用户购买能力分析、定向广告投递效果查询、产品增值的市场分析等,这些已成为互联网中的核心问题。 基于这些海量数据的查询分析,从中获取有利于互联网用户体验的信息,从而形成商业利益的有效价值链是十分有意义且充满挑战的工作。实现对计算密集型海量数据的有效查询,需要从各项技术角度加以协调。
1关键技术介绍分析
1.1大规模分布式存储技术
大规模分布式可靠存储系统可为计算密集型 查询任务提供重要的后台支撑,同时满足系统在读写效率、查询速度 和吞吐量 上的要求。 在互联网 中,计算机用户实现大规模的文件存储、共享和交换时,基本上都是基于P2P技术,比较著名的基于P2P的分布式 存储系统 有Napster、Kazaa、Ocean Store等。其中,Napster将系统中所有计算机节点认为是同一级别,文件标识号和文件存储节点间存在一个约定好的映射关系,这使得用户在查找某个文件时,可以通过计算快速定位到文件存 储节点, 从而建立连接并下载文件。
随着计算机技术的飞速发展,个人计算机进行独立工作的能力越来越强,而且会有大量的计算和存储资源处于闲置状态,并且一天当中会有近半数以上的计算机处于开机联网状态。要想在互联网的结构特点上,以现有资源为基础,更有效地发挥互联网的作用,就需要整合互联网上众多零散的个人计算机,将其作为统一的节点进行管理,并充分利用它们各自的空闲存储空间,形成一个高可靠、 高性能、海量而廉价的分布式存储系统。
因此,可以将节点Node和用户文件File作为系统中的独立实体,实现分布式存储系统。该存储系统在节点通过网络连接起来的基础上,用户文件以副本的形式存储到多个较近的节点中,文件内容会随着用户的操作随时同步更新。对于大文件而言可以直接存储;对于小文件来说,直接存储会浪费存储空间,所以可采用将多个小文件进行聚集压缩而形成一个复合文件的形式来存储,而在访问时可以不解压而直接对文件进行各种操作。另外,各节点除了提供存储空间,还可以提供计算资源,从而使系统更加高效。
从系统功能的角度可以将系统由下至上分为物理层、路由层、数据层、会话层和应用层。物理层是采用网络将各独立节点进行连接,是整个系统的物理基础;路由层通过路由算法进行节点和文件定位,以便就近存取文件;数据层通过冗余的文件副本提供数据容错,同时提供平衡负载和文件压缩等功能,以便提高文件访问效率;会话层为用户提供节点登录和目录管理功能,并保证了数据安全和高效的数据传输;应用层为用户提供了统一的虚拟海量存储空间接口,用户在系统任意一个结点上登录都可以自如地访问分布式存储空间,包括上传、下载文件,还可以实现文件共享。
由于存储的数据涉及到结构化和非结构化数据, 鉴于结构化数据适于实时访问以及方便存储敏感数据的优点,以及非结构化数据的低成本、高性能、自由性强、可扩展程度的优点,在存储数据的同时,可以将结构化数据和非结构化数据融合存储,有效整合,以简代繁,实现数据访问与共享的有效隔离。分布式存储系统的系统层次结构如图1所示。
1.2面向海量数据的索引机制
在数据库研究领域,数据通常被分成结构化数据和非结构化数据两种类型。结构化数据具有统一的纲要,关系表中的每个元组都有相同的属性和数据类型(比如数值或字符串),关系数据库可以对它们进行统一的存储和管理。相比之下,非结构化数据包括文本文件、XML数据、社交网络数据等, 这些数据没有统一格式,无法用关系数据库实现。 在复杂的实际应用中,系统甚至可能需要同时处理结构化和非结构化数据。为了方便用户对各种数据类型的查询和分析,需要根据不同的数据结构研究合理的数据存储索引机制,以提高计算密集型查询和分析的时间效率。
1.2.1结构化数据的索引策略
对于海量结构化数据,如果仍要遵循数据一致性规则,将导致数据更新延迟、局部数据失效、系统扩展性受限等问题。因此,应放宽对数据一致性的要求,取消复杂的关联查询,结合具体的应用场景, 提高系统的可用性。可以采用倒排索引技术,通过词典和倒排链表实现字符串到文件的映射,以便根据查询词快速定位。对于海量结构化数据,则需要分布式处理索引,通过索引分割建立索引集群。索引分割可以采用混合分割,即根据数据特点分别对索引进行基于文档的纵向分割和基于词的横向分割。此时,整个文档集合可以局部的纵向分割先划分成N份,然后对于每一个子文档集合在M个索引集群节点上,针对查询频率高的词进行基于“词” 的横向分割。
1.2.2非结构化数据的索引策略
对于非结构化数据,首先需要在分析数据的基础上进行预处理,然后根据不同的数据特点通过适当的算法进行数据原始特征采集和转化,生成数据的有效特征,从而得到高维数据,最后实现数据的存储。这里的特征提取算法尤为重要,算法不但要最大程度地降低特征维度,还要保证所提取的数据特征的有效性,力求从中得到更多有价值的数据和信息。
随着大数据时代的到来,数据维度不 断增加, 树形索引技术已无法满足日益增加的索引复杂度需求,因此,可以采用LSH算法,利用Hash函数族,在保持原高维数据空间相似性的前提下,将高维索引数据转化为低维数据,使高维数据点尽可能地Hash到相同桶中,同时要均衡各节点的负载,从而有效地解决高维数据的相似性搜 索问题。但是LSH算法将会把大量时间用于计算桶合并后查询点与这些高维数据点集合的距离,以便选取最近的一些数据点作为最终的查询结果返回,从而浪费大量时间。为了解决这个问题,可以在Hash函数中融入谱分析技术,即对高维数据进行谱分析,对给定的一个高维样本数据库进行训练,通过特征函数分析高维数据样本的平均分布,以构造谱Hash函数,从而保证将相似的高维数据点Hash到一个相似值上。
对于不同种类的高维数据,则要充分利用概率分布特点,使其映射到不同的节点空间中,将这种分片策略集成到非结构化数据分布式索引系统中, 以实现高效查询。LSH高维数据划分与节点映射如图2所示。
1.3高效并行聚集查询技术
在对海量数据实现了分布式存储及索引机制的基础上,还要针对具体查询进行处理和优化。由于海量数据库的应用中具有大量聚集查询,因此, 要重点针对海量数据的聚集查询操作进行处理和优化。
如果系统经常接收到的查询是聚合查询,则可以采用刷新缓存的方法来进行。首先,系统要为每种聚集查询语句分别建立缓存表,在每一个时间片内执行一次聚集查询操作,然后将带有时间标记的查询结果存入到相应的缓存表中,以后一旦有查询需要处理,则按时间段到相应的缓存表中去匹配即可。其次,如果用户提交的是已优化的聚 集查询, 就要按时间将其分解为探测查询和剩余查询,最后合并查询结果即可。
上述方案在收集缓存时需要直接访问源数据 库,因此只适用于聚集查询种类不多的情况,如果聚集查询种类多,势必会降低系统性 能。这时,可以将数据在入库前就进行分流,一段数据流载入小规模数据库,另一段数据流则直接载入源数据库。 当需要收集缓存信息时,就可以直接在小规模数据库上进行操作,然后将结果存入缓存。相应的时间片结束时,要在中间结果数据库中执行该时间片内的聚集查询,然后将查询结果存入缓存表,同时将中间结果数据库中该查询对应的缓存表截断,以便收集下个时间片的缓存信息。由于中间结果数据库中的数据容量与主数据库相比要小得多,因此在其上面做聚集查询操作效率非常高,并且不会影响到主数据库系统的性能。
2并行编程模型
为了使并行编程不依赖于具体的硬件平台,让更多的人能够在比较低的起点上快速有效地开发并行程序,实现串行程序的并行执行,需要设计出合理有效的并行编程模型。并行编程模型可以采用层次化结构设计。
首先,为实现并行编程的平台无关性,需要将与平台相关的底层所有并行函数库进行封装,用户可以通过统一的与平台无关的上层API接口进行并行程序开发,程序可以在不同的计算平台上实现编译,同时将上层API自动映射到和平台相对应的函数库中。
其次,为了大规模计算问题的并行化,解决复杂问题,要通过任务调度策略和数据分配功能,使多任务计算问题在执行时达到较低的平行开销和较好的负载均衡。对一个计算问题,可以根据任务规模分别采用不同的粒度,并将其划分为多个独立的计算单元,然后通过线程的并发同步解决计算问题。每个任务通过一个数据调度器对数据按行或按列划分,将数据平均分配到各个线程上,每个数据块分配给哪个线程可以是顺序分配,也可以是循环分配或是随机分配。
最后,为了增强系统的可扩展性,应提供应 用函数库和运行时函数库的扩展手段,使系统可以支持任何最新低层计算平台,并可针对某一具体应用领域开发特有的编程模型。
3结束语
【信息查询处理】推荐阅读：
综合信息查询08-17
政务信息查询11-02
驾照信息查询06-06
图书信息查询系统09-16
学生信息查询系统11-08
惠农补贴资金信息查询06-06
城乡居民养老信息查询08-20
智能语音查询信息系统09-22
社保卡人员信息查询10-16
个人住房信息查询证明10-22