【Elasticsearch】为什么文档知识库落地中离不开ES？
【Elasticsearch】为什么文档知识库落地中离不开ES？
- 一·背景概述
- 二·ES概览
- 三·ES核心特性
-
- 倒排索引和正排索引
-
- 倒排索引是什么？
- 倒排索引的创建和检索流程了解么？
- 倒排索引检索流程：
- 倒排索引由什么组成？
- 正排索引呢？
- 倒排索引和正排索引的区别是什么？
- Elasticsearch 可以针对某些地段不做索引吗？
- 分词器(Analyzer)
-
- 分词器有什么用？
- 常用分词器有哪些?
- 分词器由什么组成？
- 四·ES显著优势
-
- 数据类型
-
- Elasticsearch 常见的数据类型有哪些？
- keyword 和 text 有什么区别？
- Elasticsearch 是否有数组类型？
- 可以在 Mapping 中直接修改字段类型吗？
- 什么是 Nested 数据类型？有什么用？
- 将多个字段值合并为一个字段怎么做？
- Mapping（映射）
-
- 什么是 Mapping?
- 为什么插入数据不用指定 Mapping？
- 想要某个字段不被索引怎么做？
- Canal 增量数据同步 Elasticsearch 的原理了解吗？
- Elasticsearch 和 MySQL 同步的策略有哪些？
- Canal 增量数据同步 Elasticsearch 的原理了解吗？
- Elasticsearch 集群
-
- Elasticsearch 集群是什么？有什么用？
- Elasticsearch 集群中的节点角色有哪些？
- 分片是什么？有什么用？
- 整个 Elasticsearch 集群的核心就是对所有的分片执行分布存储，索引，负载，路由的工作。
- 从 Elasticsearch 版本 7 开始，每个索引的主分片数量的默认值为 1，默认的副本分片数为 0。在早期版本中，默认值为 5 个主分片。在生产环境中，副本分片数至少为 1。
- 查询文档时如何找到对应的分片？
- 自定义路由有什么好处？
- 如何查看 Elasticsearch 集群健康状态？
- Elasticsearch 集群健康状态有哪几种？
- 如何分析 Elasticsearch 集群异常问题？
- 性能优化
-
- Elasticsearch 如何选择硬件配置？
- Elasticsearch 索引优化策略有哪些？
- Elasticsearch 查询优化策略有哪些？
- 我是杰叔叔，一名沪漂的码农，下期再会！
一·背景概述
在开发公司私有文档知识库时，发现文档搜索基本离不开ES，奇了怪了，ES到底有哪些牛的不行的特性？被那么多公司采用，下面我们来唠唠。
二·ES概览
Elasticsearch是一个分布式的、开源的、实时的搜索和分析引擎，基于Apache Lucene构建，旨在提供快速、可扩展、高性能的搜索解决方案。
Lucene又是个啥玩意呢？
Lucene 是一个 Java 语言编写的高性能、全功能的文本搜索引擎库，提供强大的索引和搜索功能，以及拼写检查、高亮显示和高级分析功能。
Lucene看起来挺牛逼的啊，还要ES干嘛？
如果我们直接基于 Lucene 开发，会非常复杂。并且，Lucene 并没有分布式以及高可用的解决方案。像ElasticSearch 就是基于 Lucene 开发的，封装了许多 Lucene 底层功能，提供了简单易用的 RestFul API接口和多种语言的客户端，开箱即用，自带分布式以及高可用的解决方案。
非要用ES吗？MySQL 和 Oracle不是咱也用的6的飞起？
一、性能特点
Elasticsearch
- 分布式架构：能够将数据分布在多个节点上，实现并行处理查询请求，从而显著提高查询的吞吐量和响应速度。
- 倒排索引：使用倒排索引技术，允许快速检索，特别适用于全文搜索等场景。
- 内存优化：通过将索引数据加载到内存中，减少磁盘I/O的需求，实现低延迟和高吞吐量。
- 缓存机制：利用缓存来进一步加速查询，对于重复的查询请求，可以直接从缓存中返回结果，提高查询效率。
- 并行处理：支持并行化查询和分片操作，使得查询请求可以在多个节点上并行执行，提高查询效率。
MySQL
- 高效读写：采用B+树索引，在磁盘上可以快速查找数据，同时支持缓存机制，减少了数据的I/O操作，从而提高了数据的读写效率。
- 高效插入删除：采用MVCC机制，在并发环境中能够高效地进行数据的插入和删除，并且不会对其他操作造成影响。
- 高效更新：能够快速地定位需要更新的数据，同时支持缓存机制，能够减少数据的I/O操作，提高了数据的更新效率。
- 并发性好：支持高并发访问，能够在多用户同时访问时保持较高的性能。
二、适用场景
Elasticsearch
适合需要高性能全文搜索、实时数据分析、日志处理等场景。例如，电商网站的商品搜索、社交媒体平台的内容推荐等。
MySQL
适合需要强事务支持或复杂JOIN操作的场景。例如，金融系统的交易处理、用户管理系统等。
三、优缺点
Elasticsearch
- 优点：高性能的全文搜索和分析能力；可扩展性强，可以轻松扩展到多个节点；实时索引和搜索数据；提供了简单易用的API和丰富的查询语言。
- 缺点：数据安全性相对较弱，需要额外的配置和控制来保护数据的安全；在处理大数据时需要消耗大量的计算资源，对硬件要求较高；学习和使用难度较高，需要掌握复杂的查询语法和配置参数；集群管理复杂，需要用户具有一定的技术能力。
MySQL
- 优点：开源免费，降低了企业的IT成本；拥有庞大的开发者社区，提供了技术支持、插件、第三方工具以及丰富的文档和教程；高效处理大量数据和高并发请求；资源消耗相对较低，有助于降低企业的运营成本；安装配置简单直观；提供了多种图形化管理工具；支持多种编程语言和工具无缝集成；提供了丰富的安全功能，确保数据在传输和存储过程中的安全性。
- 缺点：对于存储非常大的数据的地方，效率较低；没有良好的开发和调试工具；不支持SQL检查约束；处理交易的效率较低，容易出现数据损坏；难以扩展，不支持自动分片，需要手动维护节点；存储过程较弱；安装与MySQL一致的数据库集群非常困难。
三·ES核心特性
倒排索引和正排索引
倒排索引是什么？
倒排索引 也被称作反向索引（inverted index），是用于提高数据检索速度的一种数据结构，空间消耗比较大。倒排索引首先将检索文档进行分词得到多个词语/词条，然后将词语和文档 ID 建立关联，从而提高检索效率。
倒排索引的创建和检索流程了解么？
- 建立文档列表，每个文档都有一个唯一的文档 ID 与之对应。
- 通过分词器对文档进行分词，生成类似于 <词语，文档ID> 的一组组数据。
- 将词语作为索引关键字，记录下词语和文档的对应关系，也就是哪些文档中包含了该词语。
倒排索引检索流程：
- 根据分词查找对应文档 ID
- 根据文档 ID 找到文档
倒排索引由什么组成？
- 单词字典 ：用于存储单词列表。一般用 B+Tree 或 Hash 拉链法存储，提高查询效率。
- 倒排列表 ：记录单词对应的文档集合。分为：
DocID：即文档 id
TF : 单词出现频率，简称词频
Position：单词在文档中出现的位置，用于检索
Offset：偏移量，记录单词开始结束位置，用于高亮显示
正排索引呢？
不同于倒排索引，正排索引将文档 ID 和分词建立关联。
根据词语查询时，必须先逐条获取每个文档，然后判断文档中是否包含所需要的词语，查询效率较低。
倒排索引和正排索引的区别是什么？
正排索引：
- 优点：维护成本低，新增数据的时候，只要在末尾新增一个 ID
- 缺点：以 DocID 为索引，查询时需要扫描所有词语，一个一个比较，直至查到关键词，查询效率
较低。
倒排索引：
- 优点：建立分词和 DocID 关系，大大提高查询效率
- 缺点：建立倒排索引的成本高。并且，维护起来也比较麻烦，因为文档的每次更新都意味着倒排索引的重建。还有一些搜索精度的问题，比如搜索dogs 和 dog 想要相同匹配结果，这时就需要合适的分词器了
Elasticsearch 可以针对某些地段不做索引吗？
文档会被序列化为字段组成的 JSON 格式保存在 ES 中。我们可以针对某些地段不做索引。
这样可以节省存储空间，但是，同时也会让字段无法被搜索。
分词器(Analyzer)
分词器有什么用？
分词器是搜索引擎的一个核心组件，负责对文档内容进行分词(在 ES 里面被称为 Analysis)，也就是将一个文档转换成 单词词典（Term Dictionary） 。单词词典是由文档中出现过的所有单词构成的字符串集合。为了满足不同的分词需求，分词器有很多种，不同的分词器分词逻辑可能会不一样。
常用分词器有哪些?
非中文分词器：
- Standard Analyzer：标准分词器，也是默认分词器， 英文转换成小写， 中文只支持单字切分。
- Simple Analyzer：简单分词器，通过非字母字符来分割文本信息，英文大写转小写，非英文不进行分词。
- Stop Analyzer ：在 SimpleAnalyzer 基础上去除 the，a，is 等词，也就是加入了停用词。
- Whitespace Analyzer : 空格分词器，通过空格来分割文本信息，非英文不进行分词。
中文分词器：
- IK Analyzer（推荐）： 最常用的开源中文分词器，包括两种分词模式：
ik_max_word：细粒度切分模式，会将文本做最细粒度的拆分，尽可能多的拆分出词语
ik_smart：智能模式，会做最粗粒度的拆分 - Ansj ：基于 n-Gram+CRF+HMM 的中文分词的 Java 实现，分词速度达到每秒钟大约 200 万字左右（mac air 下测试），准确率能达到 96%以上。实现了中文分词、中文姓名识别、用户自定义词典、关键字提取、自动摘要、关键字标记等功能。
- ICU Analyzer：提供 Unicode 支持，更好地支持亚洲语言。
- THULAC（THU Lexical Analyzer for Chinese） ： 清华大学推出的一套中文词法分析工具包，具有中文分词和词性标注功能。
- Jcseg ：基于 mmseg 算法的一个轻量级中文分词器，同时集成了关键字提取，关键短语提取，关键句子提取和文章自动摘要等功能。
分词器由什么组成？
分析器由三种组件组成：
Charater Filters：处理原始文本，例如去除 HTMl 标签。
Tokenizer：按分词器规则切分单词。
Token Filters：对切分后的单词加工，包括转小写，切除停用词，添加近义词
三者顺序：Character Filters —> Tokenizer —> Token Filter
三者个数：CharFilters（0 个或多个） + Tokenizer(一个) + TokenFilters(0 个或多个)
下图是默认分词器 Standard Analyzer 的
四·ES显著优势
数据类型
Elasticsearch 常见的数据类型有哪些？
常见类型：
关键词： keyword 、 constant_keyword ，和 wildcard
数值型： long , integer , short , byte , double , float , half_float , scaled_float
布尔型： boolean
日期型： date , date_nanos
二进制： binary
结构化数据类型：
范围型： integer_range , float_range , long_range , double_range , date_range
ip 地址类型 ： ip
软件版本 ： version
文字搜索类型：
非结构化文本 ： text
包含特殊标记的文本： annotated-text
自动完成建议： completion
对象和关系类型：
嵌套类型： nested 、 join
对象类型 ： object 、 flattened
空间类型：
地理坐标类型 ： geo_point
地理形状类型 ：
keyword 和 text 有什么区别？
keyword 不走分词器，而 text 会走分词器，使用 keyword 关键字查询效率更高，一般在 fields 中定
义 keyword 类型字段
Elasticsearch 是否有数组类型？
在 Elasticsearch 中，没有专门的数组数据类型。默认情况下，任何字段都可以包含零个或多个值，但是，数组中的所有值必须具有相同的数据类型。
可以在 Mapping 中直接修改字段类型吗？
不可以！Elasticsearch 中的 Mapping 有点类似于数据库中的表结构定义，Mapping 中的字段类型只能增加不能修改，否则只能 reindex 重新索引或者重新进行数据建模并导入数据。
什么是 Nested 数据类型？有什么用？
Elasticsearch 官方文档是这样介绍 Nested 数据类型的：
The nested type is a specialised version of the object data type that allows arrays of objects
to be indexed in a way that they can be queried independently of each other.
Nested （嵌套）类型是对象数据类型的特殊版本，它允许对象数组以一种可以相互独立查询的方式进行索引。Nested 数据类型可以避免 数组扁平化处理，多个数组的字段会做一个笛卡尔积，导致查询出不存在的数据。
将多个字段值合并为一个字段怎么做？
使用 copy_to ，比如将 first_name 和 last_name 合并为 full_name ，但 full_name 不在查询结果中展示
Mapping（映射）
什么是 Mapping?
Mapping（映射）定义字段名称、数据类型、优化信息（比如是否索引)、分词器，有点类似于数据库中的表结构定义。一个 Index 对应一个 Mapping。
为什么插入数据不用指定 Mapping？
因为在写入文档时，如果索引不存在，Elasticsearch 会自动根据数据类型 自动推断 Mapping 信息Dynamic Mapping），但有时候不是很准确。
想要某个字段不被索引怎么做？
在 Mapping 中设置属性 index = false ，则该字段不可作为检索条件，但结果中还是包含该字段与此相关的属性还有 index_options 可以控制倒排索引记录内容，属性有：
docs : 只包括 docID
freqs : 包括 docID/词频
options ：默认属性，docID/词频/
Canal 增量数据同步 Elasticsearch 的原理了解吗？
这个在 Canal 官方文档中有详细介绍到，原理非常简单：
- Canal 模拟 MySQL Slave 节点与 MySQL Master 节点的交互协议，把自己伪装成一个 MySQL
Slave 节点，向 MySQL Master 节点请求 binlog； - MySQL Master 节点接收到请求之后，根据偏移量将新的 binlog 发送给 MySQL Slave 节点；
- Canal 接收到 binlog 之后，就可以对这部分日志进行解析，获取主库的结构及数据变更。
Elasticsearch 和 MySQL 同步的策略有哪些？
我们可以将同步类型分为 全量同步和增量同步。
- 全量同步即建好 Elasticsearch 索引后一次性导入 MySQL 所有数据。全量同步有很多现成的工具可以用比如go-mysql-elasticsearch、Datax另外，除了插件之外，像我们比较熟悉的 Canal 除了支持 binlog 实时增量同步 数据库之外也支持全量同步 。
- 增量同步即对 MySQL 中新增，修改，删除的数据进行同步:
同步双写 ： 修改数据时同步到 Elasticsearch。这种方式性能较差、存在丢数据风险且会耦合大量数据同步代码，一般不会使用。
异步双写 ： 修改数据时，使用 MQ 异步写入 Elasticsearch 提高效率。这种方式引入了新的组件和服务，增加了系统整体复杂性。
定时器 ： 定时同步数据到 Elasticsearch。这种方式时效性差，通常用于数据实时性不高的场景binlog 同步组件 Canal(推荐) ： 使用 Canal 可以做到业务代码完全解耦，API 完全解耦，零代码实现准实时同步, Canal 通过解析 MySQL 的 binlog 日志文件进行数据同步。
Canal 增量数据同步 Elasticsearch 的原理了解吗？
这个在 Canal 官方文档中有详细介绍到，原理非常简单：
- Canal 模拟 MySQL Slave 节点与 MySQL Master 节点的交互协议，把自己伪装成一个 MySQL
Slave 节点，向 MySQL Master 节点请求 binlog； - MySQL Master 节点接收到请求之后，根据偏移量将新的 binlog 发送给 MySQL Slave 节点；
- Canal接收到 binlog 之后，就可以对这部分日志进行解析，获取主库的结构及数据变更
Elasticsearch 集群
Elasticsearch 集群是什么？有什么用？
单台 Elasticsearch 服务器负载能力和存储能力有限，很多时候通过增加服务器配置也没办法满足我们的要求。并且，单个 Elasticsearch 节点会存在单点风险，没有做到高可用。为此，我们需要搭建Elasticsearch 集群。
Elasticsearch 集群说白了就是多个 Elasticsearch 节点的集合，这些节点共同协作，一起提供服务，这样就可以解决单台 Elasticsearch 服务器无法处理的搜索需求和数据存储需求。出于高可用方面的考虑，集群中节点数量建议 3 个以上，并且其中至少两个节点不是仅投票主节点.
Elasticsearch 集群可以很方便地实现横向扩展，我们可以动态添加或者删除 Elasticsearch节点，当有
节点加入集群中或者从集群中移除节点时，集群将会重新平均分布所有的数据。
Elasticsearch 集群中的节点角色有哪些？
Elasticsearch 7.9 之前的版本中的节点类型：数据节点、协调节点、候选主节点、ingest 节点。在Elasticsearch 7.9 以及之后，节点类型升级为节点角色（Node roles）。
节点角色分的很细：数据节点角色、主节点角色、ingest 节点角色、热节点角色等。
节点角色主要是为了解决基于节点类型配置复杂和用户体验差的问题。
Elasticsearch 集群一般是由多个节点共同组成的分布式集群，节点之间互通，彼此配合，共同对外提供搜索和索引服务（节点之间能够将客户端请求转向到合适的节点）。
不同的节点会负责不同的角色，有的负责一个，有的可能负责多个。
在 ES 中我们可以通过配置使一个节点有以下一个或多个角色：
- 主节点（Master-eligible node） ：集群层面的管理，例如创建或删除索引、跟踪哪些节点是集群的一部分，以及决定将哪些分片分配给哪些节点。任何不是仅投票主节点的合格主节点都可以通过主选举过程被选为主节点。
- 专用备选主节点（Dedicated master-eligible node） ： Elasticsearch 集群中，设置了只
能作为主节点的节点。设置专用主节点主要是为了保障集群增大时的稳定性，建议专用主节点个数至少为 3 个。 - 仅投票主节点（Voting-only master-eligible node）: 仅参与主节点选举投票，不会被选为
主节点，硬件配置可以较低。 - 数据节点（data node） ：数据存储和数据处理比如 CRUD、搜索、聚合。
- 预处理节点（ingest node） ：执行由预处理管道组成的预处理任务。
- 仅协调节点（coordinating only node） ：路由分发请求、聚集搜索或聚合结果。
- 远程节点（Remote-eligible node） ：跨集群检索或跨集群复制。
…
高可用性 (HA) 集群需要至少三个符合主节点条件的节点，其中至少两个节点不是仅投票主节点。即使其中一个节点发生故障，这样的集群也能够选举出一个主节点。
分片是什么？有什么用？
分片（Shard） 是集群数据的容器，Index（索引）被分为多个文档碎片存储在分片中，分片又被分配到集群内的各个节点里。当需要查询一个文档时，需要先找到其位于的分片。也就是说，分片是Elasticsearch 在集群内分发数据的单位。每个分片都是一个 Lucene 索引实例，您可以将其视作一个独立的搜索引擎，它能够对 Elasticsearch 集群中的数据子集进行索引并处理相关查询。
整个 Elasticsearch 集群的核心就是对所有的分片执行分布存储，索引，负载，路由的工作。
当集群规模扩大或者缩小时， Elasticsearch 会自动的在各节点中迁移分片，使得数据仍然均匀分布在集群里。Elasticsearch 在对数据进行再平衡时移动分片的速度取决于分片的大小和数量，以及网络和磁盘性能。
一个分片可以是 主分片（Primary Shard） 或者 副本分片（Replica Shard） 。一个副本分片只是一个主分片的拷贝。副本分片作为硬件故障时保护数据不丢失的冗余备份，并为搜索和返回文档等读操作提供服务。查询吞吐量可以随着副本分片数量的增加而增长，与此同时，使用分片副本还可以处理查询的发并量。
当我们写索引数据的时候，只能写在主分片上，然后再同步到副本分片。
当主分片出现问题的时候，会从可用的副本分片中选举一个新的主分片。在默认情况下，ElasticSearch会为主分片创建一个副本分片。由于副本分片同样会占用资源，因此，不建议为一个主分片分配过多的副本分片，应该充分结合业务需求来选定副本分片的数量。
从 Elasticsearch 版本 7 开始，每个索引的主分片数量的默认值为 1，默认的副本分片数为 0。在早期版本中，默认值为 5 个主分片。在生产环境中，副本分片数至少为 1。
最后，简单总结一下：
分片是 Elasticsearch 在集群内分发数据的单位。整个 Elasticsearch 集群的核心就是对所有的分片执行分布存储，索引，负载，路由的工作。副本分片主要是为了提高可用性，由于副本分片同样会占用资源，不建议为一个主分片分配过多的副本分片。当我们写索引数据的时候，只能写在主分片上，然后再同步到副本分片。当主分片出现问题的时候，会从可用的副本分片中选举一个新的主分片。
查询文档时如何找到对应的分片？
我们需要查询一个文档的时候，需要先找到其位于那一个分片中。那究竟是如何知道一个文档应该存放在哪个分片中呢?
这个过程是根据路由公式来决定的:
routing 是一个可以配置的变量,默认是使用文档的 id。对 routing 取哈希再除以
number_of_primary_shards (索引创建时指定的分片总数)得到的余数就是对应的分片。
当一个查询请求到达 仅协调节点（coordinating only node） 后，仅协调节点会根据路由公式计算出目标分片，然后再将请求转发到目标分片的主分片节点上。上面公式也解释了为什么我们要在创建索引的时候就确定好主分片的数量，并且不允许改变索引分片数。因为如果数量变
自定义路由有什么好处？
默认的路由规则会尽量保证数据会均匀地保存到每一个分片上面。
这样做的好处是，一旦某个分片出了故障，ES 集群里的任何索引都不会出现一个文档都查不到的情况，所有索引都只会丢失故障分片上面存储的文档而已，这个给修复故障分片争取了时间。
不过，这种路由规则也有一个弊端，文档均匀分配到多个分片上面了，所以每次查询索引结果都需要向多个分片发送请求，然后再将这些分片返回的结果融合到一起返回到终端。
很显然这样一来系统的压力就会增大很多，如果索引数据量不大的情况下，效率会非常差。
如果我们想要让某一类型的文档都被存储到同一分片的话，可以自定义路由规则。所有的文档 API 请求(get,index,delete,bulk,update)都接受一个叫做 routing 的路由参数，通过这个参数我们可以自定义文档到数据分片的映射规则。
如何查看 Elasticsearch 集群健康状态？
在 Kibana 控制台执行以下命令可以查看集群的健康状态：
GET /_cluster/health
返回参数及其含义：
Elasticsearch 集群健康状态有哪几种？
Elasticsearch 集群健康状态分为三种：
GREEN （健康状态）：最健康的状态，集群中的主分片和副本分片都可用。
YELLOW （预警状态）：主分片都可用，但存在副本分片不可能。
RED （异常状态）：存在不可用的主分片，搜索结果可能会不完整。
如何分析 Elasticsearch 集群异常问题？
- 1、找到异常索引
GET /_cat/indices?v&health=yellow
GET /_cat/indices?v&health=red - 2、查看详细的异常信息
GET /_cluster/allocation/explain
GET /_cluster/allocation/explai?pretty - 3、通过异常信息进一步分析问题的原因。
性能优化
Elasticsearch 如何选择硬件配置？
- 部署 Elasticsearch 对于机器的 CPU 要求并不高，通常选择 2 核或者 4 核的就差不多了。
- Elasticsearch 中的很多操作是比较消耗内存的，如果搜索需求比较大的话，建议选择 16GB 以上的内存。具体如何分配内存呢？通常是 50% 给 ES，50% 留给 Lucene。另外，建议禁止 swap。如果不禁止的话，当内存耗尽时，操作系统就会自动把内存中暂时不使用的数据交换到硬盘中，需要使用的时候再从硬盘交换到内存，频繁硬盘操作对性能影响是致命的。磁盘的速度相对比较慢，尽量使用固态硬盘（SSD）。
Elasticsearch 索引优化策略有哪些？
- ES 提供了 Bulk API 支持批量操作，当我们有大量的写任务时，可以使用 Bulk 来进行批量写入。不过，使用 Bulk 请求时，每个请求尽量不要超过几十 M，因为太大会导致内存使用过大。
- ES 默认副本数量为 3 个，这样可以提高可用性，但会影响写入索引的效率。某些业务场景下，可以设置副本数量为 1 或者 0，提高写入索引的效率。
- ES 在写入数据的时候，采用延迟写入的策略，默认 1 秒之后将内存中 segment 数据刷新到磁盘中，此时我们才能将数据搜索出来。这就是为什么 Elasticsearch 提供的是近实时搜索功能。
- 使用 ES 的默认 ID 生成策略或使用数字类型 ID 做为主键。
- 合理的配置使用 index 属性， analyzed 和 not_analyzed ，根据业务需求来控制字段是否分词或不分词。只有 groupby 需求的字段，配置时就设置成 not_analyzed ，以提高查询或聚类的效率。
Elasticsearch 查询优化策略有哪些？
- 建立冷热索引库（可用固态硬盘存放热库数据，普通硬盘存放冷库数据）
- 热库数据可以提前预热加载至内存，提高检索效率。
- 自定义路由规则，让某一类型的文档都被存储到同一分片。
- 使用 copy_to 将多个字段整合为一个。
- 控制字段的数量，业务中不使用的字段，就不要索引。
- 不要返回无用的字段，使用 _source 进行指定。
- 避免大型文档存储，默认最大长度为 100MB。
- 使用 keyword 数据类型，该类型不会走分词器，效率大大提高。
- 开启慢查询配置定位慢查询。
- ES 查询的时候，使用 filter 查询会使用 query cache, 如果业务场景中的过滤查询比较多，建议将querycache 设置大一些，以提高查询速度。
- 尽量避免分页过深。
- 增加分片副本提高查询吞吐量，避免使用通配符。
…
