非构造化数据： 又可称为全文数据，不定长或无固定格式，不适于由数据库二维表来表现，包括所有格式的办公函档、XML、HTML、Word 文档，邮件，各种报表、图片和咅频、视频信息等。
解释：如果要更细致的区分的话，XML、HTML 可划分为半构造化数据。由于它们也具有自己特定的标签格式，以是既可以根据须要按构造化数据来处理，也可抽取出纯文本按非构造化数据来处理。
根据两种数据分类，搜索也相应的分为两种：
对付构造化数据，由于它们具有特定的构造，以是我们一样平常都是可以通过关系型数据库（MySQL，Oracle 等）的二维表（Table）的办法存储和搜索，也可以建立索引。
对付非构造化数据，也即对全文数据的搜索紧张有两种方法：
顺序扫描： 通过笔墨名称也可理解到它的大概搜索办法，即按照顺序扫描的办法查询特定的关键字。
例如给你一张报纸，让你找到该报纸中“安然”的笔墨在哪些地方涌现过。你肯定须要从头到尾把报纸阅读扫描一遍然后标记出关键字在哪些版块涌现过以及它的涌现位置。
这种办法无疑是最耗时的最低效的，如果报纸排版字体小，而且版块较多乃至有多份报纸，等你扫描完你的眼睛也差不多了。
全文搜索： 对非构造化数据顺序扫描很慢，我们是否可以进行优化？把我们的非构造化数据想办法弄得有一定构造不就行了吗？
将非构造化数据中的一部分信息提取出来，重新组织，使其变得有一定构造，然后对此有一定构造的数据进行搜索，从而达到搜索相对较快的目的。
这种办法就构成了全文检索的基本思路。这部分从非构造化数据中提取出的然后重新组织的信息，我们称之为索引。
这种办法的紧张事情量在前期索引的创建，但是对付后期搜索却是快速高效的。
先说说 Lucene
通过对生活中数据的类型作了一个简短理解之后，我们知道关系型数据库的 SQL 检索是处理不了这种非构造化数据的。
这种非构造化数据的处理须要依赖全文搜索，而目前市场上开放源代码的最好全文检索引擎工具包就属于 Apache 的 Lucene了。
但是 Lucene 只是一个工具包，它不是一个完全的全文检索引擎。Lucene 的目的是为软件开拓职员供应一个大略易用的工具包，以方便的在目标系统中实现全文检索的功能，或者因此此为根本建立起完全的全文检索引擎。
目前以 Lucene 为根本建立的开源可用全文搜索引擎紧张是 Solr 和 Elasticsearch。
Solr 和 Elasticsearch 都是比较成熟的全文搜索引擎，能完成的功能和性能也基本一样。
但是 ES 本身就具有分布式的特性和易安装利用的特点，而 Solr 的分布式须要借助第三方来实现，例如通过利用 ZooKeeper 来达到分布式折衷管理。
不管是 Solr 还是 Elasticsearch 底层都是依赖于 Lucene，而 Lucene 能实现全文搜索紧张是由于它实现了倒排索引的查询构造。
如何理解倒排索引呢？ 如果现有三份数据文档，文档的内容如下分别是：
为了创建倒排索引，我们通过分词器将每个文档的内容域拆分成单独的词（我们称它为词条或 Term），创建一个包含所有不重复词条的排序列表，然后列出每个词条涌如今哪个文档。
结果如下所示：
Term Doc_1 Doc_2 Doc_3 ------------------------------------- Java | X | | is | X | X | X the | X | X | X best | X | X | X programming | x | X | X language | X | X | X PHP | | X | Javascript | | | X -------------------------------------
这种构造由文档中所有不重复词的列表构成，对付个中每个词都有一个文档列表与之关联。
这种由属性值来确定记录的位置的构培养是倒排索引。带有倒排索引的文件我们称为倒排文件。
我们将上面的内容转换为图的形式来解释倒排索引的构造信息，如下图所示：
个中紧张有如下几个核心术语须要理解：
词条（Term）： 索引里面最小的存储和查询单元，对付英文来说是一个单词，对付中文来说一样平常指分词后的一个词。
词典（Term Dictionary）： 或字典，是词条 Term 的凑集。搜索引擎的常日索引单位是单词，单词词典是由文档凑集中涌现过的所有单词构成的字符串凑集，单词词典内每条索引项记载单词本身的一些信息以及指向“倒排列表”的指针。
倒排表（Post list）： 一个文档常日由多个词组成，倒排表记录的是某个词在哪些文档里涌现过以及涌现的位置。每条记录称为一个倒排项（Posting）。倒排表记录的不单是文档编号，还存储了词频等信息。
倒排文件（Inverted File）： 所有单词的倒排列表每每顺序地存储在磁盘的某个文件里，这个文件被称之为倒排文件，倒排文件是存储倒排索引的物理文件。
从上图我们可以理解到倒排索引紧张由两个部分组成：
词典和倒排表是 Lucene 中很主要的两种数据构造，是实现快速检索的主要基石。词典和倒排文件是分两部分存储的，词典在内存中而倒排文件存储在磁盘上。
ES 核心观点
一些根本知识的铺垫之后我们正式进入本日的主角 Elasticsearch 的先容。
ES 是利用 Java 编写的一种开源搜索引擎，它在内部利用 Lucene 做索引与搜索，通过对 Lucene 的封装，隐蔽了 Lucene 的繁芜性，取而代之的供应一套大略同等的 RESTful API。
然而，Elasticsearch 不仅仅是 Lucene，并且也不仅仅只是一个全文搜索引擎。
它可以被下面这样准确的形容：
官网对 Elasticsearch 的先容是 Elasticsearch 是一个分布式、可扩展、近实时的搜索与数据剖析引擎。
我们通过一些核心观点来看下 Elasticsearch 是如何做到分布式，可扩展和近实时搜索的。
集群（Cluster）ES 的集群搭建很大略，不须要依赖第三方折衷管理组件，自身内部就实现了集群的管理功能。
ES 集群由一个或多个 Elasticsearch 节点组成，每个节点配置相同的 cluster.name 即可加入集群，默认值为 “elasticsearch”。
确保不同的环境中利用不同的集群名称，否则终极会导致节点加入缺点的集群。
一个 Elasticsearch 做事启动实例便是一个节点（Node）。节点通过 node.name 来设置节点名称，如果不设置则在启动时给节点分配一个随机通用唯一标识符作为名称。
①创造机制那么有一个问题，ES 内部是如何通过一个相同的设置 cluster.name 就能将不同的节点连接到同一个集群的？答案是 Zen Discovery。
Zen Discovery 是 Elasticsearch 的内置默认创造模块（创造模块的职责是创造集群中的节点以及选举 Master 节点）。
它供应单播和基于文件的创造，并且可以扩展为通过插件支持云环境和其他形式的创造。
Zen Discovery 与其他模块集成，例如，节点之间的所有通信都利用 Transport 模块完成。节点利用创造机制通过 Ping 的办法查找其他节点。
Elasticsearch 默认被配置为利用单播创造，以防止节点无意中加入集群。只有在同一台机器上运行的节点才会自动组成集群。
如果集群的节点运行在不同的机器上，利用单播，你可以为 Elasticsearch 供应一些它该当去考试测验连接的节点列表。
当一个节点联系到单播列表中的成员时，它就会得到全体集群所有节点的状态，然后它会联系 Master 节点，并加入集群。
这意味着单播列表不须要包含集群中的所有节点， 它只是须要足够的节点，当一个新节点联系上个中一个并且说上话就可以了。
如果你利用 Master 候选节点作为单播列表，你只要列出三个就可以了。这个配置在 elasticsearch.yml 文件中：
discovery.zen.ping.unicast.hosts: [\"大众host1\公众, \公众host2:port\公众]
节点启动后先 Ping ，如果 discovery.zen.ping.unicast.hosts 有设置，则 Ping 设置中的 Host ，否则考试测验 ping localhost 的几个端口。
Elasticsearch 支持同一个主机启动多个节点，Ping 的 Response 会包含该节点的基本信息以及该节点认为的 Master 节点。
选举开始，先从各节点认为的 Master 中选，规则很大略，按照 ID 的字典序排序，取第一个。如果各节点都没有认为的 Master ，则从所有节点中选择，规则同上。
这里有个限定条件便是 discovery.zen.minimum_master_nodes ，如果节点数达不到最小值的限定，则循环上述过程，直到节点数足够可以开始选举。
末了选举结果是肯定能选举出一个 Master ，如果只有一个 Local 节点那就选出的是自己。
如果当前节点是 Master ，则开始等待节点数达到 discovery.zen.minimum_master_nodes，然后供应做事。
如果当前节点不是 Master ，则考试测验加入 Master 。Elasticsearch 将以上做事创造以及选主的流程叫做 Zen Discovery 。
由于它支持任意数目的集群（ 1- N ），以是不能像 Zookeeper 那样限定节点必须是奇数，也就无法用投票的机制来选主，而是通过一个规则。
只要所有的节点都遵照同样的规则，得到的信息都是对等的，选出来的主节点肯定是同等的。
但分布式系统的问题就出在信息不对等的情形，这时候很随意马虎涌现脑裂（Split-Brain）的问题。
大多数办理方案便是设置一个 Quorum 值，哀求可用节点必须大于 Quorum（一样平常是超过半数节点），才能对外供应做事。
而 Elasticsearch 中，这个 Quorum 的配置便是 discovery.zen.minimum_master_nodes 。
每个节点既可以是候选主节点也可以是数据节点，通过在配置文件 ../config/elasticsearch.yml 中设置即可，默认都为 true。
node.master: true //是否候选主节点 node.data: true //是否数据节点
数据节点卖力数据的存储和干系的操作，例如对数据进行增、删、改、查和聚合等操作，以是数据节点（Data 节点）对机器配置哀求比较高，对 CPU、内存和 I/O 的花费很大。
常日随着集群的扩大，须要增加更多的数据节点来提高性能和可用性。
候选主节点可以当选举为主节点（Master 节点），集群中只有候选主节点才有选举权和当选举权，其他节点不参与选举的事情。
主节点卖力创建索引、删除索引、跟踪哪些节点是群集的一部分，并决定哪些分片分配给干系的节点、追踪集群中节点的状态等，稳定的主节点对集群的康健是非常主要的。
一个节点既可以是候选主节点也可以是数据节点，但是由于数据节点对 CPU、内存核 I/O 花费都很大。
以是如果某个节点既是数据节点又是主节点，那么可能会对主节点产生影响从而对全体集群的状态产生影响。
因此为了提高集群的康健性，我们该当对 Elasticsearch 集群中的节点做好角色上的划分和隔离。可以利用几个配置较低的机器群作为候选主节点群。
主节点和其他节点之间通过 Ping 的办法互检讨，主节点卖力 Ping 所有其他节点，判断是否有节点已经挂掉。其他节点也通过 Ping 的办法判断主节点是否处于可用状态。
虽然对节点做了角色区分，但是用户的要求可以发往任何一个节点，并由该节点卖力分发要求、网络结果等操作，而不须要主节点转发。
这种节点可称之为折衷节点，折衷节点是不须要指定和配置的，集群中的任何节点都可以充当折衷节点的角色。
③脑裂征象同时如果由于网络或其他缘故原由导致集群中选举出多个 Master 节点，使得数据更新时涌现不一致，这种征象称之为脑裂，即集群中不同的节点对付 Master 的选择涌现了不合，涌现了多个 Master 竞争。
“脑裂”问题可能有以下几个缘故原由造成：
为了避免脑裂征象的发生，我们可以从缘故原由动手通过以下几个方面来做出优化方法：
如果 Master 在该相应韶光的范围内没有做出相应应答，判断该节点已经挂掉了。调大参数（如 6s，discovery.zen.ping_timeout:6），可适当减少误判。
discovery.zen.munimum_master_nodes 的值。这个参数表示在选举主节点时须要参与选举的候选主节点的节点数，默认值是 1，官方建议取值(master_eligibel_nodes2)+1，个中 master_eligibel_nodes 为候选主节点的个数。
这样做既能防止脑裂征象的发生，也能最大限度地提升集群的高可用性，由于只要不少于 discovery.zen.munimum_master_nodes 个候选节点存活，选举事情就能正常进行。
当小于这个值的时候，无法触发选举行为，集群无法利用，不会造身分片混乱的情形。
ES 支持 PB 级全文搜索，当索引上的数据量太大的时候，ES 通过水平拆分的办法将一个索引上的数据拆分出来分配到不同的数据块上，拆分出来的数据库块称之为一个分片。
这类似于 MySQL 的分库分表，只不过 MySQL 分库分表须要借助第三方组件而 ES 内部自身实现了此功能。
在一个多分片的索引中写入数据时，通过路由来确定详细写入哪一个分片中，以是在创建索引的时候须要指定分片的数量，并且分片的数量一旦确定就不能修正。
分片的数量和下面先容的副本数量都是可以通过创建索引时的 Settings 来配置，ES 默认为一个索引创建 5 个主分片, 并分别为每个分片创建一个副本。
PUT /myIndex { \公众settings\"大众 : { \"大众number_of_shards\公众 : 5, \公众number_of_replicas\"大众 : 1 } }
ES 通过分片的功能使得索引在规模上和性能上都得到提升，每个分片都是 Lucene 中的一个索引文件，每个分片必须有一个主分片和零到多个副本。
副本（Replicas）副本便是对分片的 Copy，每个主分片都有一个或多个副本分片，当主分片非常时，副本可以供应数据的查询等操作。
主分片和对应的副本分片是不会在同一个节点上的，以是副本分片数的最大值是 N-1（个中 N 为节点数）。
对文档的新建、索引和删除要求都是写操作，必须在主分片上面完成之后才能被复制到干系的副本分片。
ES 为了提高写入的能力这个过程是并发写的，同时为理解决并发写的过程中数据冲突的问题，ES 通过乐不雅观锁的办法掌握，每个文档都有一个 _version （版本）号，当文档被修正时版本号递增。
一旦所有的副本分片都报告写成功才会向折衷节点报告成功，折衷节点向客户端报告成功。
从上图可以看出为了达到高可用，Master 节点会避免将主分片和副本分片放在同一个节点上。
假设这时节点 Node1 做事宕机了或者网络不可用了，那么主节点上主分片 S0 也就不可用了。
幸运的是还存在其余两个节点能正常事情，这时 ES 会重新选举新的主节点，而且这两个节点上存在我们所须要的 S0 的所有数据。
我们会将 S0 的副本分片提升为主分片，这个提升主分片的过程是瞬间发生的。此时集群的状态将会为 Yellow。
为什么我们集群状态是 Yellow 而不是 Green 呢？虽然我们拥有所有的 2 个主分片，但是同时设置了每个主分片须要对应两份副本分片，而此时只存在一份副本分片。以是集群不能为 Green 的状态。
如果我们同样关闭了 Node2 ，我们的程序依然可以保持在不丢失任何数据的情形下运行，由于 Node3 为每一个分片都保留着一份副本。
如果我们重新启动 Node1 ，集群可以将缺失落的副本分片再次进行分配，那么集群的状态又将规复到原来的正常状态。
如果 Node1 依然拥有着之前的分片，它将考试测验去重用它们，只不过这时 Node1 节点上的分片不再是主分片而是副本分片了，如果期间有变动的数据只须要从主分片上复制修正的数据文件即可。
小结：将数据分片是为了提高可处理数据的容量和易于进行水平扩展，为分片做副本是为了提高集群的稳定性和提高并发量。
副本是乘法，越多花费越大，但也越保险。分片是除法，分片越多，单分片数据就越少也越分散。
副本越多，集群的可用性就越高，但是由于每个分片都相称于一个 Lucene 的索引文件，会占用一定的文件句柄、内存及 CPU。并且分片间的数据同步也会占用一定的网络带宽，以是索引的分片数和副本数也不是越多越好。
映射是用于定义 ES 对索引中字段的存储类型、分词办法和是否存储等信息，就像数据库中的 Schema ，描述了文档可能具有的字段或属性、每个字段的数据类型。
只不过关系型数据库建表时必须指定字段类型，而 ES 对付字段类型可以不指定然后动态对字段类型预测，也可以在创建索引时详细指定字段的类型。
对字段类型根据数据格式自动识别的映射称之为动态映射（Dynamic Mapping），我们创建索引时详细定义字段类型的映射称之为静态映射或显示映射（Explicit Mapping）。
在讲解动态映射和静态映射的利用前，我们先来理解下 ES 中的数据有哪些字段类型？之后我们再讲解为什么我们创建索引时须要建立静态映射而不该用动态映射。
ES（v6.8）中字段数据类型紧张有以下几类：
Text 用于索引全文值的字段，例如电子邮件正文或产品解释。这些字段是被分词的，它们通过分词器通报 ，以在被索引之前将字符串转换为单个术语的列表。
剖析过程许可 Elasticsearch 搜索单个单词中每个完全的文本字段。文本字段不用于排序，很少用于聚合。
Keyword 用于索引构造化内容的字段，例如电子邮件地址，主机名，状态代码，邮政编码或标签。它们常日用于过滤，排序，和聚合。Keyword 字段只能按其确切值进行搜索。
通过对字段类型的理解我们知道有些字段须要明确定义的，例如某个字段是 Text 类型还是 Keyword 类型差别是很大的，韶光字段大概我们须要指定它的韶光格式，还有一些字段我们须要指定特定的分词器等等。
如果采取动态映射是不能精确做到这些的，自动识别常常会与我们期望的有些差异。
以是创建索引的时候一个完全的格式该当是指定分片和副本数以及 Mapping 的定义，如下：
PUT my_index { \"大众settings\公众 : { \公众number_of_shards\公众 : 5, \"大众number_of_replicas\"大众 : 1 } \公众mappings\"大众: { \"大众_doc\公众: { \"大众properties\"大众: { \"大众title\公众: { \公众type\"大众: \"大众text\"大众 }, \公众name\"大众: { \"大众type\"大众: \"大众text\公众 }, \"大众age\"大众: { \"大众type\"大众: \"大众integer\"大众 }, \公众created\"大众: { \"大众type\"大众: \"大众date\"大众, \"大众format\"大众: \"大众strict_date_optional_time||epoch_millis\"大众 } } } } } ES 的基本利用
在决定利用 Elasticsearch 的时候首先要考虑的是版本问题，Elasticsearch （打消 0.x 和 1.x）目前有如下常用的稳定的主版本：2.x，5.x，6.x，7.x（current）。
你可能会创造没有 3.x 和 4.x，ES 从 2.4.6 直接跳到了 5.0.0。实在是为了 ELK（ElasticSearch，Logstash，Kibana）技能栈的版本统一，免的给用户带来混乱。
在 Elasticsearch 是 2.x （2.x 的末了一版 2.4.6 的发布韶光是 July 25, 2017） 的情形下，Kibana 已经是 4.x（Kibana 4.6.5 的发布韶光是 July 25, 2017）。
那么在 Kibana 的下一主版本肯定是 5.x 了，以是 Elasticsearch 直接将自己的主版本发布为 5.0.0 了。
统一之后，我们选版本就不会犹豫困惑了，我们选定 Elasticsearch 的版本后再选择相同版本的 Kibana 就行了，不用担忧版本不兼容的问题。
Elasticsearch 是利用 Java 构建，以是除了把稳 ELK 技能的版本统一，我们在选择 Elasticsearch 的版本的时候还须要把稳 JDK 的版本。
由于每个大版本所依赖的 JDK 版本也不同，目前 7.2 版本已经可以支持 JDK11。
安装利用①下载和解压 Elasticsearch，无需安装解压后即可用，解压后目录如上图：
bin：二进制系统指令目录，包含启动命令和安装插件命令等。config：配置文件目录。data：数据存储目录。lib：依赖包目录。logs：日志文件目录。modules：模块库，例如 x-pack 的模块。plugins：插件目录。②安装目录下运行 bin/elasticsearch 来启动 ES。
③默认在 9200 端口运行，要求 curl http://localhost:9200/ 或者浏览器输入 http://localhost:9200，得到一个 JSON 工具，个中包含当前节点、集群、版本等信息。
{ \"大众name\"大众 : \"大众U7fp3O9\"大众, \"大众cluster_name\公众 : \公众elasticsearch\"大众, \公众cluster_uuid\"大众 : \"大众-Rj8jGQvRIelGd9ckicUOA\"大众, \"大众version\"大众 : { \"大众number\"大众 : \"大众6.8.1\公众, \"大众build_flavor\公众 : \公众default\"大众, \"大众build_type\"大众 : \"大众zip\公众, \"大众build_hash\公众 : \"大众1fad4e1\"大众, \"大众build_date\"大众 : \"大众2019-06-18T13:16:52.517138Z\"大众, \公众build_snapshot\"大众 : false, \公众lucene_version\"大众 : \公众7.7.0\公众, \"大众minimum_wire_compatibility_version\"大众 : \"大众5.6.0\"大众, \公众minimum_index_compatibility_version\"大众 : \"大众5.0.0\"大众 }, \"大众tagline\公众 : \公众You Know, for Search\公众 } 集群康健状态
要检讨群集运行状况，我们可以在 Kibana 掌握台中运行以下命令 GET /_cluster/health，得到如下信息：
{ \"大众cluster_name\"大众 : \公众wujiajian\公众, \"大众status\公众 : \"大众yellow\公众, \公众timed_out\"大众 : false, \"大众number_of_nodes\公众 : 1, \"大众number_of_data_nodes\公众 : 1, \"大众active_primary_shards\"大众 : 9, \"大众active_shards\"大众 : 9, \公众relocating_shards\"大众 : 0, \"大众initializing_shards\公众 : 0, \"大众unassigned_shards\"大众 : 5, \"大众delayed_unassigned_shards\公众 : 0, \"大众number_of_pending_tasks\"大众 : 0, \公众number_of_in_flight_fetch\公众 : 0, \公众task_max_waiting_in_queue_millis\"大众 : 0, \"大众active_shards_percent_as_number\"大众 : 64.28571428571429 }
集群状态通过 绿，黄，红 来标识：
绿色：集群康健无缺，统统功能完好正常，所有分片和副本都可以正常事情。
黄色：预警状态，所有主分片功能正常，但至少有一个副本是不能正常事情的。此时集群是可以正常事情的，但是高可用性在某种程度上会受影响。
赤色：集群不可正常利用。某个或某些分片及其副本非常不可用，这时集群的查询操作还能实行，但是返回的结果会不准确。对付分配到这个分片的写入要求将会报错，终极会导致数据的丢失。
当集群状态为赤色时，它将会连续从可用的分片供应搜索要求做事，但是你须要尽快修复那些未分配的分片。
ES 机制事理ES 的基本观点和基本操作先容完了之后，我们可能还有很多迷惑：
它们内部是如何运行的？
主分片和副本分片是如何同步的？
创建索引的流程是什么样的？
ES 如何将索引数据分配到不同的分片上的？以及这些索引数据是如何存储的？
为什么说 ES 是近实时搜索引擎而文档的 CRUD (创建-读取-更新-删除) 操作是实时的？
以及 Elasticsearch 是若何担保更新被持久化在断电时也不丢失数据？
还有为什么删除文档不会急速开释空间？
带着这些疑问我们进入接下来的内容。
写索引事理下图描述了 3 个节点的集群，共拥有 12 个分片，个中有 4 个主分片（S0、S1、S2、S3）和 8 个副本分片（R0、R1、R2、R3），每个主分片对应两个副本分片，节点 1 是主节点（Master 节点）卖力全体集群的状态。
写索引是只能写在主分片上，然后同步到副本分片。这里有四个主分片，一条数据 ES 是根据什么规则写到特定分片上的呢？
这条索引数据为什么被写到 S0 上而不写到 S1 或 S2 上？那条数据为什么又被写到 S3 上而不写到 S0 上了？
首先这肯定不会是随机的，否则将来要获取文档的时候我们就不知道从何处探求了。
实际上，这个过程是根据下面这个公式决定的：
shard = hash(routing) % number_of_primary_shards
Routing 是一个可变值，默认是文档的 _id ，也可以设置成一个自定义的值。
Routing 通过 Hash 函数天生一个数字，然后这个数字再除以 number_of_primary_shards （主分片的数量）后得到余数。
这个在 0 到 number_of_primary_shards-1 之间的余数，便是我们所寻求的文档所在分片的位置。
这就阐明了为什么我们要在创建索引的时候就确定好主分片的数量并且永久不会改变这个数量：由于如果数量变革了，那么所有之前路由的值都会无效，文档也再也找不到了。
由于在 ES 集群中每个节点通过上面的打算公式都知道集群中的文档的存放位置，以是每个节点都有处理读写要求的能力。
在一个写要求被发送到某个节点后，该节点即为前面说过的折衷节点，折衷节点会根据路由公式打算出须要写到哪个分片上，再将要求转发到该分片的主分片节点上。
如果斯时数据通过路由打算公式取余后得到的值是 shard=hash(routing)%4=0。
则详细流程如下：
客户端向 ES1 节点（折衷节点）发送写要求，通过路由打算公式得到值为 0，则当前数据应被写到主分片 S0 上。
ES1 节点将要求转发到 S0 主分片所在的节点 ES3，ES3 接管要求并写入到磁盘。
并发将数据复制到两个副本分片 R0 上，个中通过乐不雅观并发掌握数据的冲突。一旦所有的副本分片都报告成功，则节点 ES3 将向折衷节点报告成功，折衷节点向客户端报告成功。
上面先容了在 ES 内部索引的写处理流程，这个流程是在 ES 的内存中实行的，数据被分配到特定的分片和副本上之后，终极是存储到磁盘上的，这样在断电的时候就不会丢失数据。
详细的存储路径可在配置文件 ../config/elasticsearch.yml 中进行设置，默认存储在安装目录的 Data 文件夹下。
建议不要利用默认值，由于若 ES 进行了升级，则有可能导致数据全部丢失：
path.data: /path/to/data //索引数据 path.logs: /path/to/logs //日志记录 ①分段存储
索引文档以段的形式存储在磁盘上，作甚段？索引文件被拆分为多个子文件，则每个子文件叫作段，每一个段本身都是一个倒排索引，并且段具有不变性，一旦索引的数据被写入硬盘，就不可再修正。
在底层采取了分段的存储模式，使它在读写时险些完备避免了锁的涌现，大大提升了读写性能。
段被写入到磁盘后会天生一个提交点，提交点是一个用来记录所有提交后段信息的文件。
一个段一旦拥有了提交点，就解释这个段只有读的权限，失落去了写的权限。相反，当段在内存中时，就只有写的权限，而不具备读数据的权限，意味着不能被检索。
段的观点提出紧张是由于：在早期全文检索中为全体文档凑集建立了一个很大的倒排索引，并将其写入磁盘中。
如果索引有更新，就须要重新全量创建一个索引来更换原来的索引。这种办法在数据量很大时效率很低，并且由于创建一次索引的本钱很高，以是对数据的更新不能过于频繁，也就不能担保时效性。
索引文件分段存储并且不可修正，那么新增、更新和删除如何处理呢？
新增，新增很好处理，由于数据是新的，以是只须要对当前文档新增一个段就可以了。
删除，由于不可修正，以是对付删除操作，不会把文档从旧的段中移除而是通过新增一个 .del 文件，文件中会列出这些被删除文档的段信息。这个被标记删除的文档仍旧可以被查询匹配到， 但它会在终极结果被返回前从结果集中移除。
更新，不能修正旧的段来进行反响文档的更新，实在更新相称于是删除和新增这两个动作组成。会将旧的文档在 .del 文件中标记删除，然后文档的新版本被索引到一个新的段中。可能两个版本的文档都会被一个查询匹配到，但被删除的那个旧版本文档在结果集返回前就会被移除。
段被设定为不可修正具有一定的上风也有一定的缺陷，上风紧张表现在：
不须要锁。如果你从来不更新索引，你就不须要担心多进程同时修正数据的问题。
一旦索引被读入内核的文件系统缓存，便会留在哪里，由于其不变性。只要文件系统缓存中还有足够的空间，那么大部分读要求会直接要求内存，而不会命中磁盘。这供应了很大的性能提升。
其它缓存(像 Filter 缓存)，在索引的生命周期内始终有效。它们不须要在每次数据改变时被重修，由于数据不会变革。
写入单个大的倒排索引许可数据被压缩，减少磁盘 I/O 和须要被缓存到内存的索引的利用量。
段的不变性的缺陷如下：
当对旧数据进行删除时，旧数据不会立时被删除，而是在 .del 文件中被标记为删除。而旧数据只能等到段更新时才能被移除，这样会造成大量的空间摧残浪费蹂躏。
若有一条数据频繁的更新，每次更新都是新增新的标记旧的，则会有大量的空间摧残浪费蹂躏。
每次新增数据时都须要新增一个段来存储数据。当段的数量太多时，对做事器的资源例如文件句柄的花费会非常大。
在查询的结果中包含所有的结果集，须要打消被标记删除的旧数据，这增加了查询的包袱。
先容完了存储的形式，那么索引写入到磁盘的过程是若何的？是否是直接调 Fsync 物理性地写入磁盘？
答案是显而易见的，如果是直接写入到磁盘上，磁盘的 I/O 花费上会严重影响性能。
那么当写数据量大的时候会造成 ES 停顿卡去世，查询也无法做到快速相应。如果真是这样 ES 也就不会称之为近实时全文搜索引擎了。
为了提升写的性能，ES 并没有每新增一条数据就增加一个段到磁盘上，而是采取延迟写的策略。
每当有新增的数据时，就将其先写入到内存中，在内存和磁盘之间是文件系统缓存。
当达到默认的韶光（1 秒钟）或者内存的数据达到一定量时，会触发一次刷新（Refresh），将内存中的数据天生到一个新的段上并缓存到文件缓存系统 上，稍后再被刷新到磁盘中并天生提交点。
这里的内存利用的是 ES 的 JVM 内存，而文件缓存系统利用的是操作系统的内存。
新的数据会连续的被写入内存，但内存中的数据并不因此段的形式存储的，因此不能供应检索功能。
由内存刷新到文件缓存系统的时候会天生新的段，并将段打开以供搜索利用，而不须要等到被刷新到磁盘。
在 Elasticsearch 中，写入和打开一个新段的轻量的过程叫做 Refresh （即内存刷新到文件缓存系统）。
默认情形下每个分片会每秒自动刷新一次。这便是为什么我们说 Elasticsearch 是近实时搜索，由于文档的变革并不是立即对搜索可见，但会在一秒之内变为可见。
我们也可以手动触发 Refresh，POST /_refresh 刷新所有索引，POST /nba/_refresh 刷新指定的索引。
Tips：只管刷新是比提交轻量很多的操作，它还是会有性能开销。当写测试的时候， 手动刷新很有用，但是不要在生产>环境下每次索引一个文档都去手动刷新。而且并不是所有的情形都须要每秒刷新。
可能你正在利用 Elasticsearch 索引大量的日志文件， 你可能想优化索引速率而不是>近实时搜索。
这时可以在创建索引时在 Settings 中通过调大 refresh_interval = \"大众30s\"大众 的值 ， 降落每个索引的刷新频率，设值时须要把稳后面带上韶光单位，否则默认是毫秒。当 refresh_interval=-1 时表示关闭索引的自动刷新。
虽然通过延时写的策略可以减少数据往磁盘上写的次数提升了整体的写入能力，但是我们知道文件缓存系统也是内存空间，属于操作系统的内存，只假如内存都存在断电或非常情形下丢失数据的危险。
为了避免丢失数据，Elasticsearch 添加了事务日志（Translog），事务日志记录了所有还没有持久化到磁盘的数据。
添加了事务日志后全体写索引的流程如上图所示：
一个新文档被索引之后，先被写入到内存中，但是为了防止数据的丢失，会追加一份数据到事务日志中。
不断有新的文档被写入到内存，同时也都会记录到事务日志中。这时新数据还不能被检索和查询。
当达到默认的刷新韶光或内存中的数据达到一定量后，会触发一次 Refresh，将内存中的数据以一个新段形式刷新到文件缓存系统中并清空内存。这时虽然新段未被提交到磁盘，但是可以供应文档的检索功能且不能被修正。
随着新文档索引不断被写入，当日志数据大小超过 512M 或者韶光超过 30 分钟时，会触发一次 Flush。
内存中的数据被写入到一个新段同时被写入到文件缓存系统，文件系统缓存中数据通过 Fsync 刷新到磁盘中，天生提交点，日志文件被删除，创建一个空的新日志。
通过这种办法当断电或须要重启时，ES 不仅要根据提交点去加载已经持久化过的段，还须要工具 Translog 里的记录，把未持久化的数据重新持久化到磁盘上，避免了数据丢失的可能。
③段合并
由于自动刷新流程每秒会创建一个新的段 ，这样会导致短韶光内的段数量暴增。而段数目太多会带来较大的麻烦。
每一个段都会花费文件句柄、内存和 CPU 运行周期。更主要的是，每个搜索要求都必须轮流检讨每个段然后合并查询结果，以是段越多，搜索也就越慢。
Elasticsearch 通过在后台定期进行段合并来办理这个问题。小的段被合并到大的段，然后这些大的段再被合并到更大的段。
段合并的时候会将那些旧的已删除文档从文件系统中打消。被删除的文档不会被拷贝到新的大段中。合并的过程中不会中断索引和搜索。
段合并在进行索引和搜索时会自动进行，合并进程选择一小部分大小相似的段，并且在后台将它们合并到更大的段中，这些段既可以是未提交的也可以是已提交的。
合并结束后老的段会被删除，新的段被 Flush 到磁盘，同时写入一个包含新段且打消旧的和较小的段的新提交点，新的段被打开可以用来搜索。
段合并的打算量弘大， 而且还要吃掉大量磁盘 I/O，段合并会拖累写入速率，如果任其发展会影响搜索性能。
Elasticsearch 在默认情形下会对合并流程进行资源限定，以是搜索仍旧有足够的资源很好地实行。
性能优化
存储设备磁盘在当代做事器上常日都是瓶颈。Elasticsearch 重度利用磁盘，你的磁盘能处理的吞吐量越大，你的节点就越稳定。
这里有一些优化磁盘 I/O 的技巧：
利用 SSD。就像其他地方提过的， 他们比机器磁盘精良多了。
利用 RAID 0。条带化 RAID 会提高磁盘 I/O，代价显然便是当一块硬盘故障时全体就故障了。不要利用镜像或者奇偶校验 RAID 由于副本已经供应了这个功能。
其余，利用多块硬盘，并许可 Elasticsearch 通过多个 path.data 目录配置把数据条带化分配到它们上面。
不要利用远程挂载的存储，比如 NFS 或者 SMB/CIFS。这个引入的延迟对性能来说完备是背道而驰的。
如果你用的是 EC2，当心 EBS。即便是基于 SSD 的 EBS，常日也比本地实例的存储要慢。
Elasticsearch 为了能快速找到某个 Term，先将所有的 Term 排个序，然后根据二分法查找 Term，韶光繁芜度为 logN，就像通过字典查找一样，这便是 Term Dictionary。
现在再看起来，彷佛和传统数据库通过 B-Tree 的办法类似。但是如果 Term 太多，Term Dictionary 也会很大，放内存不现实，于是有了 Term Index。
就像字典里的索引页一样，A 开头的有哪些 Term，分别在哪页，可以理解 Term Index是一棵树。
这棵树不会包含所有的 Term，它包含的是 Term 的一些前缀。通过 Term Index 可以快速地定位到 Term Dictionary 的某个 Offset，然后从这个位置再今后顺序查找。
在内存中用 FST 办法压缩 Term Index，FST 以字节的办法存储所有的 Term，这种压缩办法可以有效的缩减存储空间，使得 Term Index 足以放进内存，但这种办法也会导致查找时须要更多的 CPU 资源。
对付存储在磁盘上的倒排表同样也采取了压缩技能减少存储所占用的空间。
调度配置参数调度配置参数建议如下：
给每个文档指定有序的具有压缩良好的序列模式 ID，避免随机的 UUID-4 这样的 ID，这样的 ID 压缩比很低，会明显拖慢 Lucene。
对付那些不须要聚合和排序的索引字段禁用 Doc values。Doc Values 是有序的基于 document=>field value 的映射列表。
不须要做模糊检索的字段利用 Keyword 类型代替 Text 类型，这样可以避免在建立索引前对这些文本进行分词。
如果你的搜索结果不须要近实时的准确度，考虑把每个索引的 index.refresh_interval 改到 30s 。
如果你是在做大批量导入，导入期间你可以通过设置这个值为 -1 关掉刷新，还可以通过设置 index.number_of_replicas: 0 关闭副本。别忘却在落成的时候重新开启它。
避免深度分页查询建议利用 Scroll 进行分页查询。普通分页查询时，会创建一个 from+size 的空优先行列步队，每个分片会返回 from+size 条数据，默认只包含文档 ID 和得分 Score 给折衷节点。
如果有 N 个分片，则折衷节点再对（from+size）×n 条数据进行二次排序，然后选择须要被取回的文档。当 from 很大时，排序过程会变得很沉重，占用 CPU 资源严重。
减少映射字段，只供应须要检索，聚合或排序的字段。其他字段可存在其他存储设备上，例如 Hbase，在 ES 中得到结果后再去 Hbase 查询这些字段。
创建索引和查询时指定路由 Routing 值，这样可以精确到详细的分片查询，提升查询效率。路由的选择须要把稳数据的分布均衡。
JVM 调优建议如下：
确保堆内存最小值（ Xms ）与最大值（ Xmx ）的大小是相同的，防止程序在运行时改变堆内存大小。Elasticsearch 默认安装后设置的堆内存是 1GB。可通过 ../config/jvm.option 文件进行配置，但是最好不要超过物理内存的50%和超过 32GB。
GC 默认采取 CMS 的办法，并发但是有 STW 的问题，可以考虑利用 G1 网络器。
ES 非常依赖文件系统缓存（Filesystem Cache），快速搜索。一样平常来说，该当至少确保物理上有一半的可用内存分配到文件系统缓存。
