Elasticsearch Index模块

1. Index Setting（索引设置）

每一个索引均可以设置索引级别。可选值有：

• static ：只能在索引建立的时候，或者在一个关闭的索引上设置
• dynamic：能够动态设置

1.1. Static index settings（静态索引设置）

• index.number_of_shards ：一个索引应该有的主分片（primary shards）数。默认是5。并且，只能在索引建立的时候设置。（注意，每一个索引的主分片数不能超过1024。固然，这个设置也是能够改的，经过在集群的每一个节点机器上设置系统属性来更改，例如：export ES_JAVA_OPTS="-Des.index.max_number_of_shards=128"）
• index.shard.check_on_startup ：分片在打开前是否要检查是否有坏损。默认是false。
• index.routing_partition_size ：自定义的路由值能够路由到的分片数。默认是1。

1.2. Dynamic index settings（动态索引设置）

若是想学习Java工程化、高性能及分布式、深刻浅出。微服务、Spring，MyBatis，Netty源码分析的朋友能够加个人Java高级交流：854630135，群里有阿里大牛直播讲解技术，以及Java大型互联网技术的视频免费分享给你们。

• index.number_of_replicas ：每一个主分片所拥有的副本数，默认是1。
• index.auto_expand_replicas ：根据集群中数据节点的数量自动扩展副本的数量。默认false。
• index.refresh_interval ：多久执行一次刷新操做，使得最近的索引更改对搜索可见。默认是1秒。设置为-1表示禁止刷新。
• index.max_result_window ：在这个索引下检索的 from + size 的最大值。默认是10000。（PS：也就是说最多能够一次返回10000条）

2. Analysis

索引分析模块是一个可配置的分析器注册表，可用于将字符串字段转换为如下各个场景中的Term：

• 添加到反向索引（ inverted index）以使文档可搜索
• 用于高级查询，如match查询

（PS：简而言之，

第1、分析器用于将一个字符串转成一个一个的Term；

第2、这些Term能够被添加到反向索引中，以使得该文档能够经过这个Term被检索到；

第3、这些Term还能够高级查询，好比match查询）

3. Merge（合并）

在Elasticsearch中，一个分片就是一个Lucene索引，并且一个Lucene索引被分解成多个段（segments）。段是索引中存储索引数据的内部存储元素，而且是不可变的。较小的段按期合并到较大的段中，以控制索引大小。

合并调度程序（ConcurrentMergeScheduler）在须要时控制合并操做的执行。合并在单独的线程中运行，当达到最大线程数时，将等待进一步的合并，直到合并线程可用为止。

支持下列参数：

• index.merge.scheduler.max_thread_count ：在单个碎片上，一次合并的最大线程数。默认是 Math.max(1, Math.min(4, Runtime.getRuntime().availableProcessors() / 2))

若是想学习Java工程化、高性能及分布式、深刻浅出。微服务、Spring，MyBatis，Netty源码分析的朋友能够加个人Java高级交流：854630135，群里有阿里大牛直播讲解技术，以及Java大型互联网技术的视频免费分享给你们。

4. Slow log（慢日志）

4.1. Search Slow Log（查询慢日志）

分片级慢查询日志，容许将慢查询记录到专用的日志文件中

能够在执行query阶段和fetch阶段设置阈值，例如：

 

上面全部的设置项都是动态设置的，并且是按索引设置的。（PS：也就是说，是针对某一个索引设置的）

默认状况下，是禁用状态（设置为-1）

级别（warn, info, debug, trace）能够控制哪些日志级别的日志将会被记录

注意，日志记录是在分片级别范围内完成的，这意味着只有在特定的分片中执行搜索请求的慢日志才会被记录。

日志文件配置默认在log4j2.properties

4.2. Index Slow Log（索引慢日志）

和前面的慢查询日志相似，索引慢日志文件名后缀为_index_indexing_slowlog.log

日志和阈值配置与慢查询相似，并且默认日志文件配置也是在log4j2.properties

下面是一个例子：

 

5. Store（存储）

5.1. 文件存储类型

不一样的文件系统有不一样的存储类型。默认状况下，Elasticsearch将根据操做环境选择最佳实现。

可选的存储类型有：

• fs ：默认实现，取决于操做系统
• simplefs ：对应Lucene SimpleFsDirectory
• niofs ：对应Lucene NIOFSDirectory
• mmapfs ：对应Lucene MMapDirectory

能够改变这种设置，经过在config/elasticsearch.yml中添加以下配置，例如：

index.store.type: niofs

上面的设置对全部的索引都生效。你也能够在索引建立的时候针对某一个特定的索引进行设置，例如：

curl -X PUT "localhost:9200/my_index" -H 'Content-Type: application/json' -d' { "settings": { "index.store.type": "niofs" } } '

5.2. 预加载数据到文件系统缓存

默认状况下，Elasticsearch彻底依赖于操做系统的文件系统缓存来缓存I/O操做。能够设置index.store.preload来告诉操做系统在打开时将热点索引文件的内容加载到内存中。这个选项接受一个逗号分隔的文件扩展列表：扩展名在列表中的全部文件将在打开时预加载。这对于提升索引的搜索性能很是有用，特别是在主机操做系统重启时，由于这会致使文件系统缓存被丢弃。可是请注意，这可能会减慢索引的打开速度，由于只有在将数据加载到物理内存以后，索引才会可用。

静态设置的话能够这样设置：

index.store.preload: ["nvd", "dvd"]

或者在索引建立的时候设置：

curl -X PUT "localhost:9200/my_index" -H 'Content-Type: application/json' -d' { "settings": { "index.store.preload": ["nvd", "dvd"] } } '

若是想学习Java工程化、高性能及分布式、深刻浅出。微服务、Spring，MyBatis，Netty源码分析的朋友能够加个人Java高级交流：854630135，群里有阿里大牛直播讲解技术，以及Java大型互联网技术的视频免费分享给你们。

默认值是一个空数组，意味着文件系统不会预加载任何数据。对于可搜索的索引，你可能想要把它们设置为["nvd", "dvd"]，这将会使得norms和doc数据被预先加载到物理内存。不推荐把全部的文件都预加载到内存，一般可能更好的选择是设置为["nvd", "dvd", "tim", "doc", "dim"]，这样的话将会预加载norms，doc values，terms dictionaries， postings lists 和 points

6. Translog（事物日志）

对Lucene的更改只有在Lucene提交的时候才会持久化到磁盘，这是一个相对昂贵的操做，所以不能再每次索引建立或者删除之后就执行。若是进程退出或者硬件故障的话，那么在两次提交之间所作的更改将会被Lucece从索引中删除。（PS：上一次提交之后到下一次提交以前这之间的更新会丢失）

若是每次更改之后当即执行Lucene提交，那么这个开销实在太大，所以每一个分片副本也都有一个事物日志，它被叫作与之关联的translog。全部的索引和删除操做都是在内部Lucene索引处理以后，确认以前，被写入到translog的。在崩溃的状况下，当分片恢复时，能够从translog中恢复最近的事务，这些事务已经被确认，可是尚未包含在上一次Lucene提交中。

Elasticsearch flush是执行Lucene提交并启动新translog的过程。flush是在后台自动执行的，以确保translog不会变得太大。（PS：由于若是translog很大，那么恢复所须要的时间越长）。固然，咱们也能够经过API手动执行刷新，尽管不多须要这样作。

6.1. Translog设置

translog中的数据只有在fsync和提交时才会被持久化到磁盘。在硬件失败的状况下，在translog提交以前的数据都会丢失。

默认状况下，若是index.translog.durability被设置为async的话，Elasticsearch每5秒钟同步并提交一次translog。或者若是被设置为request（默认）的话，每次index，delete，update，bulk请求时就同步一次translog。更准确地说，若是设置为request, Elasticsearch只会在成功地在主分片和每一个已分配的副本分片上fsync并提交translog以后，才会向客户端报告index、delete、update、bulk成功。

能够动态控制每一个索引的translog行为：

• index.translog.sync_interval ：translog多久被同步到磁盘并提交一次。默认5秒。这个值不能小于100ms
• index.translog.durability ：是否在每次index，delete，update，bulk请求以后当即同步并提交translog。接受下列参数：
• request ：（默认）fsync and commit after every request。这就意味着，若是发生崩溃，那么全部只要是已经确认的写操做都已经被提交到磁盘。
• async ：在后台每sync_interval时间进行一次fsync和commit。意味着若是发生崩溃，那么全部在上一次自动提交之后的已确认的写操做将会丢失。
• index.translog.flush_threshold_size ：当操做达到多大时执行刷新，默认512mb。也就是说，操做在translog中不断累积，当达到这个阈值时，将会触发刷新操做。
• index.translog.retention.size ：translog文件达到多大时执行执行刷新。默认512mb。
• index.translog.retention.age ：translog最长多久提交一次。默认12h。

6.2. 小结

一、只有在Lucene提交的时候，对Lucene所作的更改才会持久化到磁盘，而这一操做开销很大，于是不可能每次改变后就当即提交，而若是不是每次更改后当即提交的话，那么在本次提交之后到下一次提早之前这之间的更改就有丢失的可能。为了解决这种问题，每一个索引分片都有一个叫作“translog”的事物日志，每次Lucene处理完之后，就向translog中写日志，最后确认本次更改。也就是说，translog是在Lucene内部处理完之后，确认请求以前写的。

二、translog是为了不频繁Lucene提交所形成的大额开销，同时又要尽可能减小数据丢失而采起的一种方案

三、Elasticsearch flush的时候会提交Lucene更改，同时开启新的translog。flush是后台自动进行的。默认30分钟一次。

四、translog自己做为文件也是须要fsync（同步）到磁盘的。经过translog选项设置，咱们能够控制多久同步一次，或者当文件达到多大的时候同步，或者文件最长多久就必须同步。默认每次请求之后就当即同步。若是在同步以前发生崩溃，那么上一次同步以后的写操做也是会丢失的。

五、Lucene提交跟translog提交是两回事，Lucene提交的时候translog确定会被提交

7. Segment（段）

向索引中插入文档时，文档首先被保存在内存缓存（in-memory buffer）中，同时将操做写入到translog中，此时这条刚插入的文档还不能被搜索到。默认1秒钟refresh一次，refresh操做会将文件写到操做系统的文件系统缓存中，并造成一个segment，refresh后文档能够被检索到。

当flush的时候，全部segment被同步到磁盘，同时清空translog，而后生成一个新的translog

Lucene把每次生成的倒排索引叫作一个segment，也就是说一个segment就是一个倒排索引。（PS：能够类比Oracle中段区块的概念）

 

若是想学习Java工程化、高性能及分布式、深刻浅出。微服务、Spring，MyBatis，Netty源码分析的朋友能够加个人Java高级交流：854630135，群里有阿里大牛直播讲解技术，以及Java大型互联网技术的视频免费分享给你们。