信息检索(data searching)能做什么？
其实只有一件事：从一堆信息里面找出大概是你想要的一些。在之前的40 年里，这个工作一直都由数据库完成。回想一下，商业公司用数据库查询最近半月的营业额和查询购买超过10 万的大客户。所以：现代信息检索来源于数据库技术。
现代信息检索技术 和 传统数据库技术 相比有什么不同？
其實数据库难以处理维度很高的数据。我们知道，任何一个数据都可以映射到多维空间。
比如数据库里面的记录，其实就是映射到了一个多维空间，其中，每个列是一个维度。一些数据库能够定义最多1024 个维度（列），而这个值在许多应用里都很不够。数据库还难以处理空间范围查询，更不用说对数据进行挖掘了。搜索引擎是一种信息检索系统，它通过计算机来完成信息检索的过程。本文将主要讨论搜索引擎应用技术。
有关信息检索和搜索引擎的历史和一些基本介绍，大家同样可以看answers上面的介绍，地址为：http://www.answers.com/search+engine?ca t=technology 和http://www.answers.com/topic/web-search-enginecat=technology。这里提醒大家：
搜索引擎有很多很多种，常用的百度和google 只是其中的一种（网络搜索引擎）。常见的还有：企业搜索引擎、个人桌面搜索和最近很火爆的移动平台搜索引擎。其中，只有基于网络的搜索引擎才需要蜘蛛技术。蜘蛛技术不在本文的讨论范围内。
2 搜索引擎应用
2.1你真的需要搜索引擎？
请记住：单独的搜索引擎不是必须的！最近的很多数据库系统都和基本的搜索引擎进行了结合。
请注意几个例子：
数据库的全文索引、mysq l + sphinx 的搜索数据库系统、ThunderStone 公司的TEXIS（搜索+数据库系统）。
这几个做法都可以运用到顶级需求上面。笔者推荐大家在做决定之前，先了解业内的解决方案和用户需求，然后确定你是否真的需要一个单独的搜索引擎。以笔者有限的了解来看，90%以上的用户并不需要单独的搜索引擎。
给大家举几个例子：
1）个人桌面搜索：这个应用连mysq l 都用不着出马，完全可以使用嵌入式的db 系统，如sqlite；实际应用上，据说微软的桌面搜索系统是基于Lucene 的；
2）站内搜索：BBS 网站，发帖1 万/天，pv100 万/天，搜索10 万/天。使用mysq l 的全文检索即可满足需要；
3）英文文献搜索：文献检索，数据亿级，搜索100 万/天，对检索速度有要求。可以使用mysq l + sphinx 的组合；
4）Ebay：ebay 每天检索量上10 亿，商品量上10 亿，sql 语句执行过30 亿。当初Ebay 直接在TEXIS 的基础上构建了2 维分布式系统，现在他们自己设计了一个新的简单快速智能的搜索系统：Magellan（这个名字其实是一个早年搜索引擎的名字）；
5）google：上千亿数据，上百种语言，N 亿检索每天……。不要看了，本文无法给你提供技术，也无法给你提供建议。他们需要的技术远远超过1 个人的能力。
2.2 避免重新发明轮子
不要重新发明轮子。这句名言用在哪里都合适。
当你决定用一个单独的搜索引擎的时候，应该先找一找是否已经有可用的解决方案了。
2.3 已有的搜索解决方案
解决方案太多，笔者只知道一些。最基础的搜索解决方案，笔者推荐2 个：Lucene 和Sphinx。
如果你比较爱国，推荐你使用firtex（中科院的学生开发的，但缺乏维护）。他们都是纯粹的检索系统，把文档填进去，然后就能检索了。Lucene有多种语言版本，包括java（Lucene ）、.net（Lucene.net）、c++（CLuncene）等。
Sphinx 只有c++版本，但有多个语言的接口。经验上表明， c/c++版本的搜索系统在构建索引的时候，速度比java/c#的版本要快几倍；在并行性能上，c/c++的版本效果也要好很多；其他未见太大差距。国外有人也做过对比，参考PeterZa itsev, Vadim Tkachenko. high performa nce full text search for database content。
Lucene 大名鼎鼎，在其基础之上，存在各种面向具体应用的解决方案。最有名的3 个是：
1）Compass：
Compass 的几个独特特性有：和数据库结合、对MVC 模型的
支持、对Transaction 的支持和各种数据到搜索引擎的映射。它和数据库的结
合，使得它在基于数据库的项目上有广泛的应用；
2）Solr：
适合站内搜索。它包含了xml/http 和json 的接口，能够支持大并发。
它的另外一个特点是支持同类Solr 系统的数据复制；
3）Nutch：
使用的最多的网络搜索系统，它包含了蜘蛛（ Spider）、检索和
http 接口。Nutch 被设计为极易扩展的结构，抓取和索引都是分布式的。据说能
够管理上十亿的数据。
2.4 改进搜索
再好的东西也无法满足所有环境，所以我们需要改进开源搜索引擎。其实，和我们相关的较少，常见的有：中文处理、cache 等。如果你直接使用上面推荐的2 个开源项目（Compass/Solr），你就连cache 都不需要改进了，它们都内嵌了cache。
2.4.1 中文分词
因为开源的搜索系统（如Lucene）等一般都是外国人写的，他们没有专门考
虑中文的处理，故第一重要的是为我们的搜索系统加上中文处理。中文处理可以
简单的理解为中文分词，对应到Lucene 就是写一个Analyzer 类的中文处理子类。
中文分词已有了一些解决方案，常见的有：a）海量分词组件；b）中科院分
词组件。这2 个都是比较专业的咚咚。适合大企业使用。在这里，特别对海量科
技表示敬意，他们居然能够以技术立足。
对于小企业和个人来讲，无论东西多好，但没钱。这里，建议大家使用最简
单的，正确率又比较高的最大后向分词算法。只需要一个词库，然后写一段后向
最大分词的代码，搞定。如果你连代码都不愿意写，建议你直接使用****直接到
百度上面去查询，一大堆免费的。
2.4.2 cache技术
Cache 是必须的，简单的思考一下，80%的cache 命中率就能让你的系统多支持4 倍的负荷！这还仅仅只是一级cache 能力，如果你用2 级cache，你的系统就可能多支持16 倍的负荷！注意这是理论值。
传统理论上认为搜索系统至少可以划分为3 级缓冲，最低一级是磁盘索引缓冲，再高一级是中间结果缓冲，最高一级是查询结果缓冲。
考虑到在使用开源代码的时候，做多级缓冲是很麻烦的，所以，这里只谈论一下如何做查询结果缓冲。
查询结果缓冲其实能够做成一个十分复杂的结构。想想，一个查询串，被解析为一棵查询树，这棵查询树的任意子树都可以作为一个缓冲的Key。至于缓冲的Value ，可以包含文档ID 列表、文档、预查文档ID 列表、预查文档等。为了增加缓冲的命中率，你或许还会根据布尔理论来简化查询树。头大！
最简单的最有效的办法，其实是设置缓冲的Key 为查询串本身！
这点是有统计依据的，大部分用户输入的都是少于3 个词语且不包含任何布尔操作的查询串。至于Value ，也只需要缓冲前面的3 页数据，因为从第4 页开始，就几乎没有人再看了。请注意，这个统计只是一个一般性的结果，不见得适合你的应用。
2.5 实时检索
实时检索要求前一毫秒把文档写入索引，后一毫秒就能够检索出来。
什么存储设备速度快？内存。所以实时检索的实现，都把新增的数据放到内存里面。
下面是一个基本的实时检索的结构：
写入文档的时候，文档会被写入到内存索引；删除文档的时候，删除会同时提交给内存索引和磁盘索引，磁盘索引使用一个常驻内存的删除Bitmap 来标志删除；在查询的时候，把磁盘索引的结果进行删除过滤后，和内存索引的结果合并。
这里有一个需要注意的问题：排序。应该先分别从内存和磁盘获得一定数据，然后根据数据的权重进行合并，得到一个最后的结果。
2.6 监控系统（错误恢复、日志系统）
首先，用户少或者机器少或者数据不重要的项目都不需要监控系统。错误恢复或许应该独立出来，但本处放到一起谈论。最简单的错误恢复方式是：重新构建，重启服务器。但这样做有2 个问题：
1）重新构建时间很长；
2）重启服务器导致服务暂时不可用。
对于第一个问题，也有2 种简单办法：
1）完整备份；
2）分段备份。
完整备份是说保留一个和搜索系
统完全一样的备份。分段备份包括很多小分段，每个分段只包含了一部分的数据，在恢复错误的时候，只需要把从错误时间开始的数据合并到出错服务器上。而重新启动服务器的解决方案就是双服务器方案，重启一个的时候，另外一个还能工作。
监控系统一般直接监控日志。故搜索系统应该有一个日志系统，专门记录各种日志。监控系统通过分析日志，来判断系统的运营状况，并做出相应决定。比如，判断服务器当机时重新启动搜索系统、服务器僵死时杀死搜索系统、服务器繁忙时提醒等等。其系统构架一般如下：
沒有留言:
張貼留言