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"
}
}'
网友评论