何为solr搜索

2017-03-27 22:56
solr是一个独立的企业级搜索应用服务器,它对外t提供类似于web-service的api接口。用户可以通过http请求,向搜索引擎服务器提交一定格式的xml文件,生成索引。;
也可以通过http get操作提出查询的请求,得到xml/json格式的返回结果
Lucene是一个高效的,基于 Java 的全文检索库。
所以在了解Lucene之前要费一番工夫了解一下全文检索。
那么什么叫做全文检索呢?这要从我们生活中的数据说起。
我们生活中的数据总体分为两种: 结构化数据 和 非结构化数据 。
  • 结构化数据:指具有固定格式或有限长度的数据,如数据库,元数据等。
  • 非结构化数据:指不定长或无固定格式的数据,如邮件,word文档等。
  • 当然有的地方还会提到第三种,半结构化数据,如XML,HTML等,当根据需要可按结构化数据来处理,也可抽取出纯文本按非结构化数据来处理。
    非结构化数据又一种叫法叫全文数据。
     
    按照数据的分类,搜索也分为两种:
  • 对结构化数据的搜索:如对数据库的搜索,用SQL语句。再如对元数据的搜索,如利用windows搜索对文件名,类型,修改时间进行搜索等。
  • 对非结构化数据的搜索:如利用windows的搜索也可以搜索文件内容,Linux下的grep命令,再如用Google和百度可以搜索大量内容数据。
  • 对非结构化数据也即对全文数据的搜索主要有两种方法:
    一种是 顺序扫描法(Serial Scanning): 所谓顺序扫描,比如要找内容包含某一个字符串的文件,就是一个文档一个文档的看,对于每一个文档,从头看到尾,如果此文档包含此字符串,则此文档为我们要找的文件,接着看下一个文件,直到扫描完所有的文件。如利用windows的搜索也可以搜索文件内容,只是相当的慢。如果你有一个80G硬盘,如果想在上面找到一个内容包含某字符串的文件,不花他几个小时,怕是做不到。 Linux 下的grep命令也是这一种方式。大家可能觉得这种方法比较原始,但对于小数据量的文件,这种方法还是最直接,最方便的。但是对于大量的文件,这种方法就很慢了。
    有人可能会说,对非结构化数据顺序扫描很慢,对结构化数据的搜索却相对较快(由于结构化数据有一定的结构可以采取一定的搜索 算法 加快速度),那么把我们的非结构化数据想办法弄得有一定结构不就行了吗?
    这种想法很天然,却构成了全文检索的基本思路,也即将非结构化数据中的一部分信息提取出来,重新组织,使其变得有一定结构,然后对此有一定结构的数据进行搜索,从而达到搜索相对较快的目的。
    这部分从非结构化数据中提取出的然后重新组织的信息,我们称之 索引 。
    这种说法比较抽象,举几个例子就很容易明白,比如字典,字典的拼音表和部首检字表就相当于字典的索引,对每一个字的解释是非结构化的,如果字典没有音节表和部首检字表,在茫茫辞海中找一个字只能顺序扫描。然而字的某些信息可以提取出来进行结构化处理,比如读音,就比较结构化,分声母和韵母,分别只有几种可以一一列举,于是将读音拿出来按一定的顺序排列,每一项读音都指向此字的详细解释的页数。我们搜索时按结构化的拼音搜到读音,然后按其指向的页数,便可找到我们的非结构化数据——也即对字的解释。
       这种先建立索引,在对索引进行搜索的过程就叫做全文检索。
      全文检索大体分为2个过程,索引创建和搜索索引
     1.索引创建:将现实世界中的所有结构化和非结构化数据提取信息,创建索引的过程
     2.索引索引:就是得到用户查询的请求,搜索创建的索引,然后返回结果的过程
     于是全文检索就存在3个重要的问题:
     1. 索引里面究竟存了什么东西?
     2.如何创建索引?
     3.如何对索引进行搜索?
    下面我们顺序对每个个问题进行研究。
     
    二、索引里面究竟存些什么
    索引里面究竟需要存些什么呢?
    首先我们来看为什么顺序扫描的速度慢:
    其实是由于我们想要搜索的信息和非结构化数据中所存储的信息不一致造成的。
    非结构化数据中所存储的信息是每个文件包含哪些字符串,也即已知文件,欲求字符串相对容易,也即是从文件到字符串的映射。而我们想搜索的信息是哪些文件包含此字符串,也即已知字符串,欲求文件,也即从字符串到文件的映射。两者恰恰相反。于是如果索引总能够保存从字符串到文件的映射,则会大大提高搜索速度。
    由于从字符串到文件的映射是文件到字符串映射的反向过程,于是保存这种信息的索引称为 反向索引 。
    反向索引的所保存的信息一般如下:
    假设我的文档集合里面有100篇文档,为了方便表示,我们为文档编号从1到100,得到下面的结构

     
    左边保存的是一系列字符串,称为 词典 。
    每个字符串都指向包含此字符串的文档(Document)链表,此文档链表称为 倒排表 (Posting List)。
    有了索引,便使保存的信息和要搜索的信息一致,可以大大加快搜索的速度。
    比如说,我们要寻找既包含字符串“lucene”又包含字符串“solr”的文档,我们只需要以下几步:
    1. 取出包含字符串“lucene”的文档链表。
    2. 取出包含字符串“solr”的文档链表。
    3. 通过合并链表,找出既包含“lucene”又包含“solr”的文件。
     

    看到这个地方,有人可能会说,全文检索的确加快了搜索的速度,但是多了索引的过程,两者加起来不一定比顺序扫描快多少。的确,加上索引的过程,全文检索不一定比顺序扫描快,尤其是在数据量小的时候更是如此。而对一个很大量的数据创建索引也是一个很慢的过程。
    然而两者还是有区别的,顺序扫描是每次都要扫描,而创建索引的过程仅仅需要一次,以后便是一劳永逸的了,每次搜索,创建索引的过程不必经过,仅仅搜索创建好的索引就可以了。
    这也是全文搜索相对于顺序扫描的优势之一:一次索引,多次使用。
    三、如何创建索引
    全文检索的索引创建过程一般有以下几步:
    第一步:一些要索引的原文档(Document)。
    为了方便说明索引创建过程,这里特意用两个文件为例:
    文件一:Students should be allowed to Go out with their friends, but not allowed to drink beer.
    文件二:My friend Jerry went to school to see his students but found them drunk which is not allowed.
     
    第二步:将原文档传给分次组件(Tokenizer)。
    分词组件(Tokenizer)会做以下几件事情(此过程称为Tokenize):
    1. 将文档分成一个一个单独的单词。
    2. 去除标点符号。
    3. 去除停词(Stop word)。
    所谓停词(Stop word)就是一种语言中最普通的一些单词,由于没有特别的意义,因而大多数情况下不能成为搜索的关键词,因而创建索引时,这种词会被去掉而减少索引的大小。
    英语中挺词(Stop word)如:“the”,“a”,“this”等。
    对于每一种语言的分词组件(Tokenizer),都有一个停词(stop word)集合。
    经过分词(Tokenizer)后得到的结果称为词元(Token)。
    在我们的例子中,便得到以下词元(Token):
    “Students”,“allowed”,“go”,“their”,“friends”,“allowed”,“drink”,“beer”,“My”,“friend”,“Jerry”,“went”,“school”,“see”,“his”,“students”,“found”,“them”,“drunk”,“allowed”。
    第三步:将得到的词元(Token)传给语言处理组件(Linguistic Processor)。
    语言处理组件(linguistic processor)主要是对得到的词元(Token)做一些同语言相关的处理。
    对于英语,语言处理组件(Linguistic Processor)一般做以下几点:
    1. 变为小写(Lowercase)。
    2. 将单词缩减为词根形式,如“cars”到“car”等。这种操作称为:stemming。
    3. 将单词转变为词根形式,如“drove”到“drive”等。这种操作称为:lemmatization
    第四步:将得到的词(Term)传给索引组件(Indexer)。等等
    总而言之
    1. 索引过程:
    1) 有一系列被索引文件
    2) 被索引文件经过语法分析和语言处理形成一系列词(Term)。
    3) 经过索引创建形成词典和反向索引表。
    4) 通过索引存储将索引写入硬盘。
    2. 搜索过程:
    a) 用户输入查询语句。
    b) 对查询语句经过语法分析和语言分析得到一系列词(Term)。
    c) 通过语法分析得到一个查询树。
    d) 通过索引存储将索引读入到内存。
    e) 利用查询树搜索索引,从而得到每个词(Term)的文档链表,对文档链表进行交,差,并得到结果文档。
    f) 将搜索到的结果文档对查询的相关性进行排序。
    g) 返回查询结果给用户。