Elasticsearch集群入门2

来源:互联网 时间:1970-01-01

本篇主要记录一些看Elasticsearch Server second edition第一章的一些对于Lucene和Elasticsearch基本知识的理解。


索引的基础是倒排索引,倒排索引是面向单词的而不是面向文档的,每一个词相当于每一条记录的主键,记录中包括词出现的次数,出现过的文档的标识符集合等信息。


每个索引建立之后,可以在磁盘上看到有多个段文件,每个段文件在建立索引时,一旦写入磁盘之后就不能再更新。因此,被删除文档的信息实际上存储在一个单独的文件中,被删除的段本身却并没有更新。


当强制段合并或者lucene自动进行段合并时,多个小段会被lucene合并成更大的段,一些信息需要清除,主要是不再需要的信息,例如被删除的文档的记录信息。


检索大段比检索存有相同数据的多个小段速度更快,在一般情况下,搜索只需将查询词与那些被编入索引的词相匹配,通过多个小段寻找和合并结果显然比直接让一个大段提供结果慢得多。


用过Lucene的都知道,在实例化IndexWriter类对象时,需要使用IndexWriterConfig类对象,而实例化IndexWriterConfig类对象时,需要传入Analyzer或者包含有Analyzer的Wrapper什么的,我一直不明白分析器有什么作用。分析器由一个分词器(tokenizer)和一些标记过滤器(token filter)组成,也可以有一些字符映射器(character mapper)。

分词器先把文本分割成多个token,其实就是词本身加上一些其他信息,比如与该该词在原始文本中的位置和长度,处理结果就是一个token stream,就是一个个的token。

filter无非就是处理token的,比如小写过滤器(所有token变小写),同义词过滤器(把token换成另一个同义的token),多语言词干提取过滤器(其实类似于词干算法或者词形还原,就是把标记提取词根或者词形还原)。

至于字符映射器,在分词器之前工作,对未经分析的文本起作用,比如可以从文本的整体部分去除HTML标签。


使用lucene的时候,创建文档,可以向文档中添加field,老版本的lucene可以添加ANALYZED或者其他分析选项,其实作用就是词在搜索的时候是被分词状态还是原本状态。比如查询LightRed,如果选择分析,会去查light和red,然后结果综合;如果选择不分析,那就直接查LightRed。前提是建索引和搜索的时候使用的分词器的种类顺序什么的一系列东西最好一样,否则容易出问题。


在Elasticsearch中,一个索引里面可以有很多不同类型的文档,然而让我感到奇怪的是,在同一个索引中,即使不同类型的文档,如果其中有同名的属性(相同字段),则该字段的类型必须相同,也就是所有包含某一个相同字段的文档,他们的这个字段的类型都得一样,当然是在同一索引中。


映射的话是在建立索引的时候需要配置的,其实就跟lucene里面创建field差不多,就是自定义每个字段的属性,比如字段类型,是不是存储等等,当然不止这么些,还有很多种类的配置。


在阅读Elasticsearch的索引建立和搜索的基本机制的时候,说实话第一遍和第二遍都是快速过了,本来也确实没看太明白,今天看第三遍,感觉有点明白了。

比如你要新建一个索引,把一个新的文档发送给集群,指定一个目标索引,实际发送给集群里的任意一个节点。这个节点知道目标索引有多少分片,并且能确定哪个分片应该用来存储你的文档。然后Elasticsearch使用文档的唯一标识符来计算文档应该被放到哪个shard中,然后接受你请求的节点会把你的文档住阿奴发到持有相关分片的目标节点中。

关于搜索,有发散阶段和收集阶段,这个不注意看就可能理解错。比如你发送查询到一个节点,如果你在查询请求的url里加上了文档标识符,那么该节点可以确定持有文档的节点和分片,然后转发查询;否则,收到查询请求的节点会把查询转发到所有节点,然后所有节点返回文档标识符和得分,这是发散阶段;收到客户端请求的节点收到所有节点返回的信息之后,他充当了一个聚合节点,收集所有结果然后对结果排序,再发送第二个请求来获取结果列表所需的文档(这次不用发给所有节点了,只发给有列表里的文档标识符的节点就行),然后等待返回这些文档的详细信息,成为收集阶段,也就是说在集群内部收发了两次请求,然后才由这个节点返回结果给客户端。



相关阅读:
Top