关于java:全文搜索引擎Elasticsearch这篇文章给讲透了

• 于 elasticsearch 的深度好文。

  生存中的数据

  搜索引擎是对数据的检索，所以咱们先从生存中的数据说起。咱们生存中的数据总体分为两种：

  • 结构化数据
  • 非结构化数据

结构化数据：也称作行数据，是由二维表构造来逻辑表白和实现的数据，严格地遵循数据格式与长度标准，次要通过关系型数据库进行存储和治理。指具备固定格局或无限长度的数据，如数据库，元数据等。

非结构化数据：又可称为全文数据，不定长或无固定格局，不适于由数据库二维表来体现，包含所有格局的办公文档、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 能实现全文搜寻次要是因为它实现了倒排索引的查问构造。

如何了解倒排索引呢？如果现有三份数据文档，文档的内容如下别离是：

• Java is the best programming language.
• PHP is the best programming language.
• Javascript is the best programming language.

为了创立倒排索引，咱们通过分词器将每个文档的内容域拆分成独自的词（咱们称它为词条或 Term），创立一个蕴含所有不反复词条的排序列表，而后列出每个词条呈现在哪个文档。

后果如下所示：

这种构造由文档中所有不反复词的列表形成，对于其中每个词都有一个文档列表与之关联。

这种由属性值来确定记录的地位的构造就是倒排索引。带有倒排索引的文件咱们称为倒排文件。

咱们将下面的内容转换为图的模式来阐明倒排索引的构造信息，如下图所示：

其中次要有如下几个外围术语须要了解：

• 词条（Term）：索引外面最小的存储和查问单元，对于英文来说是一个单词，对于中文来说个别指分词后的一个词。
• 词典（Term Dictionary）：或字典，是词条 Term 的汇合。搜索引擎的通常索引单位是单词，单词词典是由文档汇合中呈现过的所有单词形成的字符串汇合，单词词典内每条索引项记录单词自身的一些信息以及指向“倒排列表”的指针。
• 倒排表（Post list）：一个文档通常由多个词组成，倒排表记录的是某个词在哪些文档里呈现过以及呈现的地位。

  每条记录称为一个倒排项（Posting）。倒排表记录的不单是文档编号，还存储了词频等信息。

• 倒排文件（Inverted File）：所有单词的倒排列表往往程序地存储在磁盘的某个文件里，这个文件被称之为倒排文件，倒排文件是存储倒排索引的物理文件。

从上图咱们能够理解到倒排索引次要由两个局部组成：

• 词典
• 倒排文件

词典和倒排表是 Lucene 中很重要的两种数据结构，是实现疾速检索的重要基石。词典和倒排文件是分两局部存储的，词典在内存中而倒排文件存储在磁盘上。

## ES 外围概念

一些基础知识的铺垫之后咱们正式进入明天的配角 Elasticsearch 的介绍。

ES 是应用 Java 编写的一种开源搜索引擎，它在外部应用 Lucene 做索引与搜寻，通过对 Lucene 的封装，暗藏了 Lucene 的复杂性，取而代之的提供一套简略统一的 RESTful API。

然而，Elasticsearch 不仅仅是 Lucene，并且也不仅仅只是一个全文搜索引擎。

它能够被上面这样精确的形容：

• 一个分布式的实时文档存储，每个字段能够被索引与搜寻。
• 一个分布式实时剖析搜索引擎。
• 能胜任上百个服务节点的扩大，并反对 PB 级别的结构化或者非结构化数据。

咱们通过一些外围概念来看下 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，认为 Master 挂掉了从而选举出新的 Master，并对 Master 上的分片和正本标红，调配新的主分片。
• 节点负载：主节点的角色既为 Master 又为 Data，访问量较大时可能会导致 ES 进行响应（假死状态）造成大面积提早，此时其余节点得不到主节点的响应认为主节点挂掉了，会从新选取主节点。
• 内存回收：主节点的角色既为 Master 又为 Data，当 Data 节点上的 ES 过程占用的内存较大，引发 JVM 的大规模内存回收，造成 ES 过程失去响应。

为了防止脑裂景象的产生，咱们能够从起因着手通过以下几个方面来做出优化措施：

• 适当调大响应工夫，缩小误判。通过参数 discovery.zen.ping_timeout 设置节点状态的响应工夫，默认为 3s，能够适当调大。

  如果 Master 在该响应工夫的范畴内没有做出响应应答，判断该节点曾经挂掉了。调大参数（如 6s，discovery.zen.ping_timeout:6），可适当缩小误判。

• 选举触发。咱们须要在候选集群中的节点的配置文件中设置参数 discovery.zen.munimum_master_nodes 的值。

  这个参数示意在选举主节点时须要参加选举的候选主节点的节点数，默认值是 1，官网倡议取值(master_eligibel_nodes/2)+1，其中 master_eligibel_nodes 为候选主节点的个数。

  这样做既能避免脑裂景象的产生，也能最大限度地晋升集群的高可用性，因为只有不少于 discovery.zen.munimum_master_nodes 个候选节点存活，选举工作就能失常进行。

  当小于这个值的时候，无奈触发选举行为，集群无奈应用，不会造成分片凌乱的状况。

• 角色拆散。即是下面咱们提到的候选主节点和数据节点进行角色拆散，这样能够加重主节点的累赘，避免主节点的假死状态产生，缩小对主节点“已死”的误判。

## 分片（Shards）

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。

  并且分片间的数据同步也会占用肯定的网络带宽，所以索引的分片数和正本数也不是越多越好。

## 映射（Mapping）

映射是用于定义 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 调优

JVM 调优倡议如下：

• 确保堆内存最小值（Xms）与最大值（Xmx）的大小是雷同的，避免程序在运行时扭转堆内存大小。

  Elasticsearch 默认装置后设置的堆内存是 1GB。可通过 ../config/jvm.option 文件进行配置，然而最好不要超过物理内存的 50% 和超过 32GB。

• GC 默认采纳 CMS 的形式，并发然而有 STW 的问题，能够思考应用 G1 收集器。

• ES 十分依赖文件系统缓存（Filesystem Cache），疾速搜寻。一般来说，应该至多确保物理上有一半的可用内存调配到文件系统缓存。

  起源：https://www.cnblogs.com/jajia…

欢送关注公众号【码农开花】一起学习成长
我会始终分享 Java 干货，也会分享收费的学习材料课程和面试宝典
回复：【计算机】【设计模式】【面试】有惊喜哦