Elasticsearch 心得

2019-05-19 本文已影响0人墨明棋妙的兜兜

Elasticsearch 简介

Elasticsearch 是一个实时的分布式搜索和分析引擎，它和 solr 相似，都是基于 Lucene 实现，它们使用 Lucene 作为内部引擎，在使用它做全文搜索时，只需要使用统一开发好的API即可，而不需要了解其背后复杂的Lucene的运行原理，它们和 Lucene 的关系大概类似于 Spring Boot 和 Spring Framework 的关系。对 solr 不是很了解，二者在使用上没有太大差异，solr 在实现分布式搜索的时候需要引入 Zookeeper ，而 Elasticsearch 自身就可以通过配置实现分布式搜索。在一般情况下，sorl 的搜索表现更好，但是在对于数据实时性要求较高或者数据量较大的时候，Elasticsearch 的表现会更佳。

基本操作

创造一个索引

curl -X PUT \
  'http://sandog1:9200/es_learn?pretty=' \
  -H 'Content-Type: application/json' \
  -d '{
    "settings":{
        "number_of_shards":3,
        "number_of_replicas":1
    }
}'

插入一条数据


curl -X POST \
  http://sandog1:9200/es_learn/_doc \
  -H 'Content-Type: application/json' \
  -d '{
    "name": "Daenerys",
    "weapon": "dragon",
    "movement": "dragon-fire beautiful"
}'

获取一条数据

curl -X GET http://sandog1:9200/es_learn/_doc/id2

搜索数据


curl -X POST \
  http://sandog1:9200/es_learn/_search \
  -H 'Content-Type: application/json' \
  -d '{
    "query": {
        "match" : {
            "movement": "dragon-fire-beautiful"
        }
    }
}'

基本概念

Term

索引里最小的存储和查询单元，对于英文来说一般指一个单词，对于中文来说一般指一个分词后的词。

词典

Term的集合，词典的数据结构可以有很多种，每一种都有自己的优缺点。默认使用 FST ，其有更好的数据压缩率和查询效率。

倒序表

一篇文章通常由多个词组成，倒序表记录的是某个词在哪些文章中出现过

正向信息

原始的文档信息，可以用来做排序、聚合、展示

索引中最小的独立存储单元，一个索引文件由一个或者多个段组成，在Lucene 中段有不变性，也就是段一旦生成，在其上只能有读操作，不能有写操作。

查询流程

Elasticsearch 为了能快速找到某个 Term ，将所有的 Term 排个序形成词典，二分法查找term，logN的查找效率，就像通过字典查找一样。现在再看起来，似乎和传统数据库通过B-Tree的方式类似啊，为什么说比B-Tree的查询快呢？

B-Tree通过减少磁盘读取次数来提高查询性能，Elasticsearch也是采用同样的思路，直接通过内存查找Term，不读磁盘，但是如果 Term 太多，词典也会很大，放内存不现实，于是有了Term Index，就像字典里的索引页一样，A开头的有哪些term，分别在哪页，可以理解term index是一颗树

这棵树不会包含所有的 Term ，它包含的是 Term 的一些前缀。通过Term Index 可以快速地定位到词典的某个offset，然后从这个位置再往后顺序查找。

定位到 Term 后，再根据倒序表找到相关文档。

词典及倒叙索引的例子

原始文档：

ID	Name	Age	Sex
1	Kate	24	Female
2	John	24	Male
3	Bill	29	Male

Field Name 的词典及倒序表

Term	Posting List
Kate	1
John	2
Bill	3

Field Age 的词典及倒序表

Term	Posting List
24	[1,2]
29	3

Field Sex 的词典及倒序表

Term	Posting List
Female	1
Male	[2,3]

分段存储

Es 在搜索中引入了段的概念，每个段都是一个独立的可被搜索的数据集，并且段具有不变性，一旦索引的数据被写入硬盘，就不可再修改。
由于每次新增数据都会新增一个段，所以长时间的积累，会导致在索引中存在大量的段，当索引中段的数量太多时，不仅严重损耗服务器资源，还会影响检索性能。所以会定期进行段合并操作。

数据的删除是在 .del 文件中存储被删除的数据id，数据的更新则是删除和新增操作的组合。

索引写入流程

数据被写入时候，并没有直接写到硬盘中，而是被暂时被写到内存中，Lucene 默认是一秒钟，或者当内存中的数据达到一定的阶段时，再批量提交到硬盘中，通过延迟写的策略，可以减少往硬盘上写的次数，从而提高整体写入性能
达到触发条件后，会将内存中缓存的数据一次性写入硬盘，并形成提交点。提交点就是用来记录所有提交后的段信息的文件，一个段一旦拥有提交点，这说明这个段只有读的权限，失去了写的权限；相反，当段在内存中时，就只有写数据的权限，不具备读数据的权限，也就无法被检索到。
清空内存，等待新的数据写入

修改写入内存周期


curl -X PUT \
  http://sandog1:9200/es_learn/_settings \
  -H 'Content-Type: application/json' \
  -d '{
"index" : {
"refresh_interval" : "1s"
}
}'