elasticsearch学习

Elasticsearch:分布式，RESTful风格的搜索和分析。REST：资源状态转换，路径是对资源的定位，方法是对资源的操作。GET，POST，PUT，DELETE，HEAD，get和head无论对资源操作多少次都不会改变资源的状态（都是对资源的获取，不同在于head返回体没有内容）。 get，put，delete，head都是幂等性的。

安装目录：D:/software/elasticserch-7.12.0

启动：双击安装目录/elasticserch-7.12.0/bin/elasticsearch.bat

9300 ：集群间组件通信端口 9200 ：浏览器访问端口

ES是面向文档型数据库，一条数据就是一个文档。

ES 里的Index可以看做一个库，而Types相当于表，Documents则相当于表的行。

这里Types 的概念已经被逐渐弱化，Elasticsearch 6.X中，一个index下已经只能包含一个type，Elasticsearch 7.X中, Type 的概念已经被删除了。

mysql使用正排（正向）索引，检索内容，以文件id关联内容；

es使用倒排索引，以内容关联文件id；

所有的分片放在一起就是一个完整的索引数据。

数据存放的路由计算公式：hash（id）%主分片数量

数据获取：采用分片控制，用户可以访问任意一个节点获取数据，该节点称之为协调节点。

道理上采用轮询机制获取数据，但该协调节点有权利将请求转发到下一个节点。

用户保存数据流程：

当然有参数可以修改保存响应流程。当主分片保存完成之后就可以返回响应。

用户数据读取过程：

更新流程读流程的结合：

ES准实时原理

写入过程 1.0 （不完善）

不断将 Document 写入到 In-memory buffer （内存缓冲区）。
当满足一定条件后内存缓冲区中的 Documents 刷新到磁盘。
生成新的 segment 以及一个 Commit point 提交点。
这个 segment 就可以像其他 segment 一样被读取了。

画图如下：

将文件刷新到磁盘是非常耗费资源的，而且在内存缓冲区和磁盘中间存在一个高速缓存（cache），一旦文件进入到 cache 就可以像磁盘上的 segment 一样被读取了。

写入过程 2.0

不断将 Document 写入到 In-memory buffer （内存缓冲区）。
当满足一定条件后内存缓冲区中的 Documents 刷新到高速缓存（cache）。
生成新的 segment ，这个 segment 还在 cache 中。
这时候还没有 commit ，但是已经可以被读取了。

画图如下：

数据从 buffer 到 cache 的过程是定期每秒刷新一次。所以新写入的 Document 最慢 1 秒就可以在 cache 中被搜索到。

而 Document 从 buffer 到 cache 的过程叫做 ?refresh 。一般是 1 秒刷新一次，不需要进行额外修改。当然，如果有修改的需要，可以参考文末的相关资料。这也就是为什么说 Elasticsearch 是准实时的。

使文档立即可见：

Cloud Studio代码运行

复制代码

PUT /test/_doc/1?refresh
{"test": "test"}

// 或者
PUT /test/_doc/2?refresh=true
{"test": "test"}

Translog 事务日志

此处可以联想 Mysql 的 binlog， ES 中也存在一个 translog 用来失败恢复。

Document 不断写入到 In-memory buffer，此时也会追加 translog。
当 buffer 中的数据每秒 refresh 到 cache 中时，translog 并没有进入到刷新到磁盘，是持续追加的。
translog 每隔 5s 会 fsync 到磁盘。
translog 会继续累加变得越来越大，当 translog 大到一定程度或者每隔一段时间，会执行 flush。

flush 操作会分为以下几步执行：

buffer 被清空。
记录 commit point。
cache 内的 segment 被 fsync 刷新到磁盘。
translog 被删除。

值得注意的是：

translog 每 5s 刷新一次磁盘，所以故障重启，可能会丢失 5s 的数据。
translog 执行 flush 操作，默认 30 分钟一次，或者 translog 太大也会执行。

手动执行flush：

Cloud Studio代码运行

复制代码

POST /my-index-000001/_flush

删除和更新

segment 不可改变，所以 docment 并不能从之前的 segment 中移除或更新。

所以每次 commit，生成 commit point 时，会有一个 .del 文件，里面会列出被删除的 document（逻辑删除）。

而查询时，获取到的结果在返回前会经过 .del 过滤。

更新时，也会标记旧的 docment 被删除，写入到 .del 文件，同时会写入一个新的文件。此时查询会查询到两个版本的数据，但在返回前会被移除掉一个。

segment 合并

每 1s 执行一次 refresh 都会将内存中的数据创建一个 segment。

segment 数目太多会带来较大的麻烦。每一个 segment 都会消耗文件句柄、内存和cpu运行周期。更重要的是，每个搜索请求都必须轮流检查每个 segment ；所以 segment 越多，搜索也就越慢。

在 ES 后台会有一个线程进行 segment 合并：

refresh操作会创建新的 segment 并打开以供搜索使用。
合并进程选择一小部分大小相似的 segment，并且在后台将它们合并到更大的 segment 中。这并不会中断索引和搜索。
当合并结束，老的 segment 被删除说明合并完成时的活动：
1. 新的 segment 被刷新（flush）到了磁盘。写入一个包含新 segment 且排除旧的和较小的 segment的新 commit point。
2. 新的 segment 被打开用来搜索。
3. 老的 segment 被删除。

物理删除：

在 segment merge 这块，那些被逻辑删除的 document 才会被真正的物理删除。

总结

主要介绍了内部写入和删除的过程，需要了解 refresh、fsync、flush、.del、segment merge 等名词的具体含义。

完整画图如下：