« 多服务器的日志合并统计——apache日志的cronolog轮循 | (回到Blog入口)|(回到首页) | Google排名优化-面向Google(Search Engine Friendly)的URL设计 »

基于Lucene/XML的站内全文检索解决方案:WebLucene


内容摘要:
为Lucene做一个通用XML接口一直是我最大的心愿:更方便的在WEB应用中嵌入全文检索功能,2004年时类似应用还很不成熟,但现在也许应该优先试试以Lucene为核心的Solr全文应用引擎;

  • 提供了XML的数据输入接口:适合将原有基于各种数据库的数据源导入到全文索引中,保证了数据源的平台无关性;
  • 通过了基于XML的搜索结果输出:方便了通过XSLT进行前台的结果显示;

MySQL \ / JSP
Oracle - DB - ==> XML ==> (Lucene Index) ==> XML - ASP
MSSQL / - PHP
MS Word / \ / XHTML
PDF / =XSLT=> - TEXT
\ XML
\_________WebLucene__________/
使用过程如下:
  1. 将数据用脚本导出成XML格式;
  2. 将XML数据源导入LUCENE索引;
  3. 从WEB界面得到XML结果输出,并通过XSLT生成HTML页面

站内全文检索的必要性

虽然大型搜索引擎的功能已经越来越强大了,很多站点都使用了Google的站内检索site:domain.com代替了自己的站内数据库“全文”检索。 但依靠GOOGLE这样的大型搜索引擎做站内检索会有以下弊端:
  • 数量有限:搜索引擎并不会深度遍历一个网站,而将网站所有的内容都索引进去,比如Google就喜欢静态网页,而且是最新更新的,而不喜欢带?的动态网页,Google甚至会定期将缺少入口的网站内容逐渐抛弃;
  • 更新慢:搜索引擎针对站点的更新频率也是有一定周期的,很多内容需要一定时间后才能进入GOOGLE的索引:目前Google Dance的周期是21天左右;
  • 内容不精确:搜索引擎需要通过页面内容提取技术将导航条,页头页尾等内容过滤掉,反而不如直接从后台数据库提取数据来得直接,这种摘要和排重机制是很难实现的;
  • 无法控制输出:也许有更多的输出需求,按时间排序,按价格,按点击量,按类目过滤等

系统的搭建

下载:
http://sourceforge.net/projects/weblucene/

XML数据源的导入:

只要数据源可以导出成3层的XML结构,就都可以用IndexRunner这个命令行工具导入:

比如从数据库导出:news_dump.xml
<?xml version="1.0" encoding="GB2312"?>
<Table>
    <Record>
        <Title>标题</Title>
        <Author>作者</Author>
        <Content>内容</Content>
        <PubTime>2003-06-29</PubTime>      
    </Record>
    <Record>
        <Title>My Title</Title>
        <Author>chedong</Author>
        <Content>abc</Content>
        <PubTime>2003-06-30</PubTime>
    </Record>
    ...
</Table>

IndexRunner -i news_dump.xml -o c:\index -t Title,Content -n Author
-i news_dump.xml:  以news_dump.xml为数据源
-o c:\index   索引库建立在c:\index目录下
索引建立Title Author Content PubTime这几个字段外,按以下规则建立索引:
-t Title,Content 一个进行分词的全文索引TokenIndex:数据是Title Content这2个字段
-n Author    一个不分词的索引:NoTokenIndex:数据源是Author这个字段。

对于RSS数据源:
<?xml version="1.0"?>
<rss version="0.92">
<channel>
  <title>Amazon: Books Arts &amp; Photography</title>
  <link>http://www.lockergnome.com/</link>
  <description>Amazon RSS Feed</description>
  <lastBuildDate>Sun, 29 Jun 2003 01:05:01 GMT</lastBuildDate>
  <docs>http://www.lockergnome.com/</docs>
  <webMaster>amazonfeed@lockergnome.com (Lockergnome RSS Generator)</webMaster>
  <item>
    <title>The Artist's Way: A Spiritual Path to Higher Creativity - $11.17</title>
    <link>http://www.amazon.com/exec/obidos/ASIN/1585421464/lockergnomedigit/?ref=nosim&amp;dev-it=D34HUVGKB34YFX</link>
    <description>http://www.lockergnome.com/    </description>
  </item>
  ...
</channel>

IndexRunner -i http://www.example.com/rss.xml -o c:\index -t title,description -n link  -l  4
-l 4 表示拿第4层节点作为字段映射,

IndexRunner还提供了-a -m这两个选项:用于增量索引和批量索引优化。
-a  增量索引,表示在原有索引的基础上扩展
-m  mergeFactor 在Lucene中mergeFactor是一个针对批量索引的优化参数,控制多少条处理完多少条记录(Document)后,写入一次索引,写入频率越高,内存使用越少,但索引速度越慢,所以在大批量数据导入时需要增大文件写入的间隔,多让索引在内存中操作。

搜索结果输出:


以下是系统设计过程中一些设计的思路:

做为工业标准的XML

记得以前有关于肯德基的炸薯条断顿的报道。从这个事件报道中我们可以看到一种更高效的管理体系:对于快餐店这样全球性的企业来说,要保证各地提供的薯条品质,成本最低的方法肯定是依靠机器而不是厨师,如果要求薯条机能够处理各种形状不一的土豆,机器的复杂程度和维护成本都会很高。所以土豆必须严格符合工业标准才能让结构比较简单的薯条机生产出符合标准的薯条,因此,薯条的加工机械会严格按照土豆协会的土豆工业标准设计。高质量的原料可以大大降低后期加工设备的成本,因此从总体成本上讲还是合算的。

对于软件应用开发者来说:应用和应用之间,企业和企业之间交换的数据好比就是土豆,白菜,按照严格的XML标准设计的接口作为企业之间后台数据交换的工业标准,虽然不如简单的CSV格式高效,但缺能大大简化下游工序的后期加工成本。

不难想象为什么处理HTML的浏览器:IE和Mozilla等浏览器软件大小都在10M以上,但一般处理XML的解析器一般都在几百K。除了没有界面外,HTML浏览器需要为太多不规范的HTML代码提供大量容错处理也是一个很重要的原因,而语法严格,规则简单的XML处理器就可以做的很简短,高效,体积越“小”就意味着适应性越广:这点在手机这样的硬件配置比较低的设备环境中显得尤其重要。

虽然XML在后台数据交换方面,有着巨大的潜力。在前台表现方面,XML并不会马上代替HTML,很多通过XSLT输出的HTML仍然需要结合CSS来进行表现。XML ==XSLT==> HTML + CSS。但是由于太多的网页都是用HTML做的,相信XML没有必要马上代替这些已有的机制。

此外在应用的国际化支持方面XML和Java简直是绝配:XML数据源用Java解析后是UNICODE,这样无论是日文,繁体中文还是德文的内容我们都可以在一个索引库中同时进行搜索。这样针对其他语言的支持只是设计各种语言界面的问题了。

      GBK          \                                       / BIG5
BIG5 - UNICODE ====> Unicode - GB2312
SJIS - (XML) (XML) - SJIS
ISO-8859-1 / \ ISO-8859-1
使用XML的另外一个额外好处在于:开发人员一般都没有仔细理解Java的字符集(其实上是JVM的缺省file.encoding属性)受系统本地化设置的影响,基于XML的输入使得数据的字符解码过程变得透明:不用再和用户解释需要如何解码,编码数据源。不过,XML的学习成本还是比较高的,假设你HTML的学习成本是1,XML则可能为10,而XSLT的学习成本则可能高达100。

传统数据库应用的全文检索加速

让数据库负责精确匹配,将模糊匹配用独立的系统实现

一个站点内容积累在万级以上,站内全文检索就会是用户定位最主要的手段,而关键词检索是用户最熟悉的方法。因此基于数据库的传统WEB应用在全文检索需求还是很大的。

但是可怕的%like%数据库操作可能会吃掉数据库服务器90%以上的CPU。Oracle MSSQL等数据库服务器中数据库内置的全文检索基本上都不太适合WEB应用。而数据库另外一个的弊端在于对于条件简单的查询返回结果集非常大:数据库并不知道如何面向用户最关心的的头100条结果进行优化。根据以前的统计:头100条结果往往已经可以满足95%以上用户需求。

需要缓存设计:根据我们的经验,在应用设计中没有必要进行内置的结果缓存设计:让前台的应用服务器内置的缓存机制或者反相代理缓存服务器进行缓存就够了。

数据同步策略

总体上讲,全文检索和数据库其实是2种根本不同的应用模式,全文检索系统其实往往也没有必要和数据库那么高的实时同步机制,如果按照:低更新,高缓存的模式进行设计:数据库数据到全文索引的同步过程一般都可以通过脚本定期将数据库的数据导出成XML,然后进入Lucene的全文索引。而针对原有数据记录的更新和删除,其实一般可以通过定期的重建索引解决。WebLucene其中索引部分是一个IndexRunner的命令行程序实现的。

结果排序策略

站内全文索引另外一个很重要的需求是可定制的排序:按时间,按价格,按点击量……Lucene全文索引缺省只提供了根据关键词在原文中的匹配度排序,而任何根据某个字段的值进行排序的都无法避免再次遍历数据,从而导致性能有数量级的下降(等于又是做%Like%检索),而在索引中,除了匹配度SCORE外,唯一能用来排序的就是索引记录的ID,所以一个比较高效率实现定制排序的方法时:在索引时,让进入Lucene全文的顺序对应着一定规则:比如时间,然后在搜索时,让搜索结果按照索引记录的ID进行排序(或倒排)。

搜索结果关键词标引的实现

搜索结果中关键词通过红色或者黑体字标记出来,为了能够更恰当的显示相关上下文的问题,标引是通过限制了一个扫描范围,然后根据一个分析器将指定的词流式的读取出来,然后

全文检索和其他应用的集成

其实核心的是一个Lucene的XML接口:SAX方式的数据导入和DOM方式的结果输出。

XML的数据源定义:
只要是能够映射成表=》记录=》字段这样层次结构的都可以。因此WebLucene索引的设计比较灵活,甚至可以直接用来索引RSS。

XML结果定义:参考了Google的XML接口的设计

如果没有SERVLET界面,提供XML输出的DOMSearcher也可以很方便集成到各种应用系统中。

参考资料:

系统设计中使用的一些模块:

其他开发人员的一些反馈和改进

银杏咨询: 站内搜索引擎提供商,为点评,饭统网提供了站内全文检索服务;

Comments

车东:你好!想向你请教一个关于关键词的标亮的问题。对被索引内容进行分词之后,词语之间有空格隔开。标亮的时候是按照空格取词的,这样显示的时候存在空格,不大美观。如果去掉空格,那标亮的效果没有了。请问你是怎么处理这个问题的?望赐教。

hi chedong 你好
我怎样才能在weblucene上实现google的query效果?
除了and 然后再or

车东你好,我想向你请教一下lucene排序算法的问题。
lucene 根据本身内置score来排序。我感觉排序的效果很不好。
请问怎么来修正这个数值。

请问,有没有用来生成对应的XML文件的工具或者比较简单的方法哪?
我另外试用了一个叫做Zilverline Search Engine的,可以对一个目录下面的文档做索引。我现在就像找到一个结合这两种用法的。然后再有一个方便生成XML文档的工具,就完美了。

我最近由于做毕业设计的问题,接触到了你的weblucene,但是现在有个问题,我的搜索结果没有加亮,我也不知道是哪方面出了问题。相应的几个类都看了,我基本上都没有动它们。不知道是哪儿出现了问题。。

车东大哥您好:
我先自我介绍一下 我是一名马上要毕业的大学学生.我的毕业设计题目就是做一个搜索引擎系统.说来惭愧我现在连怎么做一个搜索引擎都不会呢..就是都不知道怎么从开始入手了.可是我不想放弃,不想一事无成.我希望成功!
我现在也在看lucence这本书,很努力很努力的再看.我也仔细看了下您blog的内容,可是我看的真是一头雾水,我会继续不屑努力的学习做搜索引擎系统,在这我希望您能给我些宝贵的意见,能给我些从零开始的指点!我知道您一定很忙,我诚心希望您能在百忙之中给我些回复,发到您的blog也行,发到我的邮箱也行,我会静静等候.原您身体健康,新年大吉.

车冬,你的数据源变为XML是通过PHP变的吗

我也是要做一个搜索引擎系统,看来学校毕业设计差不多啊,我现在刚刚把中文分词简单解决了一下,本来想用mysql当数据库,用中文全文索引,可是到最后发现mysql对中文支持不怎么好,我也没找到相应的解决方案.

我也正准备着手做关于搜索引擎方面的一个毕业设计,哪位也做的可以一起讨论,谁可以建群,可以建好了大家加!我的QQ 315213037
邮箱QQ的已开通,可以来信地起交流!

车东:
您好!
我是搜索引擎技术的爱好者,最近做一个关于搜索的大作业时遇到了一个问题,所以需要您的指点,问题描述如下:

要求:当用户搜索时,返回用户附近资源的搜索结果!

API要求:输入:搜索词,用户经纬度

例如:当用户在"朝阳区"搜索"肯德基"时,返回的搜索结果中朝阳区的肯德基相关的店面信息最靠前;而当用户在海淀区搜素时,返回的结果信息中海淀区的肯德基相关的信息最靠前

我的问题:
1.数据目前在数据库,如何建立能够实现"附近搜索"的索引? 一个字段建立一个索引么?索引与经纬度之间怎么关联?
2.搜索时如何处理查询? 查询时先搜索地名索引?然后再在搜索结果中进行搜索么?

备注:搜索打算采用Lucene和Nutch

发表一个评论

(如果你此前从未在此 Blog 上发表过评论,则你的评论必须在 Blog 主人验证后才能显示,请你耐心等候。)

相关文章

关于

此页面包含了发表于May 06, 2003 06:28 PM的 Blog 上的单篇日记。

此 Blog 的前一篇日记是 多服务器的日志合并统计——apache日志的cronolog轮循

此 Blog 的后一篇日记是 Google排名优化-面向Google(Search Engine Friendly)的URL设计

更多信息可在 主索引 页和 归档 页看到。

Creative Commons License
此 Blog 中的日记遵循以下授权 Creative Commons(创作共用)授权.
Powered by
Movable Type 3.36