核心概念
索引(Index)
一个索引就是一个拥有几分相似特征的文档的集合。比如说，你可以有一个客户数据的索引，另一个产品目录的索引，还有一个订单数据的索引。一个索引由一个名字来标识(必 须全部是小写字母)，并且当我们要对这个索引中的文档进行索引、搜索、更新和删除的时 候，都要使用到这个名字。在一个集群中，可以定义任意多的索引。
能搜索的数据必须索引，这样的好处是可以提高查询速度，比如:新华字典前面的目录 就是索引的意思，目录可以提高查询速度。
Elasticsearch 索引的精髓:一切设计都是为了提高搜索的性能。
类型(Type)
在一个索引中，你可以定义一种或多种类型。
一个类型是你的索引的一个逻辑上的分类/分区，其语义完全由你来定。通常，会为具 有一组共同字段的文档定义一个类型。不同的版本，类型发生了不同的变化
| 版本 | Type |
|---|---|
| 5.x | 支持多种 type |
| 6.x | 只能有一种 type |
| 7.x | 默认不再支持自定义索引类型(默认类型为:_doc) |
文档(Document)
一个文档是一个可被索引的基础信息单元，也就是一条数据
比如:你可以拥有某一个客户的文档，某一个产品的一个文档，当然，也可以拥有某个订单的一个文档。文档以 JSON(Javascript Object Notation)格式来表示，而 JSON 是一个 到处存在的互联网数据交互格式。
在一个 index/type 里面，你可以存储任意多的文档。
字段(Field)
相当于是数据表的字段，对文档数据根据不同属性进行的分类标识。
映射(Mapping)
mapping 是处理数据的方式和规则方面做一些限制，如:某个字段的数据类型、默认值、分析器、是否被索引等等。这些都是映射里面可以设置的，其它就是处理 ES 里面数据的一 些使用规则设置也叫做映射，按着最优规则处理数据对性能提高很大，因此才需要建立映射， 并且需要思考如何建立映射才能对性能更好。
分片(Shards)
一个索引可以存储超出单个节点硬件限制的大量数据。比如，一个具有 10 亿文档数据的索引占据 1TB 的磁盘空间，而任一节点都可能没有这样大的磁盘空间。或者单个节点处 理搜索请求，响应太慢。为了解决这个问题，Elasticsearch 提供了将索引划分成多份的能力， 每一份就称之为分片。当你创建一个索引的时候，你可以指定你想要的分片的数量。每个分 片本身也是一个功能完善并且独立的“索引”，这个“索引”可以被放置到集群中的任何节点上。
分片很重要，主要有两方面的原因:
- 允许你水平分割 / 扩展你的内容容量。
- 允许你在分片之上进行分布式的、并行的操作，进而提高性能/吞吐量。
至于一个分片怎样分布，它的文档怎样聚合和搜索请求，是完全由 Elasticsearch 管理的，对于作为用户的你来说，这些都是透明的，无需过分关心。
被混淆的概念是，一个 Lucene 索引 我们在 Elasticsearch 称作分片 。 一个 Elasticsearch 索引 是分片的集合。 当 Elasticsearch 在索引中搜索的时候， 他发送查询到每一个属于索引的分片(Lucene 索引)，然后合并每个分片的结果到一个全局的结果集。
副本(Replicas)
在一个网络 / 云的环境里，失败随时都可能发生，在某个分片/节点不知怎么的就处于离线状态，或者由于任何原因消失了，这种情况下，有一个故障转移机制是非常有用并且是 强烈推荐的。为此目的，Elasticsearch 允许你创建分片的一份或多份拷贝，这些拷贝叫做复 制分片(副本)。
复制分片之所以重要，有两个主要原因：
- 在分片/节点失败的情况下，提供了高可用性。因为这个原因，注意到复制分片从不与原/主要(original/primary)分片置于同一节点上是非常重要的。
- 扩展你的搜索量/吞吐量，因为搜索可以在所有的副本上并行运行。
总之，每个索引可以被分成多个分片。一个索引也可以被复制 0 次(意思是没有复制) 或多次。一旦复制了，每个索引就有了主分片(作为复制源的原来的分片)和复制分片(主 分片的拷贝)之别。分片和复制的数量可以在索引创建的时候指定。在索引创建之后，你可 以在任何时候动态地改变复制的数量，但是你事后不能改变分片的数量。默认情况下， Elasticsearch 中的每个索引被分片 1 个主分片和 1 个复制，这意味着，如果你的集群中至少 有两个节点，你的索引将会有 1 个主分片和另外 1 个复制分片(1 个完全拷贝)，这样的话 每个索引总共就有 2 个分片，我们需要根据索引需要确定分片个数。
分配(Allocation)
将分片分配给某个节点的过程，包括分配主分片或者副本。如果是副本，还包含从主分片复制数据的过程。这个过程是由 master 节点完成的。
系统架构
一个运行中的 Elasticsearch 实例称为一个节点，而集群是由一个或者多个拥有相同 cluster.name 配置的节点组成， 它们共同承担数据和负载的压力。当有节点加入集群中或者 从集群中移除节点时，集群将会重新平均分布所有的数据。
当一个节点被选举成为主节点时， 它将负责管理集群范围内的所有变更，例如增加、 删除索引，或者增加、删除节点等。 而主节点并不需要涉及到文档级别的变更和搜索等操作，所以当集群只拥有一个主节点的情况下，即使流量的增加它也不会成为瓶颈。 任何节 点都可以成为主节点。我们的示例集群就只有一个节点，所以它同时也成为了主节点。
作为用户，我们可以将请求发送到集群中的任何节点 ，包括主节点。 每个节点都知道 任意文档所处的位置，并且能够将我们的请求直接转发到存储我们所需文档的节点。 无论 我们将请求发送到哪个节点，它都能负责从各个包含我们所需文档的节点收集回数据，并将最终结果返回給客户端。 Elasticsearch 对这一切的管理都是透明的。
路由计算
当索引一个文档的时候，文档会被存储到一个主分片中。 Elasticsearch 如何知道一个文档应该存放到哪个分片中呢?当我们创建文档时，它如何决定这个文档应当被存储在分片 1 还是分片 2 中呢?首先这肯定不会是随机的，否则将来要获取文档的时候我们就不知道从何处寻找了。实际上，这个过程是根据下面这个公式决定的:
# routing 是一个可变值，默认是文档的 _id ，也可以设置成一个自定义的值。 routing 通过hash 函数生成一个数字，然后这个数字再除以 number_of_primary_shards (主分片的数量)后得到余数 。这个分布在 0 到 number_of_primary_shards-1 之间的余数，就是我们所寻求的文档所在分片的位置。
shard = hash(routing) % number_of_primary_shards
这就解释了为什么我们要在创建索引的时候就确定好主分片的数量 并且永远不会改变 这个数量：因为如果数量变化了，那么所有之前路由的值都会无效，文档也再也找不到了。
所有的文档 API( get 、 index 、 delete 、 bulk 、 update 以及 mget )都接受一个叫做 routing 的路由参数 ，通过这个参数我们可以自定义文档到分片的映射。一个自定 义的路由参数可以用来确保所有相关的文档——例如所有属于同一个用户的文档——都被存储到同一个分片中。
分片原理
分片是 Elasticsearch 最小的工作单元。但是究竟什么是一个分片，它是如何工作的?
传统的数据库每个字段存储单个值，但这对全文检索并不够。文本字段中的每个单词需要被搜索，对数据库意味着需要单个字段有索引多值的能力。最好的支持是一个字段多个值需求的数据结构是倒排索引。
倒排索引
Elasticsearch 使用一种称为倒排索引的结构，它适用于快速的全文搜索。
见其名，知其意，有倒排索引，肯定会对应有正向索引。正向索引(forward index)，反向索引(inverted index)更熟悉的名字是倒排索引。
所谓的正向索引，就是搜索引擎会将待搜索的文件都对应一个文件 ID，搜索时将这个ID 和搜索关键字进行对应，形成 K-V 对，然后对关键字进行统计计数
但是互联网上收录在搜索引擎中的文档的数目是个天文数字，这样的索引结构根本无法满足 实时返回排名结果的要求。所以，搜索引擎会将正向索引重新构建为倒排索引，即把文件 ID 对应到关键词的映射转换为关键词到文件 ID 的映射，每个关键词都对应着一系列的文件， 这些文件中都出现这个关键词。
一个倒排索引由文档中所有不重复词的列表构成，对于其中每个词，有一个包含它的文 档列表。例如，假设我们有两个文档，每个文档的 content 域包含如下内容:
- The quick brown fox jumped over the lazy dog
- Quick brown foxes leap over lazy dogs in summer
为了创建倒排索引，我们首先将每个文档的 content 域拆分成单独的 词(我们称它为 词条 或 tokens )，创建一个包含所有不重复词条的排序列表，然后列出每个词条出现在哪个文 档。结果如下所示:
现在，如果我们想搜索 quick brown ，我们只需要查找包含每个词条的文档:
两个文档都匹配，但是第一个文档比第二个匹配度更高。如果我们使用仅计算匹配词条数量 的简单相似性算法，那么我们可以说，对于我们查询的相关性来讲，第一个文档比第二个文 档更佳。
但是，我们目前的倒排索引有一些问题： - Quick 和 quick 以独立的词条出现，然而用户可能认为它们是相同的词。
- fox 和 foxes 非常相似, 就像 dog 和 dogs ;他们有相同的词根。
- jumped 和 leap, 尽管没有相同的词根，但他们的意思很相近。他们是同义词。
使用前面的索引搜索 +Quick +fox 不会得到任何匹配文档。(记住，+ 前缀表明这个词必须存在。)只有同时出现 Quick 和 fox 的文档才满足这个查询条件，但是第一个文档包含 quick fox ，第二个文档包含 Quick foxes 。 我们的用户可以合理的期望两个文档与查询匹配。我们可以做的更好。 如果我们将词条规范为标准模式，那么我们可以找到与用户搜索的词条不完全一致，但具有足够相关性的文档。例如: - Quick 可以小写化为 quick 。
- foxes 可以 词干提取 --变为词根的格式-- 为 fox 。类似的， dogs 可以为提取为 dog 。
- jumped 和 leap 是同义词，可以索引为相同的单词 jump 。
现在索引看上去像这样：
这还远远不够。我们搜索 +Quick +fox 仍然 会失败，因为在我们的索引中，已经没有 Quick 了。但是，如果我们对搜索的字符串使用与 content 域相同的标准化规则，会变成查询 +quick +fox，这样两个文档都会匹配!分词和标准化的过程称为分析，这非常重要。你只能搜索在索引中出现的词条，所以索引文本和查询字符串必须标准化为相同的格式。
文档搜索
早期的全文检索会为整个文档集合建立一个很大的倒排索引并将其写入到磁盘。 一旦新的索引就绪，旧的就会被其替换，这样最近的变化便可以被检索到。 倒排索引被写入磁盘后是 不可改变 的:它永远不会修改。
不变性有重要的价值：
- 不需要锁。如果你从来不更新索引，你就不需要担心多进程同时修改数据的问题。
- 一旦索引被读入内核的文件系统缓存，便会留在哪里，由于其不变性。只要文件系统缓存中还有足够的空间，那么大部分读请求会直接请求内存，而不会命中磁盘。这提供了很大的性能提升。
- 其它缓存(像filter缓存)，在索引的生命周期内始终有效。它们不需要在每次数据改变时被重建，因为数据不会变化。
- 写入单个大的倒排索引允许数据被压缩，减少磁盘 I/O 和 需要被缓存到内存的索引的使用量。
当然，一个不变的索引也有不好的地方。主要事实是它是不可变的! 你不能修改它。如 果你需要让一个新的文档 可被搜索，你需要重建整个索引。这要么对一个索引所能包含的 数据量造成了很大的限制，要么对索引可被更新的频率造成了很大的限制。
文档分析
分析 包含下面的过程:
- 将一块文本分成适合于倒排索引的独立的 词条
- 将这些词条统一化为标准格式以提高它们的“可搜索性”，或者 recall
分析器执行上面的工作。分析器实际上是将三个功能封装到了一个包里: - 字符过滤器
首先，字符串按顺序通过每个字符过滤器 。他们的任务是在分词前整理字符串。一个字符过滤器可以用来去掉 HTML，或者将 & 转化成 and。 - 分词器
其次，字符串被 分词器 分为单个的词条。一个简单的分词器遇到空格和标点的时候， 可能会将文本拆分成词条。 - Token 过滤器
最后，词条按顺序通过每个 token 过滤器 。这个过程可能会改变词条(例如，小写化 Quick )，删除词条(例如， 像 a， and， the 等无用词)，或者增加词条(例如，像 jump 和 leap 这种同义词)。
内置分析器
Elasticsearch 还附带了可以直接使用的预包装的分析器。接下来我们会列出最重要的分析器。为了证明它们的差异，我们看看每个分析器会从下面的字符串得到哪些词条："Set the shape to semi-transparent by calling set_trans(5)"
- 标准分析器
标准分析器是 Elasticsearch 默认使用的分析器。它是分析各种语言文本最常用的选择。
它根据 Unicode 联盟 定义的 单词边界 划分文本。删除绝大部分标点。最后，将词条小写。 它会产生:
set, the, shape, to, semi, transparent, by, calling, set_trans, 5 - 简单分析器
简单分析器在任何不是字母的地方分隔文本，将词条小写。它会产生: set, the, shape, to, semi, transparent, by, calling, set, trans - 空格分析器 空格分析器在空格的地方划分文本。它会产生:
Set, the, shape, to, semi-transparent, by, calling, set_trans(5) - 语言分析器
特定语言分析器可用于 很多语言。它们可以考虑指定语言的特点。例如， 英语 分析
器附带了一组英语无用词(常用单词，例如 and 或者 the ，它们对相关性没有多少影响)， 它们会被删除。 由于理解英语语法的规则，这个分词器可以提取英语单词的 词干 。
英语 分词器会产生下面的词条:
set, shape, semi, transpar, call, set_tran, 5
注意看 transparent、 calling 和 set_trans 已经变为词根格式
分析器使用场景
当我们 索引 一个文档，它的全文域被分析成词条以用来创建倒排索引。 但是，当我们在全文域 搜索 的时候，我们需要将查询字符串通过 相同的分析过程 ，以保证我们搜索 的词条格式与索引中的词条格式一致。
全文查询，理解每个域是如何定义的，因此它们可以做正确的事:
- 当你查询一个 全文 域时， 会对查询字符串应用相同的分析器，以产生正确的搜 索词条列表。
- 当你查询一个 精确值 域时，不会分析查询字符串，而是搜索你指定的精确值。
指定分析器
当Elasticsearch在你的文档中检测到一个新的字符串域，它会自动设置其为一个全文 字符串 域，使用 标准 分析器对它进行分析。你不希望总是这样。可能你想使用一个不同的 分析器，适用于你的数据使用的语言。有时候你想要一个字符串域就是一个字符串域—不使用分析，直接索引你传入的精确值，例如用户 ID 或者一个内部的状态域或标签。要做到这 一点，我们必须手动指定这些域的映射。
IK 分词器
ES 的默认分词器无法识别中文中测试、单词这样的词汇，而是简单的将每个字拆完分为一 个词，这样的结果显然不符合我们的使用要求，所以我们需要下载 ES 对应版本的中文分词器。
我们这里采用 IK 中文分词器，下载地址为: https://github.com/medcl/elasticsearch-analysis-ik/releases/tag/v7.8.0 将解压后的后的文件夹放入 ES 根目录下的 plugins 目录下，重启 ES 即可使用。
# 测试：GET http://localhost:9200/_analyze
{
"text":"测试单词",
# ik_max_word:会将文本做最细粒度的拆分 ik_smart:会将文本做最粗粒度的拆分
"analyzer":"ik_max_word"
}
自定义分析器
虽然 Elasticsearch 带有一些现成的分析器，然而在分析器上 Elasticsearch 真正的强大之处在于，你可以通过在一个适合你的特定数据的设置之中组合字符过滤器、分词器、词汇单 元过滤器来创建自定义的分析器。在 分析与分析器 我们说过，一个 分析器 就是在一个包 里面组合了三种函数的一个包装器， 三种函数按照顺序被执行:
-
字符过滤器
字符过滤器 用来 整理 一个尚未被分词的字符串。例如，如果我们的文本是 HTML 格 式的，它会包含像或者
这样的 HTML 标签，这些标签是我们不想索引的。我 们可以使用 html 清除 字符过滤器 来移除掉所有的 HTML 标签，并且像把 Á 转换 为相对应的 Unicode 字符 Á 这样，转换 HTML 实体。一个分析器可能有 0 个或者多个字符 过滤器。 -
分词器
一个分析器 必须 有一个唯一的分词器。 分词器把字符串分解成单个词条或者词汇单
元。 标准 分析器里使用的 标准 分词器 把一个字符串根据单词边界分解成单个词条，并 且移除掉大部分的标点符号，然而还有其他不同行为的分词器存在。
例如， 关键词 分词器 完整地输出 接收到的同样的字符串，并不做任何分词。 空格 分词 器 只根据空格分割文本 。 正则 分词器 根据匹配正则表达式来分割文本 。 -
词单元过滤器
经过分词，作为结果的 词单元流 会按照指定的顺序通过指定的词单元过滤器 。
词单元过滤器可以修改、添加或者移除词单元。我们已经提到过 lowercase 和 stop 词过滤 器 ，但是在 Elasticsearch 里面还有很多可供选择的词单元过滤器。词干过滤器 把单词 遏 制 为 词干。 ascii_folding 过滤器移除变音符，把一个像 "très" 这样的词转换为 "tres" 。ngram 和 edge_ngram 词单元过滤器 可以产生 适合用于部分匹配或者自动补全的词单元
# 创建自定义的分析器
# PUT http://localhost:9200/my_index
{
"settings": {
"analysis": {
"char_filter": {
"&_to_and": {
"type": "mapping",
"mappings": ["&=> and "]
}
},
"filter": {
"my_stopwords": {
"type": "stop",
"stopwords": ["the", "a"]
}
},
"analyzer": {
"my_analyzer": {
"type": "custom",
"char_filter": ["html_strip", "&_to_and"],
"tokenizer": "standard",
"filter": ["lowercase", "my_stopwords"]
}
}
}
}
}
# 索引被创建以后，使用 analyzeAPI 来 测试这个新的分析器
# GET http://127.0.0.1:9200/my_index/_analyze
{
"text":"The quick & brown fox",
"analyzer": "my_analyzer"
}
# 下面的缩略结果展示出我们的分析器正在正确地运行
{
"tokens": [{
"token": "quick",
"start_offset": 4,
"end_offset": 9,
"type": "<ALPHANUM>",
"position": 1
}, {
"token": "and",
"start_offset": 10,
"end_offset": 11,
"type": "<ALPHANUM>",
"position": 2
}, {
"token": "brown",
"start_offset": 12,
"end_offset": 17,
"type": "<ALPHANUM>",
"position": 3
}, {
"token": "fox",
"start_offset": 18,
"end_offset": 21,
"type": "<ALPHANUM>",
"position": 4
}]
}
文档处理
当我们使用 indexAPI 更新文档 ，可以一次性读取原始文档，做我们的修改，然后重新索引整个文档 。 最近的索引请求将被作为最终结果，无论最后哪一个文档被索引，都将被唯一存储在 Elasticsearch 中。如果其他人同时更改这个文档，他们的更改将丢失。变更越频繁，读数据和更新数据的间隙越长，也就越可能丢失变更。 在数据库领域中，有两种方法通常被用来确保并发更新时变更不会丢失：悲观并发控制和乐观并发控制。
Elasticsearch有两种并发控制：
- 乐观并发控制
Elasticsearch 是分布式的。当文档创建、更新或删除时， 新版本的文档必须复制到集群中的其他节点。Elasticsearch 也是异步和并发的，这意味着这些复制请求被并行发送，并 且到达目的地时也许 顺序是乱的 。 Elasticsearch 需要一种方法确保文档的旧版本不会覆盖新的版本。
当我们之前讨论 index ，GET 和 delete 请求时，我们指出每个文档都有一个 _version (版本)号，当文档被修改时版本号递增。 Elasticsearch 使用这个 version 号来确保变更 以正确顺序得到执行。如果旧版本的文档在新版本之后到达，它可以被简单的忽略。
我们可以利用 version 号来确保 应用中相互冲突的变更不会导致数据丢失。我们通过 指定想要修改文档的 version 号来达到这个目的。 如果该版本不是当前版本号，我们的请 求将会失败。
老的版本 es 使用 version，但是新版本不支持了，提示我们用 if_seq_no 和 if_primary_term - 外部系统版本控制
一个常见的设置是使用其它数据库作为主要的数据存储，使用 Elasticsearch 做数据检索， 这意味着主数据库的所有更改发生时都需要被复制到 Elasticsearch ，如果多个进程负责这一数据同步，你可能遇到类似于之前描述的并发问题。
如果你的主数据库已经有了版本号或一个能作为版本号的字段值比如 timestamp，那么你就可以在 Elasticsearch 中通过增加 version_type=external 到查询字符串的方式重用这些相同的版本号， 版本号必须是大于零的整数， 且小于 9.2E+18 — 一个 Java 中 long 类型的正值。
外部版本号的处理方式和我们之前讨论的内部版本号的处理方式有些不同， Elasticsearch 不是检查当前 _version 和请求中指定的版本号是否相同， 而是检查当前 _version 是否小于指定的版本号。 如果请求成功，外部的版本号作为文档的新 _version 进行存储。外部版本号不仅在索引和删除请求是可以指定，而且在 创建 新文档时也可以指定。