网站建设必须要具备哪些知识,网络设计报告提纲范文,浙江建设继续教育网站首页,如何做自己产品网站一、基本概念
1.Segments In Lucene
众所周知#xff0c;ElasticSearch存储的基本单元Shard#xff0c;ES中一个Index可能分为多个Shard#xff0c;事实上每个Shard都是一个Lucence的Index#xff0c;并且每个Lucene Index由多个Segment组成#xff0c;每个Segment事实上…一、基本概念
1.Segments In Lucene
众所周知ElasticSearch存储的基本单元ShardES中一个Index可能分为多个Shard事实上每个Shard都是一个Lucence的Index并且每个Lucene Index由多个Segment组成每个Segment事实上是一些倒排索引的集合每次创建一个新的Document都会归属于一个新的Segment而不是去修改原来的Segment。每次的文档删除操作只是标记Segment中该文档为删除状态并不会立马物理删除所以说ES的Index是一个抽象的概念如下图所示
2.Commits In Lucene
Commit 操作意味着将 Segment 合并并写入磁盘。保证内存数据尽量不丢失。但刷盘是很重的 IO 操作 所以为了机器性能和近实时搜索 并不会刷盘那么及时。
3.Translog
新文档被索引意味着文档会被首先写入内存 buffer 和 translog 文件。每个 shard 都对应一个 translog文件。
4.Refresh In ElasticSearch
在 Elasticsearch 中 _refresh 操作默认每秒执行一次 意味着将内存 buffer 的数据写入到一个新的 Segment 中这个时候索引变成了可被检索的。写入新Segment后 会清空内存buffer。
5.Flush In ElasticSearch
Flush操作意味着将内存Buffer的数据全部写入新的Segment中并将内存中所有的Segment全部刷盘并且清空Translog日志的过程。
二、近实时搜索
提交Commiting一个新的段到磁盘需要一个fsync来确保被物理性地写入磁盘这样在断电的时候就不会丢失数据。但是fsync操作代价很多如果每次索引一个稳定都去执行一次的话就会造成很大的性能问题。 在ElasticSearch和磁盘之间是文件系统缓存。像之前描述的一样在内存索引缓冲区中的文档会被写入到一个新的段中。但是这里新段会被先写入到文件系统缓存–这一步代价比较低稍后会被刷新到磁盘–这一步代价比较高。不过只要文件已经在系统缓存中就可以像其他文件一样被打开和读取了。如下图表示在内存缓存区中包含了新文档的索引
Lucene 允许新段被写入和打开–使其包含的文档在未进行一次完整提交时便对搜索可见。 这种方式比进行一次提交代价要小得多并且在不影响性能的前提下可以被频繁地执行。
上图表示缓存区的内容已经被写入一个可被搜索的段中但是还没有提交。
2.1 原理 上图表示的是ES的写操作流程当一个写请求发送到ES后ES将数据写入Memory Buffer中并添加事务日志Translog。如果每次一条数据写入内存后立即写到硬盘文件上由于写入的数据肯定是离散的因此写入硬盘的操作也就是随机写入了。磁盘随机写入的效率相当低会严重降低ES的性能。因此ES在设计时在Memory Buffer和磁盘间加入了Linux的高速缓存File System Cache来提高ES的写效率。 当写请求发送到ES后ES将数据暂时写入Memory Buffer中此时写入的数据还不能被查询到。默认设置下ES每1秒将Memory Buffer中的数据refresh到Linux的File System Cache并清空Memory Buffer此时写入的数据就可以被查询到了。
2.2 Refresh API
在ElasticSearch中写入和打开一个新段的轻量的过程叫refresh。默认情况下每个分片会每秒自动刷新一次。这就是为什么我们说ElasticSearch是近实时搜索文档的变化并不是立即对搜索可见但是会在一秒内变为可见。 这些默认的机制会造成在索引了一个文档后尝试搜索它但是没有搜索到这个问题就可以通过refresh api 执行一次手动刷新
POST /_refresh // 刷新所有索引
POST /my_blogs/_refresh // 只刷新blogs索引
PUT /my_blogs/_doc/1?refresh // 只刷新文档并不是所有的情况都需要每秒刷新。在日志系统中ElasticSearch被用来索引大量的日志文件此时更应该优化索引速度而不是近实时搜索可以通过设置refresh_interval降低每个索引的刷新频率。
PUT /my_logs
{settings: { refresh_interval: 30s }
}refresh_interval 可以在既存索引上进行动态更新。 在生产环境中当你正在建立一个大的新索引时可以先关闭自动刷新待开始使用该索引时再把它们调回来
PUT /my_logs/_settings
{ refresh_interval: -1 }
PUT /my_logs/_settings
{ refresh_interval: 1s }三、持久化变更
3.1 原理
如果没有用fsync把数据从文件系统缓存刷(flush)到硬盘我们不能保证数据在断电甚至是程序正常退出之后依然存在。为了保证ElasticSearch的可靠性需要确保数据变化被持久到磁盘。 在动态更新索引时我们说一次完整的提交会将段刷到磁盘并写入一个包含所有段列表的提交点。ElasticSearch在重启或重新打开一个索引的过程中使用这个提交点来判断哪些段隶属于当前分片。 即使通过每秒刷新refresh实现了近实时的搜索我们仍然需要经常进行完整提交来确保能从失败中恢复。但在两次提交之间发生变化的文档怎么办 当然是不能丢失掉这些数据。 ElasticSearch增加了一个TransLog或者叫事务日志在每一次对ElasticSearch进行操作时均进行了日志记录。通过TransLog这个流程看起来是下面这样 1、一个文档被索引之后就会添加到内存缓存区并且追加到了TransLog
2、刷新refresh使分片处于Searchable状态分片每秒被刷新一次
●这些在内存缓冲区的文档被写入一个新的段中且没有进行fsync操作 ●这个段被打开使其可被搜索 ●内存缓存区被清空 3、这个进程继续工作更多的文档被添加到内存缓冲区和追加到事务日志
4、每个一段时间–例如translog变得越来越大–索引被刷新(flush)一个新的translog被创建并且一个全量提交被执行。 ●所有在内存缓冲区的文档都被写入一个新的段 ●缓冲区被清空 ●一个提交点被写入硬盘 ●文件系统缓存通过fsync被刷新flush ●老的translog被删除 translog提供所有还没有被刷到磁盘的操作的一个持久化记录。当ElasticSearch启动的时候它会从磁盘中使用最后一个提交点去恢复已知的段并且会重放translog中所有在最后一次提交后发生的变更操作。 translog也被用来提供实时的CRUD。当试着通过ID查询、更新、删除一个文档会在尝试从相应的段中检索之前首先检查translog任何最近的变更这意味着它总是能够实时地获取到文档的最新版本。
3.2 flush API 这个执行一个提交并且截断translog的行为在ElasticSearch被称作一次flush。分片每30分钟被自动刷新flush或者再translog太大的时候也会被刷新。 flush API可以被用来执行一个手动的刷新
POST /blogs/_flush
POST /_flush?wait_for_ongoin●刷新blogs索引 ●刷新所有的索引并且等待所有刷新在返回前完成
3.3 Translog有多安全
Translog的目的是保证操作不会丢失。这引出了一个问题Translog有多安全 在文件被fsync到磁盘之前被写入的文件在重启之后就会丢失。默认translog是每5秒被fsync刷新到磁盘或者再每次写请求完成之后执行(e.g. index, delete, update, bulk)。这个过程在主分片和复制分片都会发生。这就意味着在整个请求被fsync到主分片和复制分片的translog之前客户端不会得到一个200 OK的响应。 在每次写请求后都执行一个fsync会带来一些性能损失尽管实践表明这种损失相对较小特别是 bulk 导入它在一次请求中平摊了大量文档的开销。但是对于一些大容量的偶尔丢失几秒数据问题也并不严重的集群使用异步的fsync还是比较有益的。
