具体理解
Oracle实现全文检索,其机制其实很简单。即通过Oracle专利的词法分析器(lexer),将文章中所有的表意单元(Oracle称为term,此处我理解为单词或者一些有意义的词语) 找出来,记录在一组以dr$开头的表中,同时记下该term出现的位置、次数、hash 值等信息。检索时,Oracle 从这组表中查找相应的 term,并计算其出现频率,根据某个算法来计算每个文档的得分(score),即所谓的‘匹配率’。而lexer则是该机制的核心,它决定了全文检索的效率。Oracle 针对不同的语言提供了不同的 lexer, 而我们通常能用到其中的三个:
basic_lexer: 针对英语。它能根据空格和标点来将英语单词从句子中分离,还能自动将一些出现频率过高已经失去检索意义的单词作为‘垃圾’处理,如if , is 等,具有较高的处理效率。但该lexer应用于汉语则有很多问题,由于它只认空格和标点,而汉语的一句话中通常不会有空格,因此,它会把整句话作为一个term,事实上失去检索能力。以‘中国人民站起来了’这句话为例,basic_lexer 分析的结果只有一个term ,就是‘中国人民站起来了’。此时若检索‘中国’,将检索不到内容。
chinese_vgram_lexer: 专门的汉语分析器,支持所有汉字字符集。该分析器按字为单元来分析汉语句子。‘中国人民站起来了’这句话,会被它分析成如下几个term: ‘中’,‘中国’,‘国人’,‘人民’,‘民站’,‘站起’,起来’,‘来了’,‘了’。可以看出,这种分析方法,实现算法很简单,并且能实现‘一网打尽’,但效率则是差强人意。
chinese_lexer: 这是一个新的汉语分析器,只支持utf8字符集。上面已经看到,chinese vgram lexer这个分析器由于不认识常用的汉语词汇,因此分析的单元非常机械,像上面的‘民站’,‘站起’在汉语中根本不会单独出现,因此这种term是没有意义的,反而影响效率。chinese_lexer的最大改进就是该分析器能认识大部分常用汉语词汇,因此能更有效率地分析句子,像以上两个愚蠢的单元将不会再出现,极大提高了效率。但是它只支持 utf8, 如果你的数据库是zhs16gbk字符集,则只能使用笨笨的那个Chinese vgram lexer。
–以上的说法是针对于Oracle8i或者是更低级版本的,在Oracle 9.2中采用 Chinese_lexer 分析器测试是没有这个问题的。
如果不做任何设置,Oracle 缺省使用basic_lexer这个分析器。要指定使用哪一个lexer, 可以这样操作:
第一,在ctxsys用户下建立一个preference:
ctx_ddl.create_preference(‘cnlex’,’CHINESE_LEXER’); |
第二,在建立intermedia索引时,指明所用的lexer:
create index idx_person_desc on personinfo(persondesc)indextype is ctxsys.context parameters ( ‘DATASTORE CTXSYS.DIRECT_DATASTORE FILTER CTXSYS.NULL_FILTER LEXER cnlex WORDLIST mywordlist’) |
这样建立的全文检索索引,就会使用CHINESE_LEXER作为分析器。
使用job定时同步和优化
在intermedia索引建好后,如果表中的数据发生变化,比如增加或修改了记录,怎么办?由于对表所发生的任何dml语句,都不会自动修改索引,因此,必须定时同步(sync)和优化(optimize)索引,以正确反映数据的变化。在索引建好后,我们可以在该用户下查到Oracle自动产生了以下几个表:(假设索引名为myindex):
DR$myindex$I,DR$myindex$K,DR$myindex$R,DR$myindex$N |
其中以I表最重要,可以查询一下该表,看看有什么内容:
select token_text, token_count from DR$I_RSK1$I where rownum<=20; |
可以看到,该表中保存的其实就是Oracle 分析你的文档后,生成的term记录在这里,包括term出现的位置、次数、hash值等。当文档的内容改变后,可以想见这个I表的内容也应该相应改变,才能保证Oracle在做全文检索时正确检索到内容(因为所谓全文检索,其实核心就是查询这个表)。那么如何维护该表的内容呢?总不能每次数据改变都重新建立索引吧!这就用到sync 和 optimize了。
同步(sync):将新的term 保存到I表。
优化(optimize):清除I表的垃圾,主要是将已经被删除的term从I表删除。
检查全文索引是否创建成功
1、检查DR$myindex$I是否存在,其中的 myindex 代表建立的索引名称;
2、检查全文索引是否创建成功,最好采用 Contains来检查,具体的语法为
Contains(ColumnName,SearcherKey) > 0// ColumnName为所需要检查的列名,也即创建了全文索引的列名 // SearcherKey 为你需要查找的内容,为字符型 |
列如,按上面创建的全文索引,可以使用如下的语句:
Select * From PERSONINFO Where Containts(PERSONDESC, ‘abcd’,1) > 0 Select * From PERSONINFO Where Containts(PERSONDESC, ‘abcd’,1) > 0 |
如果你创建的全文索引不成功,则返回失败,其内容为:
ORA-20000: Oracle Text error: DRG-10599: 列没有编制索引
当然,如果你创建成功,则会正确返回数据。还有一个检查全文索引是否创建成功的方法是感觉创建全文索引后的查询速度。
测试数据
下面是对一个表进行操作时,在同一台机器中获得的测试数据。
PersonInfo表中共有 182263 条记录,其中persondesc不为null的记录数为180187 条记录,
其中,persondesc 包括 “大学”两个汉字的记录数为 21579 条记录
persondesc 包括 “1999”两个汉字的记录数为 10889条记录
测试一、直接用like 来查询中文“大学”
SQL: Select count(*) From personinfo Where persondesc like ‘%大学%’ |
时间开销:耗时 40秒 688 毫秒
测试二、直接用like 来查询英文“1999”
SQL: Select count(*) From personinfo Where persondesc like ‘%1999%’ |
时间开销:耗时 47秒 218毫秒
测试三、未创建全文索引时,直接用dbms_lob.instr 来查询中文“大学”
SQL: Select count(*) From personinfo Where dbms_lob.instr(persondesc,’大学’,1,1)>0 |
时间开销:耗时 47秒 031毫秒
测试四、未创建全文索引时,直接用dbms_lob.instr 来查询英文“1999”
SQL: Select count(*) From personinfo Where dbms_lob.instr(persondesc,’1999′,1,1)>0 |
时间开销:耗时 44秒 360毫秒
测试五、未创建全文索引时,直接用Contains 来查询中文“大学”
SQL: Select count(*) From personinfo Where Contains(persondesc,’大学’,1)>0″; |
执行失败: ORA-20000: Oracle Text error: DRG-10599: 列没有编制索引
测试六、未创建全文索引时,直接用Contains 来查询英文“1999”
SQL: Select count(*) From personinfo Where Contains(persondesc,’1999′,1)>0″; |
执行失败: ORA-20000: Oracle Text error: DRG-10599: 列没有编制索引
测试七、采用CHINESE_LEXER词法分析器创建全文索引后,直接用Contains 来查询英文“1999”
SQL: Select count(*) From personinfo Where Contains(persondesc,’1999′,1)>0″; |
时间开销:第一次查询耗时 469毫秒,后面的多次查询耗时 210毫秒左右
***查询出来的记录数比在未建立索引时用like、dbms_lob.instr方式查询出来的记录数要少一些
测试八、采用CHINESE_LEXER词法分析器创建全文索引后,直接用Contains 来查询中文“大学”
SQL: Select count(*) From personinfo Where Contains(persondesc,’大学’,1)>0″; |
时间开销:第一次查询耗时 9秒359毫秒,后面的多次查询耗时 210毫秒左右
***查询出来的记录数比在未建立索引时用like、dbms_lob.instr方式查询出来的记录数要少一些
测试九、采用CHINESE_LEXER词法分析器创建全文索引后,用dbms_lob.instr 来查询中文“大学”
SQL: Select count(*) From personinfo Where dbms_lob.instr(persondesc,’大学’,1,1)>0 |
时间开销:耗时 54秒 953毫秒
测试十、采用CHINESE_LEXER词法分析器创建全文索引后,直接用dbms_lob.instr 来查询英文“1999”
SQL: Select count(*) From personinfo Where dbms_lob.instr(persondesc,’1999′,1,1)>0 |
时间开销:耗时 52秒 652毫秒
总体感觉Oracle的中文全文索引不是很好。后续版本或许会有所改进吧。
我们一直都在努力坚持原创.......请不要一声不吭,就悄悄拿走。
我原创,你原创,我们的内容世界才会更加精彩!
【所有原创内容版权均属TechTarget,欢迎大家转发分享。但未经授权,严禁任何媒体(平面媒体、网络媒体、自媒体等)以及微信公众号复制、转载、摘编或以其他方式进行使用。】
微信公众号
TechTarget
官方微博
TechTarget中国
作者
相关推荐
-
甲骨文自治数据库亮相 带来云计算新希望
早前甲骨文还不在云计算公司之列,而现在该公司正在迅速弥补其失去的时间。甲骨文的云计算核心是甲骨文自治数据库(O […]
-
2017年12月数据库流行度排行榜 定格岁末排名瞬间
数据库知识网站DB-engines最近更新的2017年12月份数据库流行度排名情况是否能提供更多的看点呢?TechTarget数据库网站将与您分享12月份的榜单排名情况,让我们拭目以待。
-
2017年11月数据库流行度排行榜 半数以上数据库积分减少
数据库知识网站DB-engines更新了2016年11月份的数据库流行度排行榜。TechTarget数据库网站将与您一同关注11月份的榜单排名情况。
-
控制合约 不再畏惧Oracle
许多公司都与Oracle有无限制授权协议,他们害怕离开这个协议,所以就证明他们在使用Oracle的软件,即使因为需求单独购买部分授权许可也可能总体是省钱的。