搜查引擎的原理是什么 (搜查引擎的原则是什么)

本文目录导航：

• 搜查引擎的原理是什么？
• 搜查引擎Lucene（4）：索引的创立环节
• 搜查引擎是如何建设索引的？

搜查引擎的原理是什么？

搜查引擎的原理可以分为：数据搜集、建设索引数据库、索引数据库中搜查和排序。

1、数据搜集：搜查引擎的智能消息搜集配置分为两种类型，一种是活期搜查，即每隔一段时期，搜查引擎就会被动发送一个“蜘蛛”程序来搜查特定IP地址范畴内的互联网站点，一旦发现一个新网站，它将智能提取该网站的消息和网址，并将其减少到自己的数据库中，另一种是提交网站搜查，即网站一切者主意向搜查引擎提交网站地址。

2、建设索引数据库：搜查引擎对搜集的消息资源启动索引，编辑摘要以构成规范页面索引，并经过数据库治理系统建设相应的索引数据库，数据库中的每条记载基本上对应于一个网页，包括关键字、网页摘要、URL地址和其余消息。

3、索引数据库中搜查和排序：依据用户提出的查问要求，经常使用查问软件将其转换为计算机口头的命令，并在索引数据库中搜查合乎条件的web记载，并依据关系度对搜查结果启动排序，关系度越高，排名越高，运转后，查问结果将前往给用户。

搜查引擎Lucene（4）：索引的创立环节

创立索引的环节如下：

索引结构如下：

IndexWriter结构：

IndexWriter经过指定寄存的目录（Directory）以及文档剖析器（Analyzer）来构建，direcotry代表索引存储在哪里；analyzer示意如何来剖析文档的内容；similarity用来规格化文档，给文档算分；IndexWriter类里还有一些SegmentInfos对象用于存储索引片段消息，以及出现缺点回滚等。

减少文档经常使用addDocument()方法，删除文档经常使用deleteDocuments(Term)或许deleteDocuments(Query)方法，而且一篇文档可以经常使用updateDocument()方法来降级（仅仅是先口头delete在口头add操作而已）。

当成功了减少、删除、降级文档，应该须要调用close方法。

这些修正会缓存在内存中（buffered in memory），并且活期地（periodically）刷新到（flush）Directory中（在上述方法的调用时期）。

一次性flush操作会在如下时刻触发（triggered）：当从上一次性flush操作后有足够多缓存的delete操作（参见setMaxBufferedDeleteTerms(int)），或许足够多已减少的文档（参见setMaxBufferedDocs(int)），无论哪个更快些（whichever is sooner）。

对被减少的文档来说，一次性flush会在如下任何一种状况下触发，文档的RAM缓存经常使用率（setRAMBufferSizeMB）或许已减少的文档数目，缺省的RAM最高经常使用率是16M，为获取索引的最高效率，你须要经常使用更大的RAM缓存大小。

须要留意的是，flush解决仅仅是将IndexWriter中外部缓存的形态（internal buffered state）移动进索引里去，然而这些扭转不会让IndexReader见到，直到commit()和close()中的任何一个方法被调用时。

一次性flush或许触发一个或更多的片断兼并（segmentmerges），这时会启动一个后盾的线程来解决，所以不会终止addDocument的调用，请参考MergeScheduler。

一个IndexReader或许IndexSearcher只会看到索引在它关上的过后的形态。

任何在索引被关上之后提交到索引中的commit消息，在它被从新关上之前都不会晤到。

DocumentsWriter结构：

DocumentsWriter 是由IndexWriter 调用来担任解决多个文档的类，它经过与Directory 类及Analyzer 类、Scorer 类等将文档内容提取出来，并合成成一组term列表再生成一个繁多的segment 所须要的数据文件，如term频率、term 位置、term 向量等索引文件，以便SegmentMerger 将它兼并到一致的segment 中去。

该类可接纳多个减少的文档，并且间接写成一个独自的segment 文件。

这比为每一个文档创立一个segment（经常使用DocumentWriter）以及对那些segments 口头协作解决更有效率。

每一个减少的文档都被传递给DocConsumer类，它解决该文档并且与索引链表中（indexing chain）其它的consumers相互出现作用（interacts with）。

确定的consumers，就像StoredFieldWriter和TermVectorsTermsWriter，提取一个文档的摘要（digest），并且马上把字节写入“文档存储”文件（比如它们不为每一个文档消耗（consume）内存RAM，除了当它们正在解决文档的时刻）。

其它的consumers，比如FreqProxTermsWriter和NormsWriter，会缓存字节在内存中，只要当一个新的segment制作出的时刻才会flush到磁盘中。

一旦经常使用完咱们调配的RAM缓存，或许已减少的文档数目足够多的时刻（这时刻是依据减少的文档数目而不是RAM的经常使用率来确定能否flush），咱们将创立一个实在的segment，并将它写入Directory中去。

索引创立的调用环节：

一个Directory对象是一系列一致的文件列表（a flat list of files）。

文件可以在它们被创立的时刻一次性写入，一旦文件被创立，它再次关上后只能用于读取（read）或许删除（delete）操作。

并且同时在读取和写入的时刻准许随机访问。

FSDirectory类间接成功Directory形象类为一个蕴含文件的目录。

目录锁的成功经常使用缺省的SimpleFSLockFactory，然而可以经过两种模式修正，即给getLockFactory()传入一个LockFactory实例，或许经过调用setLockFactory()方法明白制订LockFactory类。

目录将被缓存（cache）起来，对一个指定的合乎规则的门路（canonical path）来说，雷同的FSDirectory实例理论经过getDirectory()方法前往。

这使得同步机制（synchronization）能对目录起作用。

RAMDirectory类是一个驻留内存的（memory-resident）Directory形象类的成功。

目录锁的成功经常使用缺省的SingleInstanceLockFactory，然而可以经过setLockFactory()方法修正。

IndexInput类是一个为了从一个目录（Directory）中读取文件的形象基类，是一个随机访问（random-access）的输入流（input stream），用于一切Lucene读取Index的操作。

BufferedIndexInput是一个成功了带缓冲的IndexInput的基础成功。

IndexOutput类是一个为了写入文件到一个目录（Directory）中的形象基类，是一个随机访问（random-access）的输入流（output stream），用于一切Lucene写入Index的操作。

BufferedIndexOutput是一个成功了带缓冲的IndexOutput的基础成功。

RAMOuputStream是一个内存驻留（memory-resident）的IndexOutput的成功类。

域索引选项经过倒排索引来控制文天性否可被搜查。

当lucene建设起倒排索引后，自动状况下它会保留一切必要的消息以实施Vector Space Model。

该Model须要计算文档中出现的Term数，以及它们出现的文职（这是必要的，比如经过词组搜查时用到）。

但有时刻这些域只是在布尔搜查时用到，他们并不为关系评分做奉献，一个经常出现的例子是，域只是被用作过滤，如权限过滤和日期过滤。

在这种状况下，可以经过调用(true)方法让lucene跳过对改组项的出现频率和出现位置的索引。

该方法可以节俭一些索引在磁盘上的贮存空间，还可以减速搜查和过滤环节，但会轻轻阻止须要位置消息的搜查，如阻止PhraseQuery和SpanQuery类的运转。

域存储选项是用来确定能否须要存储域的实在值，以便后续搜查时能回复这个值。

lucene支持想一个域中写入多个不同的值。

这种解决模式是齐全可以接受并激励经常使用的，由于这是逻辑上具备多个域值的域的人造示意模式。

在lucene外部，只需文档中出现同名的多域值，倒排索引和项向量都会在逻辑上将这些语汇单元附加出来，详细顺序由减少该域的顺序选择。

文档和域的加权操作可以在索引时期成功。

而搜查时期的加权操作会愈加灵活化，由于每次搜查都可以依据不同的加权因子独立选用加权或不加权，但这个战略也或许多消耗一些CPU效率。

搜查时期的灵活加权可以更灵敏控制。

自动状况下，一切文档的加权因子都是1.0，经过扭转文档的加权因子，就可以影响文档在索引中的关键水平。调整加权操作的API为：setBoost(float)；

同文档加权一样，可以对启动加权操作。

文档加权时，lucene外部会驳回同一加权因子来对该文档中的域启动加权。

域加权API(fliat)。

Analyzer类构建用于剖析文本的TokenStream对象，因此（thus）它示意（represent）用于从文本中合成（extract）出组成索引的terms的一个规则器（policy）。

典型的（typical）成功首先创立一个Tokenizer，它将那些从Reader对象中读取字符流（stream of characters）打碎为（break into）原始的Tokens（raw Tokens）。

而后一个或更多的TokenFilters可以运行在这个Tokenizer的输入上。

正告：你必定在你的子类（subclass）中覆写（override）定义在这个类中的其中一个方法，否则的话Analyzer将会进入一个有限循环（infinite loop）中。

StandardAnalyzer：

StandardAnalyzer类是经常使用一个English的stop words列表来启动tokenize合成出文本中word，经常使用StandardTokenizer类合成词，再加上StandardFilter以及LowerCaseFilter以及StopFilter这些过滤器启动解决的这样一个Analyzer类的成功。

搜查引擎是如何建设索引的？

搜查引擎建设索引的环节也叫作建库，他是一个相对复杂的环节。深刻的来讲，关键有这些阶段：

1、蜘蛛抓取、剖析

2、数据库存储

3、权重计算并排序

比如，有100个网页，搜查引擎会依据必定战略派程序去抓取，剖析；而后分门别类地给网页的内容存储到搜查引擎的数据库里，存储的环节中会始终地降级数据并计算每个页面的权重状况。

搜查时刻依据不同关键词，启动网页排序，展现给用户。