性能调优是系统架构里所有组件必不可少的话题，Elasticsearch也不例外，虽说Elasticsearch内的默认配置已经非常优秀，但这不表示它就是完美的，必要的一些实践我们还是需要了解一下。

索引是我们使用Elasticsearch里最频繁的部分日常的操作都与索引有关，本篇从运维人员的视角，来玩一玩Elasticsearch的索引操作。

生产环境中运行的组件，只要有数据存储，定时备份、灾难恢复是必修课，mysql数据库的备份方案已经非常成熟，Elasticsearch也同样有成熟的数据备份、恢复方案，我们来了解一下。

如果我们的Elasticsearch集群做了一些离线的维护操作时，如扩容磁盘，升级版本等，需要对集群进行启动，节点数较多时，从第一个节点开始启动，到最后一个节点启动完成，耗时可能较长，有时候还可能出现某几个节点因故障无法启动，排查问题、修复故障后才能加入到集群中，此时集群会干什么呢？

我们从开始编程就接触过各种各样的组件，而每种功能的组件，对硬件要求的特性都不太相同，有的需要很强的CPU计算能力，有的对内存需求量大，有的对网卡要求高等待，下面我们讨论一下ES集群对几种硬件的特性需求。

前面历经33篇内容的讲解，与ES的请求操作都是在Kibana平台上用Restful请求完成的，一直没发布Java或python的客户端代码，Restful才是运用、理解ES核心功能最直接的表达方式，但实际项目中肯定是以Java/python来完成ES请求的发起与数据处理的，前面理解了ES的核心功能，后面Java API的使用将会非常简单，剩余的未覆盖的功...

搜索模板search tempalte高级功能之一，可以将我们的一些搜索进行模板化，使用现有模板时传入指定的参数就可以了，避免编写重复代码。对常用的功能可以利用模板进行封装，使用时更简便。

每次有document数据插入时，elasticsearch除了对document进行正排、倒排索引的存储之外，如果此索引的field设置了term_vector参数，elasticsearch还会对这个的分词信息进行计算、统计，比如这个document有多少个field，每个field的值分词处理后得到的term的df值，ttf值是多少，每个term存储的位置偏移量等信息，这些统计...

Elasticsearch在文档更新时默认使用的是乐观锁方案，而Elasticsearch利用文档的一些create限制条件，也能达到悲观锁的效果，我们一起来看一看。

本篇以实际案例为背景，介绍不同技术组件对数据建模的特点，并以ES为背景，介绍常用的联合查询的利弊，最后介绍了一下文件系统分词器path_hierarchy和嵌套对象的使用。

本篇主要介绍聚合查询的内部原理，正排索引是如何建立的和优化的，fielddata的使用，最后简单介绍了聚合分析时如何选用深度优先和广度优先。

上一篇我们演练的聚合算法，在Elasticsearch分布式场景下，其实是有略微区别的，简单来说我们可以把这些聚合算法分成两类，易并行算法和不易并行算法。

数据分组，一些数据按照某个字段进行bucket划分，这个字段值相同的数据放到一个bucket中。可以理解成Java中的Map<String, List<Object>>结构，类似于Mysql中的group by后的查询结果。

前面的案例使用standard、english分词器，是英文原生的分词器，对中文分词支持不太好。中文作为全球最优美、最复杂的语言，目前中文分词器较多，ik-analyzer、结巴中文分词、THULAC、NLPIR和阿里的aliws都是非常优秀的，我们以ik-analyzer作为讲解的重点，其它分词器可以举一反三。

我们在前面了解的搜索，词条是最小的匹配单位，也是倒排索引中存在的词，现在我们来聊聊部分匹配的话题，只匹配一个词条中的一部分内容，相当于mysql的"where content like '%love%'"，在数据库里一眼就能发现这种查询是不走索引的，效率非常低。

前面的match查询只能告诉我们，搜索的文档里有这些关键词，但无法告知词语之间的顺序，而不同的词语顺序表达的意思可能完全相反。我们想要的，是跟我们期望搜索的语义要相似，这就需要短语匹配和近似匹配来控制了。

bool查询采取"more-matches-is-better"匹配越多分越高的方式，所以每条match语句的评分结果会被加在一起，从而为每个文档提供最终的分数_score。能与两条语句同时匹配的文档会比只与一条语句匹配的文档得分要高，但有时这样也会带来一些与期望不符合的情况，我们举个例子：

概要 本篇介绍怎样在全文字段中搜索到最相关的文档，包含手动控制搜索的精准度，搜索条件权重控制。 手动控制搜索的精准度 搜索的两个重要维度：相关性(Relevance)和分析(Analysis)。 相关性是评价查询条件与结果的相关程度，并对相关程度进行排序，一般使用TF/IDF方法。 分析是指将索引文档与查询条件规范化的一个过程...

结构化搜索针对日期、时间、数字等结构化数据的搜索，它们有自己的格式，我们可以对它们进行范围，比较大小等逻辑操作，这些逻辑操作得到的结果非黑即白，要么符合条件在结果集里，要么不符合条件在结果集之外，没有那种相似的概念。

概要 本篇我们来看看shard内部的一些操作原理，了解一下人家是怎么玩的。 倒排索引 倒排索引的结构，是非常适合用来做搜索的，Elasticsearch会为索引的每个index为analyzed的字段建立倒排索引。 基本结构 倒排索引包含以下几个部分： 某个关键词的doc list 某个关键词的所有doc的数量IDF（inverse document frequency） ...

我们使用Elasticsearch索引文档时，最理想的情况是文档JSON结构是确定的，数据源源不断地灌进来即可，但实际情况中，没人能够阻拦需求的变更，在项目的某个版本，可能会对原有的文档结构造成冲击，增加新的字段还好，如果要修改原有的字段，只能重建索引了。

Elasticsearch让索引创建变得非常简单，只要索引一条新的数据，索引会自动创建出来，但随着数据量的增加，我们开始有了索引优化和搜索优化的需求之后，就会发现自动创建的索引在某些方面不能非常完美的适应我们的需求，我们开始考虑手动创建适合我们业务需求的索引。

但搜索比CRUD复杂，符合搜索条件的文档，可能散落在各个node、各个shard中，我们需要找到匹配的文档，并且把从各个node，各个shard返回的结果进行汇总、排序，组成一个最终的结果排序列表，才算完成一个搜索过程。我们将按两阶段的方式对这个过程进行讲解。

Elasticsearch进行全文搜索时，Boolean Model是匹配的基础，先用boolean model将匹配的文档挑选出来，然后再运用评分函数计算相关度，参与的函数如我们提到的TF/IDF、Length Norm等，再加上一些控制权重的参数设置，得到最后的评分。

HTTP协议，GET请求带body是不规范的做法，但由于ES搜索的复杂性，加上HTTP协议GET/POST方法表述的语义，GET更适合用来表述查询的动作，虽然不规范，但还是这么用了。现在大多数浏览器也支持GET+request body，如果遇到不支持的，换成POST即可。了解一下就行，不用太慌张。

上一篇文章介绍的都是Elasticsearch的自动mapping，我们在创建索引时，可以先指定好mapping的信息，还是以music索引为例：

前面几篇的实战案例，我们向Elasticsearch索引数据时，只是简单地把JSON文本放在请求体里，至于JSON里的field类型，存储到ES里是什么类型，中间是怎么做的映射，这个映射过程，就是mapping要解决的问题。

倒排索引是搜索引擎中常见的索引方法，用来存储在全文搜索下某个单词在一个文档中存储位置的映射。通过倒排索引，我们输入一个关键词，可以非常快地获取包含这个关键词的文档列表。

本篇从介绍搜索分页为起点，简单阐述分页式数据搜索与原有集中式数据搜索思维方式的差异，就分页问题对deep paging问题的现象进行分析，最后介绍分页式系统top N的案例。

概要 本篇主要介绍搜索的报文结构含义、搜索超时时间的处理过程，提及了一下多索引搜索和轻量搜索，最后将精确搜索与全文搜索做了简单的对比。 空搜索 搜索API最简单的形式是不指定索引和类型的空搜索，它将返回集群下所有索引的所有文档（默认显示10条）： GET /_search 响应的结果示例(有筛选，只取了一条document作为...