ElasticSearch学习笔记

Elasticsearch是一个基于Apache Lucene的全文检索和分析引擎，可以扩容到上百台服务器，处理PB级结构化/非结构化数据。

ES的应用场景举例：

1. 支持在线搜索、自动完成（搜索建议）功能
2. 作为ELK栈的一部分，收集、聚合、分析日志/事务数据
3. 海量数据的即席分析

Elasticsearch 尽可能地屏蔽了分布式系统的复杂性，它在后台自动执行的操作包括：

1. 分配文档到不同的容器或分片中，文档可以储存在一个或多个节点中
2. 按集群节点来均衡分配这些分片，从而对索引和搜索过程进行负载均衡
3. 复制每个分片以支持数据冗余，从而防止硬件故障导致的数据丢失
4. 将集群中任一节点的请求路由到存有相关数据的节点
5. 集群扩容时无缝整合新节点，重新分配分片以便从离群节点恢复

ES是一个准实时（Near Realtime）的搜索平台，从你开始索引一个文档，到该文档可以被搜索，有个较小的延迟，通常秒级。

唯一的依赖是JDK，请预先安装好JDK8（建议1.8.0_131+），然后：

所有节点、客户端都应该使用一样的JDK版本。

ES的Docker镜像基于CentOS:7。相关镜像的列表参考：https://www.docker.elastic.co/。

镜像分为三种风格：basic包含基本的X-Pack特性，自动激活免费License；platinum包含全部X-Pack特性，默认30天试用；oss不支持X-Pack，仅仅包含ES。

执行下面的命令拉取镜像：

参考如下命令部署容器：

内核参数vm.max_map_count至少要增大到262144： sysctl -w vm.max_map_count=262144  

参考kubernetes-elasticsearch-cluster搭建集群。注意点：

1. ES的Pod需要超级用户权限运行init容器，避免设置某些VM选项。因此你需要以--allow-privileged选项运行kubelet
2. ES_JAVA_OPTS的默认值为-Xms256m -Xmx256m，非常小。你可以按需调整
3. 数据节点Pod默认在一个emptyDir中存储数据，请根据实际情况修改
4. PROCESSORS的默认值为1，如果需要调整，请设置resources.limits.cpu、livenessProbe
5. 支持1.9.3+版本的K8S

从下面的仓库下载K8S资源定义文件：

资源规格定义如下：

一系列节点的集合，它们在整体上持有完整的数据集，提供联合的索引（Federated indexing），并在整体上对外提供搜索功能。

每个集群以名字来识别，默认名字elasticsearch，每个节点只能属于单个集群。如果部署多套集群，注意确保集群名字不重复。

节点是集群中的单个服务器。节点的唯一标识也是名称，默认是节点启动时随机生成的UUID。

当一个节点被选举成为主节点时， 它将负责管理集群范围内的所有变更，例如增加、删除索引，或者增加、删除节点等。 而主节点并不需要涉及到文档级别的变更和搜索等操作，所以当集群只拥有一个主节点的情况下，即使流量的增加它也不会成为瓶颈。 任何节点都可以成为主节点。

用户可以将请求发送到 集群中的任何节点 ，包括主节点。每个节点都知道任意文档所处的位置，并且能够将请求直接转发到存储所需文档的节点。

索引是一系列具有相近特性的文档的集合。例如客户数据可以对应一个索引，商品目录可以对应另一个索引。ES中的索引类似于RDBMS中的表。索引的唯一标识是名称，名称必须全小写。

当索引作为动词使用时，表示将一个文档存储到索引（名词）中，是其支持全文检索的过程。

Mapping用于描述数据的每个字段如何存储。ES自动生成一个_all字段，其类型为字符串，属于全文字段。ES会根据文档内容进行猜测，动态产生一个映射。

Elasticsearch 支持 如下简单域类型：

1. 字符串：string
2. 整数：byte, short, integer, long
3. 浮点数：float, double
4. 布尔型：boolean
5. 日期：date

当你索引一个包含新字段的文档时，ES自动进行动态映射。JSON类型到上述类型的转换比较直白，除了要注意2018-04-03这样的字符串会被自动解析为date类型。

除了上述的简单标量类型外，JSON中的null、数组、对象，都是被ES支持的。

空字段不会被索引，包括：null、null、[ null ]

Lucene不理解嵌套对象，Lucene文档由一组键值对的列表构成。为了支持复杂类型的处理，ES必须对文档进行扁平化。

多值域以数组形式表示，数组的元素类型必须相同。尽管提取文档时，数组元素顺序不会丢失，但是索引是以无序的多值域形式进行的：

类似的，为了让ES有效的索引嵌套对象，同样需要扁平化：

Analysis是处理全文字段，使其可以被搜索的过程。分析包含下面的步骤：

1. 首先，将一块文本分成适合于倒排索引的独立的词条
2. 之后，将这些词条统一化为标准格式以提高它们的“可搜索性”

分析器负责执行上面的工作。 分析器实际上是将三个功能封装到了一个包里：

1. 字符过滤器：首先，字符串按顺序通过每个字符过滤器 。他们的任务是在分词前整理字符串。一个字符过滤器可以用来去掉HTML，或者将 & 转化成and
2. 分词器：其次，字符串被分词器分为单个的词条。一个简单的分词器遇到空格和标点的时候，可能会将文本拆分成词条
3. Token过滤器：最后，词条按顺序通过每个Token过滤器 。这个过程可能会：
   1. 改变词条，例如小写化
   2. 删除词条，例如像 a， and， the这样的无用词
   3. 增加词条，例如像 jump 和 leap 这种同义词

ES提供了开箱即用的字符过滤器、分词器、Token过滤器，它们可以自由的组合成分析器，满足不同应用场景。

分词器（Tokenizer）决定“从哪里切开”，分析器（Analyzer）决定“切开之后再做什么”。如果把全文检索看成一条流水线，那么字符过滤器负责预清洗，分词器负责切边界，Token 过滤器负责归一化、删词、扩词与词干化，分析器只是把这三层组件串成一个可复用名字。

分词器是分析链中唯一负责“切 token 边界”的组件。它把原始字符串切成词项序列，但通常不负责小写化、停用词过滤、同义词扩展或词干提取；这些操作通常由后续 Token 过滤器完成。

分词器	切分规则	典型用途
standard	按 Unicode 文本分词规则切分	通用全文检索默认选择，适合多数自然语言文本。
letter	按非字母字符切分	纯字母文本或规则较简单的英文内容。
lowercase	按非字母字符切分，并把 token 转成小写	英文等大小写噪声明显、又不需要复杂规则的文本。
classic	按传统英文文档规则切分	偏旧式英文文本或希望保留经典 Lucene 行为时使用。
whitespace	仅按空白字符切分	日志、命令行、格式较规整的文本。
keyword	完全不切分，整串文本作为一个 token	ID、完整路径、完整邮箱、状态码等精确值场景。
pattern	按正则表达式切分	邮件地址、分号分隔值、业务格式化字符串。
uax_url_email	按 UAX 规则切分，并尽量把 URL / Email 保持为整体	网页文本、论坛内容、带大量 URL 与邮箱的语料。
char_group	按字符组切分	对分隔符集合比较固定的半结构化文本。
ngram	把词切成连续 n-gram	模糊匹配、拼写纠错、子串召回。
edge_ngram	只保留前缀 n-gram	自动完成、前缀补全。
path_hierarchy	按路径层级展开	目录树、URL 路径、组织层级过滤。
thai	按泰语规则切分	泰语文本分析。

分析器	说明
标准分析器	默认的分析器，根据Unicode联盟定义的单词边界来划分文本，删除绝大部分标点符号，最后小写化
简单分析器	在任何非字母的地方拆分词条
空格分析器	以空格为界拆分词条
停用词分析器	在简单切分基础上移除停用词，适合英文等停用词明显的文本。
关键字分析器	不切分文本，整串作为一个 token，常用于需要精确匹配但又希望走分析链的场景。
模式分析器	基于正则表达式切分，适合分隔符规则清晰的文本。
指纹分析器	把 token 归一化、排序并去重后合成一个签名，常用于去重或规范化匹配。
语言分析器	针对具体自然语言构造完整分析链，通常组合小写化、停用词、词干提取、语言归一化与省音符处理。
自定义分析器	手工指定 char_filter、 tokenizer 和 filter，用于业务域定制。

内置语言分析器的目标不是“把所有语言统一切分”，而是为每种语言提供更合理的停用词、词干化和归一化规则。对英语、法语、德语、西班牙语这类有明显词形变化的语言，语言分析器通常比通用分析器更适合检索。

语言组	内置分析器	说明
西欧与北欧语言	english, french, german, spanish, italian, portuguese, brazilian, dutch, norwegian, swedish, danish, finnish, irish	重点在停用词、词干化和词形归一化。
中东、南亚与古典字母语言	arabic, armenian, persian, greek, hindi, bengali	除停用词与词干化外，通常还需要语言特定归一化。
中东欧与斯拉夫语系	czech, hungarian, romanian, russian, bulgarian, sorani, turkish	这些语言词形变化明显，直接用标准分析器往往损失召回。
南欧、小语种与区域语言	basque, catalan, galician, estonian, latvian, lithuanian, indonesian	内置语言分析器让这些语言无需手工拼装停用词和词干器。
东亚与无空格语言	cjk, thai	cjk 适合中日韩混合文本的通用切分， thai 面向泰语。

ES 内置分析器对中文并不充分。生产环境中的中文全文检索通常依赖插件补足中文切分、拼音召回或繁简转换能力。你给出的 DSL 就属于这一路线：它把插件分析器与自定义分析链组合起来，而不是只用内置分析器。

组件	层次	作用
ik_max_word	分词器 / 分析器链核心	尽量细粒度切分中文，适合正文、主题等召回优先场景。
ik_smart	分词器 / 分析器链核心	较粗粒度切分中文，适合人名、地址、邮件头等噪声较多但不希望切得太碎的字段。
stconvert	字符过滤器	在分词前完成繁简转换，避免繁体与简体内容索引不一致。
synonym	Token 过滤器	把业务同义词、缩写、别称纳入同一检索空间。

1. 当索引一个文档时，它的全文域被分析成词条以用来创建倒排索引
2. 当在全文字段上执行搜索时，查询字符串也需要类似的分析过程

当查询一个精确值字段时，分析器不会介入。

当ES在你的文档中检测到一个新的字符串域 ，它会自动设置其为一个全文字符串域，使用标准分析器对它进行分析。某些情况下你可能需要改变此默认行为：

1. 你想使用一个不同的分析器，适用于你的数据使用的语言
2. 你想要一个字符串域就是一个精确值，不需要分析

可以通过自定义映射来满足上述需求。

总体来说，ES中的字段可以分为精确值、全文两个大类。

精确值包括日期、数字，字符串也可以表示精确值。精确值是大小写敏感的。精确值很容易查询，它要么匹配，要么不匹配查询条件。

查询全文字段则要复杂得多，通常不会对全文字段进行精确匹配查询。全文字段匹配查询条件时有相关度的概念，表现为分数（Score）。搜索引擎应该能够识别缩写、词根、同义词，并给出适当的相关度。

对全文检索的支持依赖于分析，在分析之后需要创建倒排索引。

text 是全文字段类型。写入时会经过分析链，查询时通常也会分析输入，因此适合正文、标题、姓名、地址、备注等需要分词和相关性排序的内容。

keyword 是精确值字段类型。它通常把整个输入值作为一个完整项存入倒排结构，不做全文分词，因此适合 ID、状态、来源类型、邮箱 Message-ID、枚举值、标签、聚合、排序和过滤。

不要把 keyword字段类型和 keyword分析器 / 分词器混为一谈。前者属于 mapping 层，决定字段如何建索引；后者属于 analysis 层，决定字符串在分析链中是否切分。

同一个逻辑字段可以映射出多个物理检索视图，这就是多字段（Multi-fields）。最常见的写法是一个 text主字段负责全文召回，再挂一个 keyword子字段负责排序、聚合和精确过滤。

你给出的 DSL 里， from 同时挂了 keyword和 email两个子字段，本质上也是同一套路：一份原始值，同时服务于精确匹配和不同分析策略。

ES使用一种称为倒排索引的结构来支持快速的全文检索。

倒排索引的结构类似于RDBMS的位图索引，对于索引中出现的任何不重复词条的标准形式，生成包含该词的文档列表。标准形式可能已经过词干提取、同义词扩展等处理。

默认情况下，查询返回结果是按相关性倒序排列的。每个文档都有相关性评分，用一个正浮点数字段 _score 来表示 。 _score 的评分越高，相关性越高。

查询语句会为每个文档生成一个 _score 字段。评分的计算方式取决于查询类型。不同的查询语句用于不同的目的：fuzzy 查询会计算与关键词的拼写相似程度。terms 查询会计算找到的内容与关键词组成部分匹配的百分比。

通常我们说的 relevance 是我们用来计算全文字段相对于检索词相似程度的算法。可以把它理解为 TF / IDF 思想的现代工程实现：词出现得越关键、越稀有、越贴近合适长度的字段，得分通常越高。

1. 检索词频率：检索词在该字段出现的频率。出现频率越高，相关性通常越高
2. 反向文档频率：每个检索词在索引中出现的频率。出现越普遍，区分度越低，相关性通常越低
3. 字段长度准则：字段本身的长度。字段越长，单个词命中的权重通常越低

现代 ES 默认使用 BM25 作为相似度模型。BM25 仍然围绕“词频、逆文档频率、字段长度归一化”这三件事工作，但它不会让词频无限线性增长，而是让重复命中的收益逐渐饱和，因此比朴素 TF 计算更稳健。

在索引 DSL 里， similarity 可以先在 settings.index.similarity中定义一个具名模型，再由字段通过 "similarity": "mail_bm25"引用。这样做的意义不在于“换一种完全不同的排序理论”，而在于显式固定参数，避免不同字段沿用默认值而失去可解释性。

BM25 最常见的两个参数是 k1和 b。 k1控制词频增长多快进入饱和区；值越大，重复命中带来的额外得分持续得越久。 b控制字段长度归一化强度；值越接近 1，长字段越容易被压分，值越接近 0，长度差异影响越弱。

Type用于对索引进行分区/分类，允许你在一个索引里存储不同类型的文档。从6.0开始Type被弃用。

可被索引的最小信息单元，以JSON形式表示。

一个索引的数据量可以超过硬盘的物理容量限制，ES使用分片来突破此限制。每个分片都是独立的、完整功能的“子索引”

创建索引时，你可以指定分片的数量。但是，分片如何分配给节点，分片中的文档如何被聚合以响应查询，完全由ES管理，对用户透明。

每个分片可以创建0-N个副本，这样可以避免单点故障。

ES的API通过JSON over RESTful HTTP暴露。除非特别强调，所有API都遵守本节描述的约定。

大部分支持index参数的API，都能够跨越多个索引执行。你可以用以下形式指定多个索引：

所有支持多索引的API，均识别以下URL参数：

参数	说明
ignore_unavailable	是否忽视不存在或者关闭的索引，取值true/false
allow_no_indices	是否允许没有任何匹配的索引
expand_wildcards	通配符如何展开，open仅仅展开匹配打开的索引，其它取值all，close

指定索引名时，你可以提供一些特殊符号，以匹配时间序列索引集中的一个范围，这样可以避免全集群扫描过滤。

几乎所有支持index参数的API，均可以指定如下格式的索引名：

示例：

表达式	说明	解析为
<logstash-{now/d}>	截断到日起点	logstash-2018.04.12
<logstash-{now/M}>	截断到月起点	logstash-2018.04.01
<logstash-{now/M{YYYY.MM}}>	截断到月，格式化为年月	logstash-2018.04
<logstash-{now/M-1M{YYYY.MM}}>	截断到月，减一月	logstash-2018.03
<logstash-{now/d{YYYY.MM.dd|+8:00}}>	使用东八区格式化	logstash-2018.04.12

运算符： +1d添加一天、 -1d减少一天、 /d向下截断到最近一天、 /h向下截断到最近一小时。例如 now-1h/d表示当前时间的毫秒数减去1小时，然后向下截断为UTC当日零时。

日期字段：y年、M月、w周、d日、h时、m分、s秒

选项	说明
pretty=true	格式化打印，默认打印为JSON格式
format=yaml	打印为YAML格式
human=false	是否以人类易读方式输出数字
filter_path	用于减少服务器返回的响应长度，该参数为逗号分隔的、响应字段过滤器。例如： filter_path=took,hits.hits._id,hits.hits._score filter_path=metadata.indices.*.stat*，支持通配符 filter_path=routing_table.indices.**.state，通配符**表示可以跨越多级路径 filter_path=-_shards，短横线表示排除
flat_settings	影响_settings查询的输出格式
error_trace	设置为true，则查询出错时返回结果包含调用栈信息，便于诊断
source	使用不支持非POST请求体的HTTP客户端库时，使用此参数传递请求体内容

REST参数（使用HTTP时对应URL参数）使用小写+下划线的风格。

类型	说明
布尔	取值true或者false，不支持其它取值
数字	支持原生JSON数字类型 支持单位：k、m、g、t、p
时间	支持单位：d、h、m、s、ms、micros、nanos
字节数	支持单位：b、kb、mb、gb、tb、pb
距离	支持单位：km、m、cm、mm

某些查询/API支持非精确的“模糊查询”，你可以指定fuzziness参数。

当针对text或keyword字段进行模糊查询时，“模糊”被解释为编辑距离（Levenshtein Edit Distance）——为了让一个字符串变为另一个，所需改变的字符个数。

某些库不支持非POST请求的请求体，此时你可以将请求体作为source查询参数传递。

需要同时传递参数source_content_type来指定内容类型，例如application/json。

必须通过请求头Content-Type来设置请求体格式，大部分API支持 JSON, YAML, CBOR,SMILE这些格式。批量/多搜索API支持NDJSON,JSON,SMILE。

默认副本份数是1，要为将来创建的索引修改副本份数，执行：

你可以使用 analyze API 来看文本是如何被分析的：

使用_mapping API可以获取1-N个索引的1-N个字段的映射信息：

_validate 可以用来验证查询是否合法：

尽管在很多情况下基本域数据类型已经够用，但你经常需要为单独域自定义映射 ，特别是字符串域。自定义映射允许你执行下面的操作：

1. 全文字符串域和精确值字符串域的区别
2. 使用特定语言分析器
3. 优化域以适应部分匹配
4. 指定自定义数据格式

指定字段映射时，最重要的属性是type，对于非string字段，通常仅仅需要设置type。

首次创建一个索引时，你可以指定自定义映射，以后，你可以使用_mapping API创建新字段的映射，或者修改现有字段的映射。注意一个限制：不能把字段从analyzed修改为not_analyzed。

首次创建索引时指定映射的例子：

上面的例子对应的是旧版写法：它使用了 string字段类型和显式 type 名称。理解一份现代索引 DSL 时，真正需要抓住的版本分界主要有两个。第一，ES 5.0 把旧的 string拆成了 text与 keyword。从这时开始，“全文字段 + keyword 子字段”的多字段写法成为主流。第二，ES 7.0 进入 typeless API 时代，创建索引与定义 mapping 时不再以业务 type 名称作为顶层键；到了 ES 8.0，mapping types 已被彻底移除。

因此，像 settings、 mappings、 properties、 dynamic_templates、多字段 fields、自定义 analyzer / tokenizer / similarity 这样的结构，本身并不是 7.14 才引入的新能力。它们是 ES 索引设计体系中的长期组成部分。真正带来语法差异的是字段类型从 string 迁移为 text / keyword，以及mapping 从 typed 结构迁移为 typeless 结构。

显式 mapping 只能覆盖你提前知道的字段。遇到动态字段时，如果完全依赖自动映射，ES 会按默认规则猜测类型，这在日志索引或半结构化业务字段中经常不够稳。 dynamic_templates 的作用就是：当新字段第一次出现时，按“路径 + 类型匹配规则”把它映射成你指定的类型，而不是交给默认动态映射。

因此， "all_strings_as_keyword" 这一类模板的准确含义不是“所有字符串都变成关键词字段”，而是所有未显式声明、且命中模板条件的动态字符串字段，都默认按 keyword类型落地。这样做的目的通常是保住过滤、聚合、排序和精确匹配能力，避免动态字段被自动建成全文字段后变得难以治理。

参数	所在层次	作用
properties	mapping	显式定义字段名、字段类型和字段级参数。
dynamic_templates	mapping	为动态出现的新字段指定“命中条件 → 映射模板”的规则。
fields	字段级 mapping	为同一个原始值建立多个索引视图，例如 text 主字段加 keyword 子字段。
analyzer	字段级 mapping	控制字段在建索引时如何分析文本。
search_analyzer	字段级 mapping	控制字段在查询时如何分析输入；当查询分析策略与索引分析策略不同时使用。
ignore_above	keyword 子字段	超长值不写入该 keyword 字段，避免极端长字符串带来额外索引和存储负担。
format	日期字段	声明日期字符串允许的解析格式。
similarity	字段级 mapping	给字段绑定具名相似度模型，例如自定义 BM25 参数。

除了 mapping，创建索引时通常还会同时定义一批索引级参数。它们控制的不是“字段如何解释”，而是“索引如何写入、刷新、分片和排序”。

设置项	作用	典型考虑
refresh_interval	控制新写入文档多久对搜索可见一次	值越小，检索越快看到新数据；值越大，写入吞吐通常更高。
number_of_shards	主分片数量	决定索引的并行度和未来扩展边界，创建后通常不能随意修改。
number_of_replicas	副本数量	影响高可用、读吞吐和存储成本。
max_result_window	限制 from + size 的最大深分页窗口	窗口越大，深分页代价越高；超大分页通常更适合改成游标式方案，而不是无限抬高窗口。
translog.sync_interval	事务日志同步周期	影响 translog 刷新节奏与持久化行为。
translog.durability	控制写请求何时算持久化成功	request 更稳， async 更偏吞吐。
analysis	定义自定义分析链组件	包括 char_filter、 tokenizer、 filter 与具名 analyzer。
similarity	定义具名相关性模型	供字段通过 mapping 中的 similarity 参数引用。

DSL 组成	版本判断	说明
settings / mappings / properties	早期版本已存在	这是 ES 索引定义最基础的骨架，不是 7.x 新功能。
dynamic_templates	早期版本已存在	动态模板长期用于约束动态字段如何落地，7.x 继续沿用。
多字段 fields	早期版本已存在；5.0 后更常见	一个原始值映射出多个检索视图； text + keyword 组合在 5.0 之后尤其常见。
text / keyword	5.0 关键变更	这是旧 string 类型被拆分后的新语义边界。
search_analyzer / ignore_above	早期版本已存在	分别用于区分查询时分析器和限制超长 keyword 值建索引。
自定义 analyzer / tokenizer	早期版本已存在	分析链是 ES 全文检索的基础设施，7.x 只是继续使用。
pattern tokenizer	早期版本已存在	属于标准分析组件家族，不是因为邮件搜索场景才新出现。
具名 BM25 similarity	BM25 在现代 ES 中是默认相关性模型；显式命名属于配置写法	这里的重点不是“用了新算法”，而是给字段显式绑定一套可调参数。
typeless mappings.properties	7.0 关键语法变化	不再写成 mappings.<type>.properties。
mapping types 完全移除	8.0 最终状态	如果还沿用 typed 写法，就已经不属于 8.x 兼容语法。

下面给出一份脱敏后的邮件检索索引定义。它保留了实战中的核心结构，但去掉了环境地址、认证信息、双索引切换逻辑和业务专有索引名，只保留索引 schema 本身。该示例适合用来解释 ES 7.x 中一份完整索引 DSL 的层次关系。

这份 DSL 的设计重点不是“字段越多越好”，而是三层控制同时成立。第一层是 properties，把查询路径上的关键字段显式定型。第二层是 dynamic_templates，为未知字符串字段提供稳定兜底，避免动态映射把结构化字段错误落成全文字段。第三层是多字段 fields，让同一份原始值同时服务于全文召回、精确过滤、聚合排序和特定检索策略。

• Strings are dead, long live strings
• Removal of mapping types
• Create index API
• Text field type
• Keyword field type
• Dynamic templates
• Multi-fields
• Built-in analyzers
• Tokenizers
• Language analyzers
• Pattern tokenizer
• Similarity settings

修改某个文档类型的某个字段的映射的例子：

插入一个文档：

使用相同URL再次PUT，则对标识符为1的文档进行替换（Reindex）操作。

插入文档时，可以不显式指定ID，ES会自动随机生成一个： POST /customer/_doc?pretty ... 

如果索引文档时，目标索引不存在，则：

1. 自动创建索引，设置选项action.auto_create_index=false，可以禁用
2. 自动创建一个类型映射，设置选项index.mapper.dynamic=false，可以禁用

每个被索引的文档都具有对应的版本号，此版本号作为响应的一部分返回。默认情况下，索引从1开始，每次更新（即使没有做任何改变）、删除操作后增1。

请求可以直接指定版本号，这种情况下ES自动进行乐观并发控制：PUT index_name/_doc/1?version=2。乐观并发控制的典型应用场景是读后更新。

版本化是完全实时的，不受检索操作的准实时性影响。如果不提供version参数，则ES不对操作进行版本检查。

版本号可以存放在ES外部，要启用此特性，设置version_type=external。这种情况下，请求参数中的版本号会和当前被索引的文档中的版本号进行比较，如果请求中的版本号大则新文档被存储、索引。

指定 op_type=create则强制进行创建操作，如果同ID的文档已经存在，则报错。

默认情况下，文档ID的哈希值决定了它被存放到哪个分片上。你可以使用请求参数 routing，其值作为哈希函数的入参。

根据路由的结果，索引操作在相应的主分片（所在的节点）上执行。当主分片的索引操作完成后，更新操作复制到可用的从分片。

为了提升可靠性，ES允许配置为必须等待一定数量的分片的写操作完成，在此之前，请求必须等待、重试，或者超时。默认情况下只需要等待主分片，即index.write.wait_for_active_shards=1。你也可以针对请求来设置wait_for_active_shards参数。设置为all则需要等待所有分片操作完成。

执行索引操作时，主分片可能处于不可用状态，默认情况下，ES会等待1分钟，此超时时间可以通过请求参数timeout定制。

除了插入/替换文档之外，我们还可以进行更新操作。注意，实际上ES是不支持In-place更新的，它仅仅是把更新信息merge到原文档中，然后替换掉原文档。示例：

这类API允许基于ID来取得JSON格式的文档：

你也可以使用HEAD方法来检查目标文档是否存在：HEAD customer/_doc/id

默认情况下get操作是实时的，不受到索引刷新率的影响。

如果所请求的文档已经更新，但是尚未刷新，则此API会即席的发起一次刷新操作。设置请求参数realtime=false禁用此自动刷新行为。

默认情况下此API获取源文档的所有内容，即_source字段。设置_source=false则不返回源文档的任何内容。

如果需要返回某些字段，使用_source_include请求参数；如果需要排除某些字段，使用_source_exclude字段，示例：

要仅仅返回响应文档的_source字段，使用请求：customer/_doc/1/_source

如果索引文档时使用routing来指定路由，则提取文档时必须传入相同的routing参数。

使用参数preference，可以指定在什么分片上提取文档。默认值是随机选取分片。取值_primary则仅仅在主分片上提取，取值_local则尽可能在本地分配的分片上提取。

分片副本份数越多，则操作的性能越好。

使用参数refresh=true，可以在提取之前刷新相关的分片。使用此参数时要注意对系统性能的潜在影响。

传递version参数，则仅在当前文档版本号匹配时，才返回。

使用mget API可以同时提取多个文档：

返回值包含一个docs数组

根据ID来删除一个已被索引的文档：

版本化、路由、分布式、刷新、超时类似于索引文档。

可以将匹配查询条件的文档删除：

此API会获取其被调用时的索引的快照，并基于此快照中匹配文档的内部版本号，执行删除操作。

注意：由于内部版本化不支持版本号0， 因此version=0的文档无法被_delete_by_query删除。 

ES提供了批量操作的API，可以把多个CRUD操作组合在一起执行：

如果批处理中的某个操作失败，则它会继续处理。最终，所有操作的执行结果会返回给调用者。

准备数据：

当执行搜索时，请求会广播给索引的全部分片，并以RR算法选择分片的Replica。使用routing参数可以强制在匹配哈希值的分片上执行搜索，你可以为routing指定逗号分隔的多个值。

除了默认的RR轮询算法以外，ES还支持自适应Replica选择，自动选取最适当的Replica。选取准则包括：

1. 根据协调（coordinating）节点向数据节点转发请求的响应时间
2. 在数据节点上执行请求所消耗的时间
3. 数据节点的搜索线程池大小

要启用该特性，设置集群选项：

除了在每个请求中设置超时之外，ES还支持全局性的搜索超时search.default_search_timeout，此设置没有默认值，设置为-1可以取消先前设置的值。

搜索可以通过标准的任务取消机制来取消。默认情况下ES仅仅在段边界（segment boundaries）来检查请求是否已经被取消，因此取消操作可能由于大段而延迟。要降低取消操作的响应时间，可以设置search.low_level_cancellation=true，但是要注意此设置会导致更加频繁的检查。

默认情况下ES不限制搜索请求牵涉到的分片数量，你可以设置软限制 action.search.shard_count.limit 来拒绝命中太多分片的请求。

参数max_concurrent_shard_requests可以限制搜索请求最多同时在多少个分片上执行，可以防止单个搜索请求消耗整个集群的资源。 此参数的默认值取决于集群中数据节点的数量，最多256。

检索API支持两种传递查询参数的方式：通过URL参数、通过请求体。

要检索特定索引上，任何类型的文档，使用：/index_name/_search

要检索特定索引上，特定类型的文档，使用：/index_name/type1,type2.../_search

要检索多个索引上，具有特定标签的，使用：/index1,index2/_search?q=tag:tag1

要检索任何的索引，使用：/_all/_search

示例：

注意，并非所有检索选项支持URL方式传参。

query参数传递Query DSL，示例：

可用参数：

参数	说明
timeout	搜索超时，默认无
from	分页，起始偏移量，默认0
size	分页，抓取结果数量，默认10
search_type	搜索类型，取值dfs_query_then_fetch、query_then_fetch，默认query_then_fetch 只能作为URL参数传递
request_cache	true/false，是否启用搜索结果（仅针对size为0的请求，亦即聚合/建议请求）的缓存 只能作为URL参数传递
terminate_after	每个分片最多收集的文档数量，如果超过限制查询立即终止，响应中的terminated_early设置为true 设置此参数为1，可以实现快速检查是否存在匹配（exists）
batched_reduce_size	在协调节点（coordinating node）上，每次Reduce分片结果的数量。可以防止单个请求占用太多的内存

一旦搜索结果返回，ES就不会在服务器端存留任何资源，例如游标。这个特性和关系型数据库不同。

默认情况下，返回的结果是按照相关性（评分）进行排序的——最相关的文档排在最前，默认按照_score字段降序排序。

你也可以定制排序方式：

ES支持根据数组字段、多值字段进行排序，此时可以设置sort.mode字段：

sort.mode	说明
min	取数组中的最小值参与排序
max	取数组中的最大值参与排序
sum	取数组元素总和参与排序
avg	取数组元素平均值参与排序
median	取中位数参与排序

ES支持依据文档中的嵌套字段进行排序，示例：

使用missing指定可以指定当某个文档没有参与排序的字段时该怎么办，默认值为_last，可以取值_first或者自定义一个用于排序的数值：

ES支持根据二维平面上的距离值来排序，示例：

排序算法可以由自定义的脚本提供：

当使用排序时，默认不会计算匹配分数，要改变此行为设置track_scores = true

当执行排序时，排序相关的字段被载入内存。每个分片都需要具有足够的内存来容纳这些字段：

1. 对于参与排序的字符串类型，不应该被analyzed/tokenized
2. 对于参与排序的数字类型，尽可能使用更短的类型

允许根据现有字段，进行计算，衍生出新的字段：

通常的规则是，使用 查询（query）语句来进行全文搜索或者其它任何需要影响相关性得分的搜索。除此以外的情况都使用过滤（filters)。

本节以Query DSL语法说明如何指定查询条件。

过滤查询（Filtering queries）只是简单的检查包含或者排除，这就使得计算起来非常快。过滤查询不进行评分，结果可以被缓存。

相反，评分查询（scoring queries）不仅仅要找出 匹配的文档，还要计算每个匹配文档的相关性，计算相关性使得它们比不评分查询费力的多。同时，查询结果并不缓存。

由于倒排索引（inverted index），一个简单的评分查询在匹配少量文档时可能与一个涵盖百万文档的filter表现的一样好，甚至会更好。但是在一般情况下，一个filter 会比一个评分的query性能更优异，并且每次都表现的很稳定。

注意filter可以放在不同位置，仅仅其引用的查询条件不影响评分，而不是整个查询不支持评分。过滤查询示例：

ES支持修改搜索结果，为匹配搜索的字段添加HTML标签，以便高亮显示：

示例：

执行结果如下：

你可以指定聚合函数、排序方式：

ES提供了很适当的默认配置，需要很少的定制化。大部分配置项都可以在运行时更新。 

ES的配置文件主要有三个：

1. elasticsearch.yml 主配置文件
2. jvm.options 使用的JVM参数
3. log4j2.properties 日志配置

这些配置文件位于conf目录，具体位置和你使用的安装方式有关。可以通过环境变量定制：

主配置文件基于YML格式，支持通过${VAR_NAME}来引用环境变量，例如：

主要的配置项如下：

默认情况下，ES使用固定大小的1G堆内存。关于JVM参数配置的建议包括：

1. 设置堆的最小值和最大值相同
2. 堆越大，ES越可以缓存更多的东西。但是大堆意味着更长的GC停顿
3. Xmx不要设置超过50%的物理内存。为内核和系统缓存留下空间 

ES使用Java安全管理器。JVM默认无限期的缓存DNS解析记录，如果你依赖于动态解析的DNS，则需要配置安全管理器：

Swap可能导致JVM堆甚至可执行页被交换到磁盘中，对性能有非常不利的影响。Swap可能导致GC从毫秒级变为分钟级完成、导致节点响应异常缓慢甚至脱离集群。因此，宁愿让OS把节点杀掉也不要启用Swap。

你可以执行下面的命令来禁用所有交换文件：

注释掉/etc/fstab中的相关行，可以永久禁用Swap。

设置systctl参数vm.swappiness为1，可以减小Linux内核进行Swap的倾向，让它在通常情况下不会Swap。

或者，你可以利用Linux的mlockall，将ES进程的地址空间锁定在内存中，配置ES：

ES需要使用大量的文件描述符/文件句柄。确保运行ES的用户可以打开65536或者更多的文件描述符。

ES默认使用一个mmapfs目录来存储其索引，OS的mmap计数默认值很低，可能导致OOM异常。执行下面命令修改：

ES需要创建很多线程来完成不同的操作，你最少要保证ES能够创建4096个线程：ulimit -u 4096或者设置nprocs

对于Gold/Platinum类型的License，如果你启用了安全，则必须同时启用TLS。

你可以使用外部提供的CA证书，或者通过下面的命令生成：

可以使用下面的命令生成p12格式的私钥、证书：

默认情况下，此证书不包含SAN字段，因此可以所有节点共享。如果需要更加严格的身份验证，可以传入--name, --dns --ip参数。

你可以可以使用外部提供的证书。

把密钥拷贝到节点的config/certs目录下

添加以下ES配置项：

验证模式默认certificate，不检查SAN，如果需要更加严格的身份验证，设置为full。

重启服务后，集群节点间的TLS通信OK，你可以使用Gold/Platinum的License了。

登陆到客户端节点，执行下面的命令，可以随机生成elastic、kibana、logstash_system的新密码：

 或者，你也可以交互式的设置密码：

添加ES配置项：

角色	说明
ingest_admin	可以访问所有索引模板、ingest流水线配置
kibana_dashboard_only_user	可以访问Kibana仪表盘，只读访问.kibana索引
kibana_system	可以读写Kibana索引，检查集群可用性，管理索引模板。可以读.monitoring-*索引，读写.reporting-*索引
kibana_user	Kibana用户的最小权限，可以访问Kibana索引，监控集群状态
logstash_admin	可以访问.logstash*索引，以管理配置
logstash_system	Logstash系统级用户，可以发送监控数据给ES
monitoring_user	支持X-pack monitoring
remote_monitoring_agent	支持写入监控数据到ES
superuser	超级用户
transport_client	支持访问Node Liveness API、Cluster State API，例如/_cluster/state/version
watcher_admin	读写.watches索引
watcher_user	只读.watches索引

启用身份验证后，如果没有修改内置用户密码，则kibana登陆界面会提示：Login is currently disabled. Administrators should consult the Kibana logs for more details.

你需要更改kibana的配置项elasticsearch.password，如果在Docker中运行Kibana，也可以修改环境变量ELASTICSEARCH_PASSWORD。然后使用setup-passwords命令更改内置用户密码。

建议把节点分为三类：

1. Master节点，仅仅负责集群管理，不存储数据，不提供HTTP API
2. Client节点，和客户端通信，不存储数据，提供HTTP API
3. Data节点，仅仅负责存储、索引数据，不提供HTTP API

对于超过32GB的堆，无法使用压缩普通对象指针（Compressed Ordinary Object Pointer），指针大小变为64bit。这导致50GB的堆，能存储的对象数量和30GB的堆差不多。

堆的最大、最小值应该设置为一致。

低水位：默认情况下，节点磁盘用量超过85%后，ES不会分发新的分片到该节点。即便如此，已有的分片仍然可能继续增大。

高水位：默认情况下，节点磁盘用量超过90%后，ES会停止写入，并且将该节点上的分片重现分配给磁盘空闲的其它节点。

副本：默认情况下使用1个副本，这意味着两倍的磁盘空间

分片：更大的分片，在存储上越高效。但是节点失败导致数据迁移的成本也越高。

索引是存储文档并让其可检索的过程。文档必须落盘，才能被搜索。

默认的落盘间隔是一秒，由参数refresh_interval指定。如果将此参数改为半分钟甚至更大，则能极大的增加ES的吞吐量：

每次落盘，ES都会创建一个新的段（segment ）。

设置更多的分片，插入数据的并发度更高：

字段数据（Field Data ）反转倒排索引。如果你需要知道某个字段包含哪些值，则ES需要反转字段的倒排索引，并产生字段数据。

字段数据存放在堆中，不加任何限制可能充满整个堆。参数indices.fielddata.cache.size用于控制字段数据的内存用量，可以指定百分比或者绝对值。

如果写入量非常大，则需要保证内存中的索引缓冲足够大，对应的参数是indices.memory.index_buffer_size。可以设置高达512MB/分片。

ES 6.x的查询缓存使用LRU算法清除，其内存用量通过indices.queries.cache.size配置。 

批量请求比针对单个文档的请求性能要好很多。批次的最佳大小需要基准测试才能得出。

可以使用多个客户端并发的进行批量请求，单线程往往不能用尽ES的吞吐能力。

交换分区会导致严重的性能下降。

在进行IO操作时，需要使用文件系统缓存。你应该保证有一半的ES节点内存用于文件系统缓存。