当我们学习Elasticsearch时，经常会遇到如下的几个概念：
这个几个概念分别指的是什么？有什么用处？如何配置它们？只有我们熟练地掌握了这些概念，我们才可以正确地使用它们。
inverted index（反向索引）是Elasticsearch和任何其他支持全文搜索的系统的核心数据结构。 反向索引类似于您在任何书籍结尾处看到的索引。 它将出现在文档中的术语映射到文档。
例如，您可以从以下字符串构建反向索引：
Elasticsearch从已建立索引的三个文档中构建数据结构。 以下数据结构称为反向索引(inverted index)：
Term Frequency Document (postings)
choice 1 3
day 1 2
is 3 1,2,3
it 1 1
last 1 2
of 1 2
of 1 2
sunday 2 1,2
the 3 2,3
tomorrow 1 1
week 1 2
yours 1 3
如果您要处理时间序列数据，则不想将所有内容连续转储到单个索引中。 取而代之的是，您可以定期将数据滚动到新索引，以防止数据过大而又缓慢又昂贵。 随着索引的老化和查询频率的降低，您可能会将其转移到价格较低的硬件上，并减少分片和副本的数量。
要在索引的生命周期内自动移动索引，可以创建策略来定义随着索引的老化对索引执行的操作。 索引生命周期策略在与Beats数据发件人一起使用时特别有用，Beats数据发件人不断将运营数据（例如指标和日志）发送到Elasticsearch。 当现有索引达到指定的大小或期限时，您可以自动滚动到新索引。 这样可以确保所有索引具有相似的大小，而不是每日索引，其大小可以根beats数和发送的事件数而有所不同。
让我们通过动手操作场景跳入索引生命周期管理（Index cycle management: ILM）。 本文章将利用您可能不熟悉的ILM独有的许多新概念。 我们先用一个示例来展示。本示例的目标是建立一组索引，这些索引将封装来自时间序列数据源的数据。 我们可以想象有一个像Filebeat这样的系统，可以将文档连续索引到我们的书写索引中。 我们希望在索引达到50 GB，或文档的数量超过10000，或已在30天前创建索引后对其进行rollover，然后在90天后删除该索引。
上图显示一个Log文档在Elasticsearch中生命周期。
HanLP 中文分词器是一个开源的分词器，是专为Elasticsearch而设计的。它是基于HanLP，并提供了HanLP中大部分的分词方式。它的源码位于：
https://github.com/KennFalcon/elasticsearch-analysis-hanl
从Elasticsearch 5.2.2开始，一直有跟随Elasticsearch的不同发行版而更新。
1） 方式一：
a. 下载对应的release安装包，最新release包可从baidu盘下载（链接:https://pan.baidu.com/s/1mFPNJXgiTPzZeqEjH_zifw 密码:i0o7）
b. 执行如下命令安装，其中PATH为插件包绝对路径：
1 | ./bin/elasticsearch-plugin install file://${PATH} |
2）方式二：
a. 使用elasticsearch插件脚本安装command如下：
1 | ./bin/elasticsearch-plugin install https://github.com/KennFalcon/elasticsearch-analysis-hanlp/releases/download/v7.4.2/elasticsearch-analysis-hanlp-7.4.2.zip |
安装完后，我们可以使用如下的方式来验证我们的安装是否成功：
1 | $ ./bin/elasticsearch-plugin list |
如果我们安装时成功的话，我们可以看到上面的输出。
默认情况下，大多数字段都已编入索引，这使它们可搜索。 但是，脚本中的排序，聚合和访问字段值需要与搜索不同的访问模式。
搜索需要回答“哪个文档包含该术语？”这个问题，而排序和汇总则需要回答一个不同的问题：“此字段对该文档的值是什么？”。
大多数字段可以将索引时生产的磁盘doc_values(https://www.elastic.co/guide/en/elasticsearch/reference/current/doc-values.html)用于此数据访问模式，但是文本（text）字段不支持doc_values。
替代的方案，文本（text）字段使用查询时内存中的数据结构，称为fielddata。 当我们首次将该字段用于聚合，排序或在脚本中使用时，将按需构建此数据结构。 它是通过从磁盘读取每个段的整个反向索引，反转术语↔︎文档关系并将结果存储在JVM堆中的内存中来构建的。
Fielddata会占用大量堆空间，尤其是在加载大量的文本字段时。 一旦将字段数据加载到堆中，它在该段的生命周期内将一直保留在那里。 同样，加载字段数据是一个昂贵的过程，可能导致用户遇到延迟的情况。 这就是默认情况下禁用字段数据的原因。
在今天的文章里，我们来主要介绍一下Elasticsearch的refresh及flush两种操作的区别。如果我们从字面的意思上讲，好像都是刷新的意思。但是在Elasticsearch中，这两种操作是有非常大的区别的。本指南将有效解决两者之间的差异。 我们还将介绍Lucene功能的基础知识，例如重新打开（reopen)和提交(commit)，这有助于理解refresh和flush操作。
乍一看，Refresh和Flush操作的通用目的似乎是相同的。 两者都用于使文档在索引操作后立即可供搜索。 在Elasticsearch中添加新文档时，我们可以对索引调用_refresh或_flush操作，以使新文档可用于搜索。 要了解这些操作的工作方式，您必须熟悉Lucene中的Segments，Reopen和Commits。Apache Lucene是Elasticsearch中的基础查询引擎。
在Elasticsearch中，最基本的数据存储单位是shard。 但是，通过Lucene镜头看，情况会有所不同。 在这里，每个Elasticsearch分片都是一个Lucene索引(index)，每个Lucene索引都包含几个Lucene segments。 一个Segment包含映射到文档里的所有术语（terms)一个反向索引(inverted index)。
下图显示了段的概念及其如何应用于Elasticsearch索引及其分片：
这种分Segment的概念是，每当创建新文档时，它们就会被写入新的Segment中。 每当创建新文档时，它们都属于一个新的Segment，并且无需修改前一个Segment。 如果必须删除文档，则在其原始Segment中将其标记为已删除。 这意味着它永远不会从Segement中物理删除。
与更新相同：文档的先前版本在上一个Segment中被标记为已删除，更新后的版本保留在当前Segment中的同一文档ID下。