CN103605704B - 大量url数据任意字段索引及检索方法 - Google Patents
大量url数据任意字段索引及检索方法 Download PDFInfo
- Publication number
- CN103605704B CN103605704B CN201310554903.XA CN201310554903A CN103605704B CN 103605704 B CN103605704 B CN 103605704B CN 201310554903 A CN201310554903 A CN 201310554903A CN 103605704 B CN103605704 B CN 103605704B
- Authority
- CN
- China
- Prior art keywords
- url
- cutting
- data
- search
- length
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/90—Details of database functions independent of the retrieved data types
- G06F16/95—Retrieval from the web
- G06F16/955—Retrieval from the web using information identifiers, e.g. uniform resource locators [URL]
Abstract
本发明公开了一种大量url数据任意字段索引及检索方法,在建立索引时,包括以下步骤:反转url;按设定的切分长度对url进行切分成关键字;建立倒排索引表;在进行索引时,包括以下步骤:反转作为检索关键词的url片段;按设定的切分长度对检索url片段进行切分作为检索用的关键字;在倒排索引表中分别用切分后的检索关键字进行查找;查找结果的交集指向的url为检索到的url。本发明对大量的url数据的检索可以获得较高的效率。
Description
[技术领域]
本发明涉及计算机网络地址,尤其涉及一种大量url数据任意字段索引及检索方法。
[背景技术]
传统的文本信息检索主要使用分词与倒排索引技术,但是传统的切词方法并不能满足url(Uniform Resource Locator,统一资源定位符)任意字段匹配检索的需求。传统的字符串匹配技术都只是针对少量的文本数据,对于大量url数据并不适合,在数据量比较大(GB级以上)的情况下,其检索效率不能满足用户需求。
[发明内容]
本发明要解决的技术问题是提供一种在数据量比较大的情况下,检索效率较高的大量url数据任意字段索引及检索方法。
为了解决上述技术问题,本发明采用的技术方案是,一种大量url数据任意字段索引及检索方法,在建立索引时,包括以下步骤:
101)反转url;
102)按设定的切分长度对url进行切分成关键字;
103)建立倒排索引表;
在进行索引时,包括以下步骤:
104)反转作为检索关键词的url片段;
105)按设定的切分长度对检索url片段进行切分作为检索用的关键字;
106)在倒排索引表中分别用切分后的检索关键字进行查找;
107)查找结果的交集指向的url为检索到的url。
以上所述的大量url数据任意字段索引及检索方法,
201)在步骤101之后,步骤102之前,用分隔符对url进行切分;
202)在步骤104之后,步骤105之前,用分隔符对检索url片段进行切分。
以上所述的大量url数据任意字段索引及检索方法,
301)在步骤101之后,步骤102之前,对url数据进行压缩;并建立基础数据表和一对多的转换表;在基础数据表中将同样的url数据列为一条,并建立与之对应的ID;在转换表中列出与新建ID对应的所有url数据的编号。
以上所述的大量url数据任意字段索引及检索方法,所述的倒排索引表即是一个K-V结构的记录集合,其中K是检索关键字,V即是对应的记录编号集合;倒排索引表即是以检索关键字为键有序存储的数据结构。
以上所述的大量url数据任意字段索引及检索方法,对url或url片段进行切分时,以设定的切分长度向后切分,最后剩余长度如果不足设定的切分长度时,则按设定的切分长度从后向前取字符作为最后的关键字,全部关键字的长度等于设定的切分长度。
以上所述的大量url数据任意字段索引及检索方法,设定的切分长度为20。
以上所述的大量url数据任意字段索引及检索方法,所述分隔符是“?”和/或“&”。
本发明的索引及检索方法对大量的url数据可以获得较高的检索效率。
[附图说明]
下面结合附图和具体实施方式对本发明作进一步详细的说明。
图1是本发明实施例倒排索引建立的流程图。
图2是本发明实施例使用倒排索引表执行检索的流程图。
[具体实施方式]
(1)逐个字符切词:
为了支持任意字符子串的快速匹配检索,必须对url进行逐个字符的细致切分,并使用切分后的url片段建立倒排索引,解决任意字符子串匹配检索的问题。
不限定长度的逐个字符切分即是对字符串一个一个字符的向后滑动切去子串
如abcdef切分如下:
abcdef
bcdef
cdef
def
ef
最后切分到只有两个字符,之所以不切分到只有一个字符,是因为切分出来的子串都是将来建立索引所有的关键字,单个字符作为检索关键字在实际的应用中没有意义。
对于www.baidu.com,则切分结果如下:
www.baidu.com |
ww.baidu.com |
w.baidu.com |
.baidu.com |
baidu.com |
aidu.com |
idu.com |
du.com |
u.com |
.com |
com |
om |
如上所述,这里的切分没有细致到url的最后一个字符,因为一般没有针对单个字符进行检索的需求。
上面的切分是不限定长度的切分,限定切分长度即每个分割出来的子串的最大长度是固定的。设最大分割长度固定为4,则上面abcdef切分的结果为:
abcd
bcde
cdef
def
ef
固定切分的长度,主要是为了减少关键字的长度,增加关键字的重复率,从而减少索引的数据量。
使用切分后的url片段建立倒排索引即可支持url任意字符子串的快速检索,倒排索引源于实际应用中需要根据属性的值来查找记录。这种索引表中的每一项都包括一个属性值和具有该属性值的各记录的编号。由于不是由记录来确定属性值,而是由属性值来确定记录,因而称为倒排索引(inverted index)。
本文中属性值就是切分出来的url片段,称之为检索关键字。对应的记录编号即是相应的url所在记录的编号。一个检索关键字会对应很多的记录编号。
实际上倒排索引表即是一个K-V结构的记录集合,这里K(Key)即是检索关键字,V(Value)即是对应的记录编号集合。倒排索引表即是以K为键有序存储的数据结构,如B+树等。
假设我们有两个url记录,如下:
ID url
1)www.sohu.com
2)www.baidu.com
对上面的记录建立倒排索引,可以得到倒排索引表如下表1:
表1,逐个字符切分建立倒排索引示例表
Key | Value |
.baidu.com | 2 |
.com | 1,2 |
.sohu.com | 1 |
aidu.com | 2 |
baidu.com | 2 |
com | 1,2 |
du.com | 2 |
hu.com | 1 |
idu.com | 2 |
ohu.com | 1 |
om | 1,2 |
sohu.com | 1 |
u.com | 1,2 |
w.baidu.com | 2 |
w.sohu.com | 1 |
ww.baidu.com | 2 |
ww.sohu.com | 1 |
www.baidu.com | 2 |
www.sohu.com | 1 |
如表1所示,表中的Key即是检索关键字(任意的url片段),Value是检索对象(ID串,含有检索关键字的记录编号集合)。使用上面的倒排索引表即可进行url任意字符子串的快速匹配检索,例如检索“ww”即可知记录(1,2)的url包含该字符子串,检索“du.com”即可知记录(2)的url包含该记录子串,这里使用的检索方式都是前缀匹配检索,检索结果会经过归并等进一步的处理才会形成最终返回给用户的结果。
上述方法虽然解决了url任意字符子串匹配检索的问题,但是会引起巨大的数据膨胀问题,实际应用当中的url的长度经常会有几百个字符,这样的数据膨胀用户可能无法接受。
空间大小以字节为单位计算,则原始url数据的大小可表示为:
n*(K+L);
其中,K表示url的平均长度
L表示记录编号(ID)的长度
n表示记录总数
w表示url的最大长度
ni表示长度为i的记录数(1≤i≤w)。
所建立倒排索引的大小也可以计算出来,如果使用平均值K只能计算出一个估计值,实际的值会比该值更大,但该结果表达式较为直观,如下所示:
使用ni即可计算出精确的索引数据大小,但该表达式不够直观,如下所示:
上述表达式中e是一个平衡重复url片段的常数因子(0<e<1),比如在上面的例子中,url片段“u.com”在记录1和记录2中都有出现,但在倒排索引表中就只有一个倒排索引记录{“u.com”,(1,2)}。e、ni、K等都是可以通过数据统计计算出来的。
(2)将url反转后再切分
反转就是简单的字符串逆置,如abcd,反转就变为dcba。
分析url的组成特性可知,同一个主机后面一般会有很多不同的路径,同一个路径后面一般会有很多不同的参数,它是一个多叉的树状结构。以下面的两个url为例,它们有相同的主机名,但是路径不同:
news.ifeng.com/mil/2/detail_2013_05/03/24892748_0.shtml
news.ifeng.com/mil/1/detail_2013_05/03/24892315_0.shtml
现在将这两个url反转,结果如下:
lmths.0_84729842/30/50_3102_liated/2/lim/moc.gnefi.swen
lmths.0_51329842/30/50_3102_liated/1/lim/moc.gnefi.swen
可以明显的看出,url反转后再进行逐个字符的切词会提高所切分url片段的重复率,减少倒排索引表中倒排记录的数量,从而达到减少索引数据量的目的。当然使用反转的url建立索引,用户的检索条件也需要反转后才能使用。
这里表示倒排索引大小的表达式和前面基本一致,只是常数因子会更小,如下:
eto是常数因子,且0<eto<e,具体eto的值可以通过实际数据测试计算得到。
(3)固定切分关键字长度
逐个字符切词,但url片段的最大长度是固定的,以“www.baidu.com”为例,设url片段的最大长度为5,则切分结果如下:
www.b |
ww.ba |
w.bai |
.baid |
baidu |
aidu. |
idu.c |
du.co |
u.com |
.com |
com |
om |
固定url片段的最大长度一方面会减小url片段的长度,从而减少切分关键字的数据量,另一方面url片段的重复率也会增加,即常数因子也会变小。假设:
m表示url片段的最大长度;
则倒排索引的大小可表示如下:
上述表达式中有条件m<K成立,如果该条件不成立,则固定切分关键字长度的方法将没有意义。同样efl是平衡重复url片段的常数因子,且有0<efl<e成立,如果是反转url之后再使用该方法,则有0<efl<eto成立。
如果使用上述切词方法切分出的url片段建立倒排索引,则当用户检索关键字的长度大于m时,需要将检索关键字按照最大长度进行分割。设检索条件为“ww.baidu.com”,m=5,则分割结果为:“ww.ba”、“idu.c”、“u.com”。使用分割后的检索关键字片段分别在倒排索引表里面执行检索,最后将各个检索结果进行归并,归并的结果一般都满足检索条件,因此在最终返回给用户时需要对归并结果里面的每一个记录进行进一步的过滤验证以剔除不满足条件的检索记录。这里的检索方式都是精确检索,将检索条件分割成长度为m的片段正是为了这个目的,因为精确查找的速度更快,返回的结果只有一个倒排索引记录。如果用户检索关键字的长度小于m,则直接使用检索关键字执行前缀匹配检索。
url片段最大长度(m的值)为多少合适,这个问题需要实际的测试数据来验证。m越小,倒排索引表所占的空间越小,检索执行的难度越大(因为检索关键字会被分割成更多的片段,这就需要执行更多的检索,并对这些检索结果执行归并);m越大,检索执行的难度越小,但倒排索引表所占的空间越大。
通过实际测试,切分长度为20是一个比较理想的选择。
(4)用分隔符分割url后再分词
前面所展示的url示例都是比较简单、比较短的url示例,下面是两个较为复杂的url示例,如下所示:
ishare.iask.sina.com.cn/search.php?key=%B8%DF%D6%D0%CA%FD%D1%A7&from=index&format=
ishare.iask.sina.com.cn/search.php?key=%CA%FD%D1%A7%B7%D6%CE%F6&format=
可以看出上面两个url都是由主机、路径以及参数组成的。分隔符为“?”和“&”,对示例中的第一个url进行分割,结果如下:
ishare.iask.sina.com.cn/search.php?
?key=%B8%DF%D6%D0%CA%FD%D1%A7&
&from=index&
&format=
分割时,分隔符在分割时重复了一次,这是因为逐个字符分词时最小只切分到两个字符。
上面提到的url反转方法以及固定切分关键字长度方法都可以对按分隔符分割后的url片段使用。使用分隔符将url分割成片段,在一定的程度上可以减少切分关键字的数据量,但这个作用并不是特别明显,该方法更重要的作用是增加了url片段的重复率,特别是和下面介绍的“转换表压缩算法”一起使用时会取得更好的效果。
若在使用分隔符分割法的基础上建立倒排索引,则在处理用户检索时也必须考虑检索关键字中间含有的分隔符。
以上介绍的三个改进切词方法的办法是可以相互结合起来使用的,使用的方法越复杂,减少数据膨胀的效果越好,但对用户检索的处理也会相对复杂。以上三个方法的关注点主要在两个方面,一个是减少切分关键字的数据量,另一个是增加url片段的重复率,但是对于减少检索对象(记录编号集合,ID串)的数据量却没有什么帮助。
(5)基于转换表的数据压缩
海量url记录中很多记录的url字段是重复的,如表2所示:
表2,重复url记录示例表
表2所显示的6个url记录中,记录1和记录6二者的url字段是一样的,记录2和记录4二者的url字段也是一样的。在建立倒排索引表时,相同的url会被切分成相同的url片段,记录编号1和6会同时出现在多个倒排索引记录的Value里面(记录编号集合,即ID串),而且它们总是会同时出现,如果一个倒排索引记录的Value里面有记录编号1,那么也一定会有记录编号6。因此可以把记录编号1和记录编号6看成集合,并使用一个特定编号来代表该集合,推而广之,可以将所有拥有相同url的记录都看成一个集合,每个集合都有一个唯一的集合编号,这样在建立倒排索引表时就不需要在Value中存储所有的记录编号(它们具有相同的url),只需要存储一个集合编号即可。该方法需要一个将集合编号转换为记录编号集合的转换表,因此本发明将它称为“转换表压缩算法”。
“转换表压缩算法”利用url数据重复率高的特性来减少索引的数据量。因为有重复,所以可将重复的url聚合在一起,只用一个来做代表,这样显然即可减少数据量。但用一个来表示多个,这需要一个一对多的转换关系,本发明就是使用一个转换表来存储这种转换关系。
针对上面的6个url记录示例,对它们使用“转换表压缩算法”,结果如下:
表3(a),基础数据表
表3(b),集合编号与记录编号集合转换表
集合ID | 记录ID集合 |
A | 1,6 |
B | 2,4 |
表3,(a)基础数据表,(b)集合编号与记录编号集合转换表使用转“换表压缩算法”对数据进行处理之后,在建立倒排索引时使用的是基础数据表的数据,很明显基础数据表的数据量要小于原始url记录表的数据量,表2中有6条记录,而在表3(a)的基础数据表中只有4条记录。
需要强调的是,在最终建立的倒排索引表的数据量虽然会有一点程度的减少,但这些数据量的减少并不是由于切分关键字数据量的减少或者倒排索引记录的减少所导致的,而是因为倒排索引记录中Value的数据量减少所导致的。
倒排索引表减少的数据量可以用如下表达式计算:
R*L*(K1-1)(T-1)-R*L*(T+1)
其中,R表示转换表中的记录数;
T表示转换表中记录ID集合的平均长度(即ID的个数);
集合ID与记录ID的长度相同,为L;
K1表示重复url的平均长度;
在实际应用中由于url重复出现的情况很常见,因此“转换表压缩算法”的效果十分明显。
如果使用分隔符分割url,并对分割后的url片段使用“转换表压缩算法”则数据压缩的效果会更好。以表2中的url记录为例,使用分隔符切分之后,结果如下:
表4,分隔符分割url示例表
ID | url片段 |
1 | movie.youku.com/new/index |
2 | news.xinmin.cn/world/2013/05/05/20085965.html |
3 | ishare.iask.sina.com.cn/search.php? |
3 | ?key=%B8%DF%D6%D0%CA%FD%D1%A7& |
3 | &from=index& |
3 | &format= |
4 | news.xinmin.cn/world/2013/05/05/20085965.html |
5 | ishare.iask.sina.com.cn/search.php? |
5 | ?key=%CA%FD%D1%A7%B7%D6%CE%F6& |
5 | &format= |
6 | movie.youku.com/new/index |
对表4中的url片段使用“转换表压缩算法”,则得到结果如下:
表5(a),基础数据表
表5(b),转换表
集合ID | 记录ID集合 |
A | 1,6 |
B | 2,4 |
C | 3,5 |
D | 3,5 |
从表5中可以明显的看出,在对url片段使用“转换表压缩算法”之后,由于url片段拥有更高的重复率,导致基础数据表的数据量更小,从而进一步减少了倒排索引表的数据量。
倒排索引表减少的数据量可以用如下表达式计算:
R*L*(K2-1)(T-1)-R*L*(T+1)
其中K2是重复url片段的平均长度;
在实际当中,由于使用了多种技术来改进切词方法,切分后的检索关键字在倒排索引中数据量已经大大的减少,检索关键字的重复率也有了很大的提高,影响倒排索引表大小的关键因素已从检索关键字变为检索对象(ID串),“转换表压缩算法”可以较为有效的解决该问题。
使用“转换表压缩算法”建立的倒排索引,在执行检索时需要将检索结果(混合ID集合)里面的集合ID转换成对应的记录ID集合。
(6)综合实施例
本发明综合使用上面的五种方法,即可取得最好的效果。具体综合流程如图1所示,下面以一个具体的实例来诠释整个步骤与流程,:
表6,综合实施例原始url示例表
第一步,反转原始url,得到结果如下:
表7,对表6的数据使用反转url方法后得到的结果
第二步,使用分隔符“?”与“&”分割翻转后的url,得到结果如下:
表8,对表7的数据使用殊字符分割url方法后得到的结果
1 | xedni/wen/moc.ukuoy.eivom |
2 | lmth.56958002/50/50/3102/dlrow/nc.nimnix.swen |
3 | =tamrof& |
3 | &xedni=morf& |
3 | &7A%1D%DF%AC%0D%6D%FD%8B%=yek? |
3 | ?php.hcraes/nc.moc.anis.ksai.erahsi |
4 | lmth.56958002/50/50/3102/dlrow/nc.nimnix.swen |
5 | =tamrof& |
5 | &6F%EC%6D%7B%7A%1D%DF%AC%=yek? |
5 | ?php.hcraes/nc.moc.anis.ksai.erahsi |
6 | xedni/wen/moc.ukuoy.eivom |
第三步,使用转换表压缩算法处理表8的数据,得到结果如下:
表9,对表8的数据使用转换表压缩算法后得到的结果表9(a),基础数据表
表9(b),转换表
集合ID | 记录ID集合 |
A | 1,6 |
B | 2,4 |
C | 3,5 |
D | 3,5 |
第四步,使用固定切分关键字长度的方法处理基础数据表9(a)的数据,即得到最终的倒排索引表,固定切分长度以5为例,结果如下:
表10,对表9的数据使用固定关键字切分长度建立倒排索引方法得到的倒排索引表
编号 | Key | Value | 编号 | Key | Value | 编号 | Key | Value | 编号 | Key | Value |
1 | %=yek | 3,5 | 42 | 02/50 | B | 83 | D%8B% | 3 | 124 | mth.5 | B |
2 | %0D%6 | 3 | 43 | 02/dl | B | 84 | D%DF% | 3,5 | 125 | n/moc | A |
3 | %1D%D | 3,5 | 44 | 0D%6D | 3 | 85 | D%FD% | 3 | 126 | nc.mo | C |
4 | %6D%7 | 5 | 45 | 102/d | B | 86 | DF%AC | 3,5 | 127 | nc.ni | B |
5 | %6D%F | 3 | 46 | 1D%DF | 3,5 | 87 | dlrow | B | 128 | ni/we | A |
6 | %7A%1 | 5 | 47 | 2/50/ | B | 88 | dni/w | A | 129 | ni=mo | 3 |
7 | %7B%7 | 5 | 48 | 2/dlr | B | 89 | dni=m | 3 | 130 | nimni | B |
8 | %8B%= | 3 | 49 | 3102/ | B | 90 | EC%6D | 5 | 131 | nis.k | C |
9 | %AC%= | 5 | 50 | 50/31 | B | 91 | edni/ | A | 132 | nix.s | B |
10 | %AC%0 | 3 | 51 | 50/50 | B | 92 | edni= | 3 | 133 | oc.an | C |
11 | %DF%A | 3,5 | 52 | 56958/ | B | 93 | eivom | A | 134 | oc.uk | A |
12 | %EC%6 | 5 | 53 | 58002/ | B | 94 | ek? | 3,5 | 135 | of& | D |
13 | %FD%8 | 3 | 54 | 69580/ | B | 95 | en | B | 136 | om | A |
14 | &6F%E | 5 | 55 | 6D%7B | 5 | 96 | en/mo | A | 137 | orf& | 3 |
15 | &7A%1 | 3 | 56 | 6D%FD | 3 | 97 | erahs | C | 138 | ow/nc | B |
16 | &xedn | 3 | 57 | 6F%EC | 5 | 98 | es/nc | C | 139 | oy.ei | A |
17 | .5695/ | B | 58 | 7A%1D | 3,5 | 99 | F%AC% | 3,5 | 140 | p.hcr | C |
18 | .anis | C | 59 | 7B%7A | 5 | 100 | F%EC% | 5 | 141 | php.h | C |
19 | .eivo | A | 60 | 8002/ | B | 101 | f& | 3,D | 142 | raes/ | C |
20 | .erah | C | 61 | 8B%=y | 3 | 102 | FD%8B | 3 | 143 | rahsi | C |
21 | .hcra | C | 62 | 95800/ | B | 103 | h.569 | B | 144 | rf& | 3 |
22 | .ksai | C | 63 | A%1D% | 3,5 | 104 | hcrae | C | 145 | rof& | D |
23 | .moc. | C | 64 | AC%=y | 5 | 105 | hp.hc | C | 146 | row/n | B |
24 | .nimn | B | 65 | AC%0D | 3 | 106 | hsi | C | 147 | s.ksa | C |
25 | .swen | B | 66 | aes/n | C | 107 | i.era | C | 148 | s/nc. | C |
26 | .ukuo | A | 67 | ahsi | C | 108 | i/wen | A | 149 | sai.e | C |
27 | /3102 | B | 68 | ai.er | C | 109 | i=mor | 3 | 150 | si | C |
28 | /50/3 | B | 69 | amrof | D | 110 | imnix | B | 151 | swen | B |
29 | /50/5 | B | 70 | anis. | C | 111 | is.ks | C | 152 | tamro | D |
30 | /dlro | B | 71 | B%=ye | 3 | 112 | ivom | A | 153 | th.56 | B |
31 | /moc. | A | 72 | B%7A% | 5 | 113 | ix.sw | B | 154 | ukuoy | A |
32 | /nc.m | C | 73 | C%=ye | 5 | 114 | k? | 3,5 | 155 | uoy.e | A |
33 | /nc.n | B | 74 | C%0D% | 3 | 115 | ksai. | C | 156 | vom | A |
34 | /wen/ | A | 75 | C%6D% | 5 | 116 | kuoy. | A | 157 | w/nc. | B |
35 | ?php. | C | 76 | c.ani | C | 117 | lmth. | B | 158 | wen | B |
36 | =morf | 3 | 77 | c.moc | C | 118 | lrow/ | B | 159 | wen/m | A |
37 | =tamr | D | 78 | c.nim | B | 119 | mnix. | B | 160 | x.swe | B |
38 | =yek? | 3,5 | 79 | c.uku | A | 120 | moc.a | C | 161 | xedni | 3,A |
39 | 0/310 | B | 80 | craes | C | 121 | moc.u | A | 162 | y.eiv | A |
40 | 0/50/ | B | 81 | D%6D% | 3 | 122 | morf& | 3 | 163 | yek? | 3,5 |
41 | 002/5 | B | 82 | D%7B% | 5 | 123 | mrof& | D |
通过以上四步,即可建立倒排索引。在检索时也需要对用户的检索条件做相应的处理,具体的步骤参见图2。假设有如下的用户检索条件:
com.cn/search.php?key
第一步,反转用户检索条件,即反转检索url片段:
yek?php.hcraes/nc.moc
第二步,使用分隔符将倒转后的url片段分割为多个小url片段,得到结果如下:
yek??php.hcraes/nc.moc
第三步,小url片段yek?的长度小于5,不做处理;?php.hcraes/nc.moc的长度为18,因此需要将其切分;切分后的检索关键字的固定长度应该与倒排索引表的固定最大切分长度相等,如切分长度为5,那就以5个字符长度为单位向后切分,最后剩余长度如果不足5时,则从后向前切分五个字符作为最后的检索关键字。?php.hcraes/nc.moc需要将其切分为4个固定长度为5的检索关键字如下:
?php.hcrae s/nc.c.moc
第四步,在倒排索引表10中对检索关键字yek?执行前缀查找,可得记录:
yek?3,5
对四个长度为五的检索关键字(?php.hcrae s/nc.c.moc)分别执行精确查找,可得记录:
求它们检索结果的交集为C,C是集合ID,在转换表中查找可知C对应的记录ID集合为(3,5)。
第五步,将小url片段yek?与?php.hcraes/nc.moc的检索结构求交集,得到记录ID集合(3,5),在原始数据表中使用记录ID进行查找可得:
3
ishare.iask.sina.com.cn/search.php?key=%B8%DF%D6%D0%CA%FD%D1%A7&f rom=index&format=
5
ishare.iask.sina.com.cn/search.php?key=%CA%FD%D1%A7%B7%D6%CE%F6&f ormat=
通过验证可知这两个url记录都含有url片段com.cn/search.php?key,满足用户的检索条件。将检索结构返回用户即可。
本发明以上实施例使用逐个字符切分的方法对url进行切分,并使用切分后的url片段建立倒排索引,从而解决了该问题;但是该方法所建立的倒排索引占用的空间大小是原始数据的数十倍,为了解决数据膨胀问题,本发明对切词方法进行了多方面的改进,并使用了“转换表压缩算法”等解决方法,最终将索引数据的膨胀由原来原始数据的约60倍降到3倍左右。
Claims (7)
1.一种大量url数据任意字段索引及检索方法,其特征在于,在建立索引时,包括以下步骤:
101)反转url;
102)按设定的切分长度对url进行切分成关键字;
103)建立倒排索引表;
在进行索引时,包括以下步骤:
104)反转作为检索关键词的url片段;
105)按设定的切分长度对检索url片段进行切分作为检索用的关键字;
106)在倒排索引表中分别用切分后的检索关键字进行查找;
107)查找结果的交集指向的url为检索到的url。
2.根据权利要求1所述的大量url数据任意字段索引及检索方法,其特征在于,
201)在步骤101之后,步骤102之前,用分隔符对url进行切分;
202)在步骤104之后,步骤105之前,用分隔符对检索url片段进行切分。
3.根据权利要求1所述的大量url数据任意字段索引及检索方法,其特征在于,
301)在步骤101之后,步骤102之前,对url数据进行压缩;并建立基础数据表和一对多的转换表;在基础数据表中将同样的url数据列为一条,并建立与之对应的ID;在转换表中列出与新建ID对应的所有url数据的编号。
4.根据权利要求1所述的大量url数据任意字段索引及检索方法,其特征 在于,所述的倒排索引表即是一个K-V结构的记录集合,其中K是检索关键字,V即是对应的记录编号集合;倒排索引表即是以检索关键字为键有序存储的数据结构。
5.根据权利要求1所述的大量url数据任意字段索引及检索方法,其特征在于,对url或url片段进行切分时,以设定的切分长度向后切分,最后剩余长度如果不足设定的切分长度时,则按设定的切分长度从后向前取字符作为最后的关键字,全部关键字的长度等于设定的切分长度。
6.根据权利要求1所述的大量url数据任意字段索引及检索方法,其特征在于,设定的切分长度为20。
7.根据权利要求2所述的大量url数据任意字段索引及检索方法,其特征在于,所述分隔符是“?”和“/”或“&”。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201310554903.XA CN103605704B (zh) | 2013-11-08 | 2013-11-08 | 大量url数据任意字段索引及检索方法 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201310554903.XA CN103605704B (zh) | 2013-11-08 | 2013-11-08 | 大量url数据任意字段索引及检索方法 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN103605704A CN103605704A (zh) | 2014-02-26 |
CN103605704B true CN103605704B (zh) | 2017-02-01 |
Family
ID=50123927
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN201310554903.XA Expired - Fee Related CN103605704B (zh) | 2013-11-08 | 2013-11-08 | 大量url数据任意字段索引及检索方法 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN103605704B (zh) |
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2019133294A1 (en) * | 2017-12-26 | 2019-07-04 | Didi Research America, Llc | System and method for uniform resource identifier (uri) consolidation |
Families Citing this family (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN105426759A (zh) * | 2015-10-30 | 2016-03-23 | 百度在线网络技术(北京)有限公司 | Url的合法性识别方法及装置 |
CN106776657B (zh) * | 2015-11-25 | 2021-05-04 | 阿里巴巴集团控股有限公司 | 一种域名检索方法及设备 |
CN108509437B (zh) * | 2017-02-24 | 2021-09-17 | 南京烽火星空通信发展有限公司 | 一种ElasticSearch查询加速方法 |
CN108228710B (zh) * | 2017-11-30 | 2021-09-28 | 中国科学院信息工程研究所 | 一种针对url的分词方法及装置 |
CN108306771B (zh) * | 2018-02-09 | 2021-06-18 | 腾讯科技(深圳)有限公司 | 日志上报方法、装置及系统 |
CN109061020B (zh) * | 2018-09-28 | 2020-08-07 | 深圳市绘云生物科技有限公司 | 一种基于气相/液相色谱质谱平台的数据分析系统 |
CN110879819A (zh) * | 2019-11-20 | 2020-03-13 | 北京明略软件系统有限公司 | 路由信息快速准确识别方法、装置、服务器及存储介质 |
Citations (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JPH1139340A (ja) * | 1997-07-24 | 1999-02-12 | N T T Data:Kk | データベース検索システム、マルチプロセッサシステム及びデータベース検索方法 |
JP2001052033A (ja) * | 1997-07-18 | 2001-02-23 | Internatl Business Mach Corp <Ibm> | Url管理装置およびその方法 |
CN101030897A (zh) * | 2007-02-07 | 2007-09-05 | 华为技术有限公司 | 一种入侵检测中模式匹配的方法和装置 |
CN101499098A (zh) * | 2009-03-04 | 2009-08-05 | 阿里巴巴集团控股有限公司 | 一种网页评估值的确定及运用的方法、系统 |
CN102663022A (zh) * | 2012-03-21 | 2012-09-12 | 浙江盘石信息技术有限公司 | 一种基于url的分类识别方法 |
CN103092844A (zh) * | 2011-10-28 | 2013-05-08 | 腾讯科技(深圳)有限公司 | 一种索引建立方法和系统、搜索方法和系统 |
-
2013
- 2013-11-08 CN CN201310554903.XA patent/CN103605704B/zh not_active Expired - Fee Related
Patent Citations (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2001052033A (ja) * | 1997-07-18 | 2001-02-23 | Internatl Business Mach Corp <Ibm> | Url管理装置およびその方法 |
JPH1139340A (ja) * | 1997-07-24 | 1999-02-12 | N T T Data:Kk | データベース検索システム、マルチプロセッサシステム及びデータベース検索方法 |
CN101030897A (zh) * | 2007-02-07 | 2007-09-05 | 华为技术有限公司 | 一种入侵检测中模式匹配的方法和装置 |
CN101499098A (zh) * | 2009-03-04 | 2009-08-05 | 阿里巴巴集团控股有限公司 | 一种网页评估值的确定及运用的方法、系统 |
CN103092844A (zh) * | 2011-10-28 | 2013-05-08 | 腾讯科技(深圳)有限公司 | 一种索引建立方法和系统、搜索方法和系统 |
CN102663022A (zh) * | 2012-03-21 | 2012-09-12 | 浙江盘石信息技术有限公司 | 一种基于url的分类识别方法 |
Non-Patent Citations (1)
Title |
---|
应对海量数据检索分布式局部索引的架构;张滇等;《计算机时代》;20130815;第1-4页 * |
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2019133294A1 (en) * | 2017-12-26 | 2019-07-04 | Didi Research America, Llc | System and method for uniform resource identifier (uri) consolidation |
Also Published As
Publication number | Publication date |
---|---|
CN103605704A (zh) | 2014-02-26 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN103605704B (zh) | 大量url数据任意字段索引及检索方法 | |
US8533203B2 (en) | Identifying synonyms of entities using a document collection | |
US11036685B2 (en) | System and method for compressing data in a database | |
Karpinski et al. | Top-k color queries for document retrieval | |
US9405819B2 (en) | Efficient indexing using compact decision diagrams | |
CN106503223B (zh) | 一种结合位置和关键词信息的在线房源搜索方法及装置 | |
WO2014169265A1 (en) | Storing and querying graph data in a key-value store | |
EP2812815A1 (en) | Web page retrieval method and device | |
CN103218443A (zh) | 一种面向博客网页的网页检索系统及方法 | |
Bramandia et al. | On incremental maintenance of 2-hop labeling of graphs | |
KR20180021074A (ko) | 무손실 축소된 데이터에 대한 기본 데이터 시브를 사용한 다차원 탐색, 내용 연관 검색, 및 키워드 기반 탐색 및 검색의 수행 | |
CN105718521A (zh) | 一个基于Wavelet Tree的网络数据包索引系统 | |
Belazzougui et al. | A framework for space-efficient string kernels | |
Kim et al. | PcapWT: An efficient packet extraction tool for large volume network traces | |
Gagie et al. | Heaviest induced ancestors and longest common substrings | |
Belazzougui et al. | Compressed string dictionary search with edit distance one | |
Jekovec et al. | Parallel query in the suffix tree | |
Pibiri | Fast and compact set intersection through recursive universe partitioning | |
Patel et al. | Inverse suffix array queries for 2-dimensional pattern matching in near-compact space | |
Kosolobov et al. | Compressed multiple pattern matching | |
Song et al. | Design of Index Schema based on Bit-Streams for XML Documents | |
KR100645711B1 (ko) | 다수의 정보 블록으로 구분된 웹 페이지를 이용한 정보검색 서비스 제공 서버, 방법 및 시스템 | |
Abedin | Efficient Data Structures for Text Processing Applications | |
Kashgouli | A Kraken-like tool with k given at query time and an index for finding approximately longest common substrings | |
Chen et al. | PLQ: An Efficient Approach to Processing Pattern-Based Log Queries |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
C06 | Publication | ||
PB01 | Publication | ||
SE01 | Entry into force of request for substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
C14 | Grant of patent or utility model | ||
GR01 | Patent grant | ||
CF01 | Termination of patent right due to non-payment of annual fee | ||
CF01 | Termination of patent right due to non-payment of annual fee |
Granted publication date: 20170201 Termination date: 20191108 |