一种云环境下的高效发布订阅方法与流程

文档序号:16248198发布日期:2018-12-11 23:46阅读:172来源:国知局
一种云环境下的高效发布订阅方法与流程
本发明涉及信息技术,能够用于提供高效的发布/订阅匹配性能,并且具有更小的内存消耗,具体为一种云环境下的高效发布/订阅方法。
背景技术
发布/订阅在过去的二十年间已经受到了广泛的关注,目前已应用于在线广告(onlineadvertise),股票市场(stockmarket),社会媒体(socialmedia),电子商务(e-commerce)等等。一个发布订阅系统包含两个角色:数据属主和用户。数据属主以事件的形式发布数据。用户用布尔表达式的形式订阅感兴趣的事件。这两个角色的交互可以通过单机平台也可以通过分布式平台。系统需要保证实时的向用户提供匹配成功的事件对应的数据。现有的发布/订阅方法中,k-index方法将一个区间操作符重写成一组析取的等式谓词,因此谓词数量很多,导致占用的内存和匹配效率不高。be-tree中,随着属性的增加,be-tree产生很多的节点,导致内存消耗和匹配效率不高。opindex采用两级索引结构,但是没有最小化事件匹配的计算复杂度导致匹配效率不高;并且保留了相同的谓词,因此内存消耗较大。静态事件匹配(staticeventmatching)方法只能支持静态的用户订阅。综上可知在时间应用中目前的发布订阅方法存在低效和高内存消耗的问题,因此开展这方面的研究很有实际意义。技术实现要素:本发明提出一种高效的订阅索引方法eim(anefficientsubscriptionindexforpublicationmatch)。表1给出了含6个订阅的一个集合的一个例子。eim首先根据核心属性将订阅进行分组,然后根据基本操作符(,=,)对订阅中所有的谓词进行分组,最后将分组以后的订阅指向分组以后的谓词构成订阅索引。从而提供高效的发布/订阅匹配性能,并且具有更小的内存消耗。针对上述目的,本发明提出了订阅分组方法,对重复的谓词进行了处理,并且形成了订阅索引。从订阅集s中找出最少数量的核心属性,对,都有一个核心属性与s对应,同时也是s中的一个属性。下面对核心属性给出定义。定义1.(核心属性)从订阅集s中找出一组属性,如果满足以下条件,则称是订阅集s的核心属性集:(1),,使得是s中的一个属性,可以用来代表s,即一个订阅用一个核心属性代表;(2)是s中出现频率最高的属性集;(3)是数量最少的,不可能找出另一组核心属性使得的数量少于。基于核心属性集,订阅集s被划分成不相交的订阅组,用表示,如下式所示。=…式子中={s|ss},表示与核心属性相关的订阅组。表1订阅例子a=2b=3a8c=6e2b4c=6e[2,9]b=3d8e9b=3c4d6在实际的发布/订阅系统中,多个订阅具有相同的谓词是一个十分常见的现象,为了减少候选匹配谓词,eim省略了所有重复的谓词。换言之,订阅集s中每个不同的谓词在谓词组中只会出现一次。如果一个谓词已经出现在了一个谓词组中,那么它绝对不会出现在另一个谓词组中。为了加快发布匹配的速度,将所有的操作符都转变成合取操作就是说,如果一个订阅不只一个谓词,则必须所有谓词都匹配才能实现与输入事件的匹配。下面对谓词分组的方法给出定义。定义2.(谓词分组)如果系统中存在订阅集s,则满足以下条件的分组称为s的谓词分组:(1)每个谓词组从订阅集s出发;(2)根据三种运算符(,=,)将所有s的谓词进行分组;(3)一个谓词只会出现一次。对订阅集s进行的谓词分组如下式所示:=。将以上两个部分独立形成的订阅组和谓词组合并到一起就形成了订阅索引,该索引建立的目标是为了提高发布/订阅系统中的用户订阅匹配发布的效率。本发明的优点是,相对于现有的大多数订阅发布方法提出了一种高效的订阅索引方法eim,并对eim方法进行了优化和扩展,通过实验评估将eim与现有的方法(k-index、be-tree、opindex)进行了对比,eim方法具有比现有方法更好的性能。附图说明图1是本发明的eim体系结构图;图2是本发明的表1的订阅分组图;图3是本发明的表1的谓词分组图;图4是本发明的表1的订阅索引图;图5是本发明的表1执行订阅更新后的订阅索引图;图6是本发明的订阅数量影响的内存消耗对比图;图7是本发明的值空间影响的内存消耗对比图;图8是本发明的索引构建对比图;图9是本发明的属性数量影响的事件匹配对比图;图10是本发明的订阅数量影响的事件匹配对比图;图11是本发明的订阅最大容量影响的事件匹配对比图;图12是本发明的事件最大容量影响的事件匹配对比图;图13是本发明的值空间影响的事件匹配对比图;图14是本发明的订阅数量影响的订阅更新对比图;图15是本发明的订阅最大容量影响的订阅更新对比图。具体实施方式以下结合附图和实例对本发明作进一步说明,参见图1~15,订阅方法eim的结构如图1所示。eim中有两个角色:一组用户和一个数据属主。用户订阅数据,是数据的使用者。数据属主发布数据,是数据的拥有者。用户首先向系统提交订阅申请(模块1),然后系统从一组订阅中找出最小数量的核心属性,接着根据核心属性对订阅集合进行分组(模块2)。根据三种基本操作(,=,)将订阅集中的每个谓词进行分组,分成合取组和析取组。为了减少谓词总数量,eim省略了重复的谓词(模块3)。将分组以后的谓词与订阅相连,形成订阅索引(模块4)。数据属主在发布数据(模块7)的同时,会发布一条相应的事件(模块5)。eim将输入的事件和订阅索引放在一起进行匹配(模块6),如果事件可以匹配订阅,则将相应的数据发送给用户(模块7)。图2给出了表1订阅集划分成含2个订阅列的订阅分组。由于表1中b出现了4次,c、e出现了3次,a、d出现了2次。因此首先将b放入。由于订阅,,,含属性b,因此可以用b代表这四个订阅。即:====b。其次,将c、e放入,此时的订阅集s去掉已经被代表的四个订阅后,只剩下了和。如果选c,则只能代表,而选e,则可以代表和,因此用e来代表剩下的两个订阅。即:==e。因此,表1对应的核心属性集={b,e}。给定事件:(a=2)∧(c=6),那么订阅组和中的订阅一定不是的候选订阅,因此不用判断s是否和匹配。表1的订阅集被分成了3个谓词组,如图3所示。订阅集根据三种运算符(,=,)进行分组,并且每个谓词只会出现一次。例如最开始的时候,s找到第一个订阅:a=2b=3,将这两个谓词依次放入“=”谓词组中,并与s相连。表1按照订阅索引建立方法得到的订阅索引如图4所示。第一步,从每个订阅增加指针指向该订阅包含的谓词。第二步,为每个订阅具有的合取谓词数量计数,为下一步的发布匹配做好准备。由于这里已经减少了大量的谓词数量和操作种类,因此有效的减少了发布匹配的环节和参数,提高了匹配的效率。表1首先删除订阅,然后增加订阅:d=5,更新后的订阅索引如图5所示。指向四个谓词:{e2,c=6,b4,e9},其中,b4这个谓词没有被其他订阅使用,而{e2,c=6}在同时被使用,e9在同时被使用,因此只能删除、b4和相应的指针。由于核心属性是{b,e},不含d,并且中仅含一个属性d,因此,增加核心属性d,增加新的订阅组。由于d6这个谓词节点已经存在,因此不需增加新谓词节点,直接增加从指向d6的指针即可。本发明从用户查询效率、析取索引操作两个方面进行讨论。在选取核心属性的时候,选取的是使组数量最少的方法,而opindex选取的是使组数量最多的方法,实际上这两种方法的查询效率都不是最高的。假设系统中的订阅数量是,那么效率最高的理想状态应该是:订阅组的数量是,并且每组的订阅数量是,此时的用户查询匹配复杂度是,这种情况下的用户查询效率最高。但是实际上,eim和opindex的算法复杂度都是按式(5)算的。即按照核心属性数量||和订阅组(与核心属性相关的订阅组)中的订阅数量||的最大值计算的。而这个值是一定大于等于的。因此,为了最大化用户查询的效率,对eim进行如下优化:(1)在选取核心属性的时候,要尽量使核心属性的数量接近。(2)在为一个订阅组选取订阅的时候,要使每组订阅的数量接近。在实际的应用场景中,不可能只存在合取操作,必定还存在析取操作。例如:b=。集合的谓词运算符需要重写成常见的关系运算符。即重写成:(b=3∨b=6∨b=9)。eim的做法是单独建立析取的订阅索引,具体算法与合取索引类似。实际上,任何一个订阅都可以拆成合取操作和析取操作,换言之,如果一个订阅既含析取操作,又含合取操作,则可以将之拆开分别放入析取索引和合取索引。本发明中将方法eim与现有方法opindex、be-tree、k-index进行比较。所有的索引都是驻留内存的,随机产生了订阅和事件,其中所有的属性和操作符都是随机的。由于索引要常驻内存,因此第一个实验用于测试四种方法的内存消耗。影响内存消耗的有两个参数:订阅数量和值空间。为此,实验结果如图6和图7所示。其中纵坐标是内存消耗,单位是g。图6的横坐标表示订阅数量,单位是m(million),图7的横坐标表示值空间。当订阅数量从一百万(1m)增长到4千万(40m)的时候,我们的方法eim随着订阅数量的增长消耗的内存缓慢增长,而opindex消耗的内存是eim的2倍,be-tree是eim的4倍,k-index是eim的14倍。这是由于eim会省略相同的谓词。在k-index中,一个区间操作符会被重写成一组析取的等式谓词,因此谓词数量是最多的。而opindex和be-tree并不会省略相同的谓词,因此内存消耗也比eim要大。当值空间从50增长到12800,k-index消耗的内存会急剧增长,当值空间=3200和12800的时候,以我们128g的内存已经无法测出k-index具体消耗的内存容量了。be-tree内存消耗也增长了很多:从1g增到了10g。这是由于k-index和be-tree都采用了基于属性值的反向列表,因此当值空间增长的时候,索引也随之增长。而eim和opindex将订阅划分成了谓词组,因此索引不随着值空间的增长而增长。同时,eim省略了相同的谓词,并且简化了索引结构,因此内存消耗比opindex要小。索引的构建代价只与属性数量相关,因此试验结果如图8所示。其中,横坐标表示属性数量,单位是k(1千);纵坐标表示构建索引的时间,单位是秒(s)。当属性数量从20k增长到60k的时候,be-tree构建索引的时间最长,而k-index次之,opindex只比eim多消耗一点时间。这是由于eim省略了重复的谓词并且索引与节点容量无关。be-tree的索引构建依赖于节点容量(nodecapacity),节点容量越大,索引构建时间越少,但是订阅匹配速度越慢。因此,我们测试的时候取了一个折中,be-tree的节点容量取了一个中等的值(100)。k-index需要产生更多的谓词,因此索引构建时间也较多。opindex没有省略多余的谓词,因此构建索引的时间多于eim。事件匹配其实就是订阅对新发布数据的匹配,匹配速度越快,用户查询数据的速度越快。因此,事件匹配的性能才是整个系统最关键的性能指标。从属性数量、订阅数量、订阅最大容量、事件最大容量、值空间五个方面对事件匹配性能进行测试,试验结果如图9到图13所示。纵坐标均表示事件匹配消耗的时间,单位是微秒()。横坐标分别表示属性数量、订阅数量、订阅最大容量、事件最大容量和值空间。图9的横坐标表示属性数量,单位是k。图10的横坐标表示订阅数量,单位是m。图11的横坐标表示订阅最大容量。图12的横坐标表示事件最大容量。图13的横坐标表示值空间。在属性数量从20k增长到60k的过程中,eim的性能略微高于opindex和be-tree,都是随着属性数量的增长,事件匹配的效率轻微地逐渐增大,因此eim适合用于大数据的应用场景。而k-index在订阅数量很多的时候效率不高。这是由于eim最小化了事件匹配的计算复杂度,因此性能优于opindex、be-tree和k-index。在订阅数量从1m到40m的过程中,eim匹配事件时消耗的时间几乎没有变化,都是具有最好的事件匹配性能,是opindex的2倍、be-tree的4倍、k-index的数十倍以上。k-index效率最低的原因有二:①没有按照核心属性来进行划分,而是按照订阅容量进行划分,因此不够高效;②候选匹配集远大于eim,因此性能低于eim。be-tree采用了等级聚类因此性能高于k-index,但是低于eim。而opindex的索引结构比eim复杂,因此性能低于eim。在订阅最大容量从4增长到20的过程中,eim具有最优秀的性能。并且随着订阅容量的增长,性能下降的速度几乎可以忽略不计。同时,eim的性能略微优于opindex和be-tree并远优于k-index。这是由于eim将操作分成析取索引和合取索引省略了操作判断过程。在事件最大容量从20增长到100的过程中,eim的性能明显高于opindex、be-tree和k-index。并且随着事件最大容量的增长,eim的性能几乎没有任何下降。这是由于eim简化了索引结构。在值空间从50增长到12800的过程中,eim具有最优秀的性能。并且随着订阅容量的增长,性能下降的速度几乎可以忽略不计。同时,eim的性能明显优于opindex、be-tree和k-index。这是由于eim最小化了事件匹配的计算复杂度。订阅更新与订阅数量和订阅最大容量相关,因此试验结果如图14和图15所示。其中,纵坐标表示更新时间,单位是秒(s)。图14的横坐标表示订阅数量,图15的横坐标表示订阅最大容量。k-index更新的时候需要更新整个订阅组,be-tree需要更新被聚合的订阅组,opindex需要更新反向插入列和相关订阅组,而eim只需要更新少量的相关订阅。因此,eim的性能优于opindex、be-tree和k-index。eim的性能略微优于opindex和be-tree,非常显著的优于k-index。这是由于eim的订阅更新操作简化了更新对象,因此性能受订阅最大容量的影响不大。综合所有试验数据,可以得出以下结论:(1)eim的综合性能明显优于现有的三种方法:opindex、be-tree和k-index。(2)由于面对各种参数都具有非常优秀的性能,因此eim可以广泛的用于各种应用场景,例如大数据,分布式计算,电子商务,手机平台,云计算等。本发明考虑了发布/订阅中的高效匹配问题,现有的方法有的内存消耗较高、有的订阅匹配性能不够高效、有的无法支持动态订阅。为此,本发明提出了一种高效的订阅索引方法eim,将分组以后的订阅与分组以后的谓词合并构成新的订阅索引。同时提供了订阅更新算法用于支持动态订阅。从而提供高效的动态发布/订阅匹配性能,并且具有更小的内存消耗。当前第1页12
当前第1页1 2 
网友询问留言 已有0条留言
  • 还没有人留言评论。精彩留言会获得点赞!
1