Elasticsearch分布式搜索引擎入门总结

1. 性能低下
2. 没有相关性排名 - 刚需
3. 无法全文搜索
4. 搜索不准确 - 没有分词

生活中的数据总体分为两种：结构化数据和非结构化数据。

• 结构化数据：指具有固定格式或有限长度的数据，如数据库，元数据等。
• 非结构化数据：指不定长或无固定格式的数据，如邮件，word文档等。

非结构化数据又一种叫法叫全文数据。
按照数据的分类，搜索也分为两种：

• 对结构化数据的搜索：如对数据库的搜索，用SQL语句。再如对元数据的搜索，如利用windows搜索对文件名，类型，修改时间进行搜索等。
• 对非结构化数据的搜索：如利用windows的搜索也可以搜索文件内容，Linux下的grep命令，再如用Google和百度可以搜索大量内容数据。

对非结构化数据也即对全文数据的搜索主要有两种方法：
顺序扫描法(Serial Scanning)：

比如要找内容包含某一个字符串的文件，就是一个文档一个文档的看，对于每一个文档，从头看到尾，如果此文档包含此字符串，则此文档为要找的文件，接着看下一个文件，直到扫描完所有的文件。如利用windows的搜索也可以搜索文件内容，只是相当的慢。假如有一个80G硬盘，如果想在上面找到一个内容包含某字符串的文件，可能需要几个小时的时间。Linux下的grep命令也是这一种方式。这是一种比较原始的方法，但对于小数据量的文件，这种方法还是最直接，最方便的。但是对于大量的文件，这种方法的速度就很慢。
全文检索(Full-text Search)：

即先建立索引，再对索引进行搜索。索引是从非结构化数据中提取出之后重新组织的信息。

Elasticsearch 是一个分布式可扩展的实时搜索和分析引擎,一个建立在全文搜索引擎 Apache Lucene™ 基础上的搜索引擎.当然 Elasticsearch 并不仅仅是 Lucene 那么简单，它不仅包括了全文搜索功能，还可以进行以下工作:

• 分布式实时文件存储，并将每一个字段都编入索引，使其可以被搜索。
• 实时分析的分布式搜索引擎。
• 可以扩展到上百台服务器，处理PB级别的结构化或非结构化数据。

• 维基百科
• The Guardian、新闻
• Stack Overflow
• Github
• 电商网站、检索商品
• 日志数据分析、logstash采集日志、ES进行复杂的数据分析(ELK)
• 商品价格监控网站、用户设定价格阈值
• BI系统、商业智能、ES执行数据分析和挖掘

1. 可以作为一个大型的分布式集群(数百台服务器)技术，处理PB级数据，服务大公司，可以运行在单机上，服务小公司。
2. ES不是什么新技术，主要是将全文检索、数据分析以及分布式技术合并在一起，才形成了独一无二的ES.lucene（全文检索）、商用的数据分析软件、分布式数据库 (mycat)
3. 对用户而言，是开箱即用，非常简单，作为中小型的应用，直接3分钟部署ES，就可以作为生产环境的系统使用，数据量不大，操作不是很复杂。
4. 数据库的功能面对很多领域是不够用的(事务，还有各种联机事务的操作)：特殊的功能，比如全文检索、同义词处理、相关度排名、复杂数据分析、海量数据近实时处理；ES作为传统数据库的一个补充，提供了数据库所不能提供的很多功能。

1.索引 **
有两个含义： 动词(insert) , 名词(表)
Elasticsearch将它的数据存储到一个或者多个索引(index)中，索引就像数据库**，可以向索引写入文档或者从索引中读取文档。

2.文档
文档(document)是Elasticsearch中的主要实体。所以，所有使用Elasticsearch最终都会归结到文档的搜索上
从客户端看，文档就是一个JSON对象，文档由字段构成，每个字段包含字段名以及一个或多个字段值。文档之间可能有各自不同的字段集合，文档没有固定的模式或强制的结构。

3.类型(7.x开始取消)
Elasticsearch中每个文档都有与之对应的类型(type)定义，允许在一个索引存储多种文档类型，并提供不同映射。
类型就像一个数据库表
4.映射
映射做的就是，存储分析链所需的信息。
主要就是设置一些参数，根据这些参数来做过滤还是分割词条。

官方文档

在customer下保存id为1的数据, 这里id是必须的

同一个请求发送多次，下面的信息会产生变化

关于 _version和_seq_no的区别和作用参考官方文档

如果post带id就和put一样的操作了， put是不允许不带id的

没有就创建，有就报错

只返回source的值

Elasticsearch有两种查询方式

请求参数位于_search端点之后，参数之间使用&分割，例如：

搜索API的最基础的形式是没有指定任何查询的空搜索，它简单地返回集群中所有索引下的所有文档。

更新数据
删除数据

此时会发现，已有的数据的name字段没有了，只有age字段，PUT也是同样的问题。
此时需要使用

官方文档

用法

Postman批量插入最后一行一定要空行才行

官方文档

官方文档

from-limit

size-offset

对于es来说，from和size分页在数据量比较小的情况下可行，反之使用scroll

1. match查询（匹配查询）

文档
：模糊匹配，需要指定字段名，但是输入会进行分词，比如"hello world"会进行拆分为hello和world，然后匹配，如果字段中包含hello或者world，或者都包含的结果都会被查询出来，也就是说match是一个部分匹配的模糊查询。查询条件相对来说比较宽松。大小写不敏感，分词中满足其中一个词

2. match_phrase查询 短语查询

官方文档
：会对输入做分词，但是需要结果中也包含所有的分词，而且顺序要求一样。以"hello world"为例，要求结果中必须包含hello和world，而且还要求他们是连着的，顺序也是固定的，hello that word不满足，world hello也不满足条件。大小写不敏感，分词必须满足短句条件

3. multi_match查询

官方文档
查询提供了一个简便的方法用来对多个字段执行相同的查询，即对指定的多个字段进行match查询

4、query_string查询

官方文档
：和match的方式类似，但是match需要指定字段名，query_string是在所有字段中搜索，范围更广泛，很灵活。

查询所有的数据

官方文档

1、term查询

: 这种查询和match在有些时候是等价的，比如查询单个的词hello，那么会和match查询结果一样，但是如果查询"hello world"，结果就相差很大，因为这个输入不会进行分词，就是说查询的时候，是查询字段分词结果中是否有"hello world"的字样，而不是查询字段中包含"hello world"的字样，elasticsearch会对字段内容进行分词，“hello world"会被分成hello和world，不存在"hello world”，因此这里的查询结果会为空。这也是term查询和match的区别。

term是原子查询，不会做分词操作

"boost": 1.0 //设置权重

2、range查询 - 范围查询

3、exists查询

查询某个字段是否存在的数据

4、fuzzy模糊查询

编辑距离

5、复合查询

官方文档
Elasticsearch bool查询对应Lucene BooleanQuery, 格式如下

bool查询采用了一种匹配越多越好的方法，因此每个匹配的must或should子句的分数将被加在一起，以提供每个文档的最终得分

官方文档

Mapping 类似于数据库中的表结构定义 schema，它有以下几个作用：
定义索引中的字段的名称定义字段的数据类型，比如字符串、数字、布尔字段，倒排索引的相关配置，比如设置某个字段为不被索引、记录 position 等在 ES 早期版本，一个索引下是可以有多个 Type ，从 7.0 开始，一个索引只有一个 Type，也可以说一个 Type 有一个 Mapping 定义。

比如一个新的文档，这个文档包含一个字段，当 Dynamic 设置为 true 时，这个文档可以被索引进 ES，这个字段也可以被索引，也就是这个字段可以被搜索，Mapping 也同时被更新；当 dynamic 被设置为 false 时候，存在新增字段的数据写入，该数据可以被索引，但是新增字段被丢弃；当设置成 strict 模式时候，数据写入直接出错。
另外还有 index 参数，用来控制当前字段是否被索引，默认为 true，如果设为 false，则该字段不可被搜索。
参数 index_options 用于控制倒排索引记录的内容，有如下 4 种配置：
doc：只记录 doc id
freqs：记录 doc id 和 term frequencies
positions：记录 doc id、term frequencies 和 term position
offsets：记录 doc id、term frequencies、term position 和 character offects

另外，text 类型默认配置为 positions，其他类型默认为 doc，记录内容越多，占用存储空间越大。

null_value 主要是当字段遇到 null 值时的处理策略，默认为 NULL，即空值，此时 ES 会默认忽略该值，可以通过设定该值设定字段的默认值，另外只有 KeyWord 类型支持设定 null_value。

copy_to 作用是将该字段的值复制到目标字段，实现类似 _all 的作用，它不会出现在 _source 中，只用来搜索。
除了上述介绍的参数，还有许多参数，大家感兴趣的可以在官方文档中进行查看。

从图中可以看出核心类型可以划分为字符串类型、数字类型、日期类型、布尔类型、基于 BASE64 的二进制类型、范围类型。

其中，在 ES 7.x 有两种字符串类型：text 和 keyword，在 ES 5.x 之后 string 类型已经不再支持了。

text 类型适用于需要被全文检索的字段，例如新闻正文、邮件内容等比较长的文字，text 类型会被 Lucene 分词器（Analyzer）处理为一个个词项，并使用 Lucene 倒排索引存储，text 字段不能被用于排序，如果需要使用该类型的字段只需要在定义映射时指定 JSON 中对应字段的 type 为 text。
keyword 适合简短、结构化字符串，例如主机名、姓名、商品名称等，可以用于过滤、排序、聚合检索，也可以用于精确查询。

数字类型分为 long、integer、short、byte、double、float、half_float、scaled_float。
数字类型的字段在满足需求的前提下应当尽量选择范围较小的数据类型，字段长度越短，搜索效率越高，对于浮点数，可以优先考虑使用 scaled_float 类型，该类型可以通过缩放因子来精确浮点数，例如 12.34 可以转换为 1234 来存储。

在 ES 中日期可以为以下形式：

格式化的日期字符串，例如 2020-03-17 00:00、2020/03/17
时间戳（和 1970-01-01 00:00:00 UTC 的差值），单位毫秒或者秒即使是格式化的日期字符串，ES 底层依然采用的是时间戳的形式存储。

JSON 文档中同样存在布尔类型，不过 JSON 字符串类型也可以被 ES 转换为布尔类型存储，前提是字符串的取值为 true 或者 false，布尔类型常用于检索中的过滤条件。

二进制类型 binary 接受 BASE64 编码的字符串，默认 store 属性为 false，并且不可以被搜索。

范围类型可以用来表达一个数据的区间，可以分为5种：
integer_range、float_range、long_range、double_range 以及 date_range。

复合类型主要有对象类型（object）和嵌套类型（nested）：

可以看出转换后的 JSON 文档中 first 和 last 的关联丢失了，如果尝试搜索 first 为 wu，last 为 xy 的文档，那么成功会检索出上述文档，但是 wu 和 xy 在原 JSON 文档中并不属于同一个 JSON 对象，应当是不匹配的，即检索不出任何结果。
嵌套类型就是为了解决这种问题的，嵌套类型将数组中的每个 JSON 对象作为独立的隐藏文档来存储，每个嵌套的对象都能够独立地被搜索，所以上述案例中虽然表面上只有 1 个文档，但实际上是存储了 4 个文档。

地理类型字段分为两种：经纬度类型和地理区域类型：

经纬度类型字段（geo_point）可以存储经纬度相关信息，通过地理类型的字段，可以用来实现诸如查找在指定地理区域内相关的文档、根据距离排序、根据地理位置修改评分规则等需求。

经纬度类型可以表达一个点，而 geo_shape 类型可以表达一块地理区域，区域的形状可以是任意多边形，也可以是点、线、面、多点、多线、多面等几何类型。

特殊类型包括 IP 类型、过滤器类型、Join 类型、别名类型等，在这里简单介绍下 IP 类型和 Join 类型，其他特殊类型可以查看官方文档。

Dynamic Mapping 机制不需要手动定义 Mapping，ES 会自动根据文档信息来判断字段合适的类型，但是有时候也会推算的不对，比如地理位置信息有可能会判断为 Text，当类型如果设置不对时，会导致一些功能无法正常工作，比如 Range 查询。

可以从结果中看出，ES 会根据文档信息自动推算出合适的类型。
哦豁，万一想修改 Mapping 的字段类型，能否更改呢？分以下两种情况来探究下：

如果是新增加的字段，根据 Dynamic 的设置分为以下三种状况：

当 Dynamic 设置为 true 时，一旦有新增字段的文档写入，Mapping 也同时被更新。
当 Dynamic 设置为 false 时，索引的 Mapping 是不会被更新的，新增字段的数据无法被索引，也就是无法被搜索，但是信息会出现在 _source 中。
当 Dynamic 设置为 strict 时，文档写入会失败。

另外一种是字段已经存在，这种情况下，ES 是不允许修改字段的类型的，因为 ES 是根据 Lucene 实现的倒排索引，一旦生成后就不允许修改，如果希望改变字段类型，必须使用 Reindex API 重建索引。
不能修改的原因是如果修改了字段的数据类型，会导致已被索引的无法被搜索，但是如果是增加新的字段，就不会有这样的影响。

官方文档

Elasticsearch 中文本分析Analysis是把全文本转换成一系列的单词(term/token）的过程，也叫分词。文本分析是使用分析器 Analyzer 来实现的，Elasticsearch内置了分析器，用户也可以按照自己的需求自定义分析器。
为了提高搜索准确性，除了在数据写入时转换词条，匹配 Query 语句时候也需要用相同的分析器对查询语句进行分析。

Analyzer 由三部分组成：Character Filters、Tokenizer、Token Filters

Character Filters字符过滤器接收原始文本text的字符流，可以对原始文本增加、删除字段或者对字符做转换。一个Analyzer 分析器可以有 0-n 个按顺序执行的字符过滤器。

Tokenizer 分词器接收Character Filters输出的字符流，将字符流分解成的那个的单词，并且输出单词流。例如空格分词器会将文本按照空格分解，将 “Quick brown fox!” 转换成 [Quick, brown, fox!]。分词器也负责记录每个单词的顺序和该单词在原始文本中的起始和结束偏移 offsets 。
一个Analyzer 分析器有且只有 1个分词器。

一个Analyzer 分析器可以有 0-n 个按顺序执行的单词过滤器。

Standard Analyzer - 默认分词器，按词切分，小写处理
Simple Analyzer - 按照非字母切分（符号被过滤），小写处理
Stop Analyzer - 小写处理，停用词过滤（the ，a，is）
Whitespace Analyzer - 按照空格切分，不转小写
Keyword Analyzer - 不分词，直接将输入当做输出
Patter Analyzer - 正则表达式，默认 W+
Language - 提供了 30 多种常见语言的分词器

例子：The 2 QUICK Brown-Foxes jumped over the lazy dog’s bone.

• 默认分词器
• 按词分类
• 小写处理

输出：
[the,2,quick,brown,foxes,a,jumped,over,the,lazy,dog’s,bone]

• 按照非字母切分，非字母则会被去除
• 小写处理

输出：
[the,quick,brown,foxes,jumped,over,the,lazy,dog,s,bone]

• 小写处理
• 停用词过滤（the，a, is)

输出：
[quick,brown,foxes,jumped,over,lazy,dog,s,bone]

• 按空格切分

输出：
[The,2,QUICK,Brown-Foxes,jumped,over,the,lazy,dog’s,bone.]

• 不分词，当成一整个 term 输出

输出：
[The 2 QUICK Brown-Foxes jumped over the lazy dog’s bone.]

• 通过正则表达式进行分词
• 默认是 W+(非字母进行分隔)

输出：
[the,2,quick,brown,foxes,jumped,over,the,lazy,dog,s,bone]

支持语言：arabic, armenian, basque, bengali, bulgarian, catalan, czech, dutch, english, finnish, french, galician, german, hindi, hungarian, indonesian, irish, italian, latvian, lithuanian, norwegian, portuguese, romanian, russian, sorani, spanish, swedish, turkish.

输出：
[2,quick,brown,fox,jump,over,the,lazy,dog,bone]

中文分词要比英文分词难，英文都以空格分隔，中文理解通常需要上下文理解才能有正确的理解，比如 [苹果，不大好吃]和
[苹果，不大，好吃]，这两句意思就不一样。

IK Analyzer - 对中文分词友好，支持远程词典热更新，有ik_smart 、ik_max_word 两种分析器
pinyin Analyzer - 可以对中文进行拼音分析，搜索时使用拼音即可搜索出来对应中文
ICU Analyzer - 提供了 Unicode 的支持，更好的支持亚洲语言
hanLP Analyzer - 基于NLP的中文分析器

单词是语言中重要的基本元素。一个单词可以代表一个信息单元，有着指代名称、功能、动作、性质等作用。在语言的进化史中，不断有新的单词涌现，也有许多单词随着时代的变迁而边缘化直至消失。根据统计，《汉语词典》中包含的汉语单词数目在37万左右，《牛津英语词典》中的词汇约有17万。

理解单词对于分析语言结构和语义具有重要的作用。因此，在机器阅读理解算法中，模型通常需要首先对语句和文本进行单词分拆和解析。

分词（tokenization）的任务是将文本以单词为基本单元进行划分。由于许多词语存在词型的重叠，以及组合词的运用，解决歧义性是分词任务中的一个挑战。不同的分拆方式可能表示完全不同的语义。如在以下例子中，两种分拆方式代表的语义都有可能：

英文有天然的空格作为分隔符，但是中文没有。所以如何切分是一个难点，再加上中文里一词多意的情况非常多，导致很容易出现歧义。下文中难点部分会详细说明。

英文单词存在丰富的变形变换。为了应对这些复杂的变换，英文NLP相比中文存在一些独特的处理步骤，称为词形还原（Lemmatization）和词干提取（Stemming）。中文则不需要
词性还原：does，done，doing，did 需要通过词性还原恢复成 do。
词干提取：cities，children，teeth 这些词，需要转换为 city，child，tooth”这些基本形态

例如「中国科学技术大学」就有很多种分法：

• 中国科学技术大学
• 中国 科学技术 大学
• 中国 科学 技术 大学

粒度越大，表达的意思就越准确，但是也会导致召回比较少。所以中文需要不同的场景和要求选择不同的粒度。这个在英文中是没有的。

难点 1：没有统一的标准

目前中文分词没有统一的标准，也没有公认的规范。不同的公司和组织各有各的方法和规则。

难点 2：歧义词如何切分

例如「兵乓球拍卖完了」就有2种分词方式表达了2种不同的含义：

• 乒乓球 拍卖 完了
• 乒乓 球拍 卖 完了

难点 3：新词的识别

信息爆炸的时代，三天两头就会冒出来一堆新词，如何快速的识别出这些新词是一大难点。比如当年「蓝瘦香菇」大火，就需要快速识别。

分词的方法大致分为 3 类：

1. 基于词典匹配
2. 基于统计
3. 基于深度学习

给予词典匹配的分词方式
优点：速度快、成本低
缺点：适应性不强，不同领域效果差异大
基本思想是基于词典匹配，将待分词的中文文本根据一定规则切分和调整，然后跟词典中的词语进行匹配，匹配成功则按照词典的词分词，匹配失败通过调整或者重新选择，如此反复循环即可。代表方法有基于正向最大匹配和基于逆向最大匹配及双向匹配法。
基于统计的分词方法
优点：适应性较强
缺点：成本较高，速度较慢
这类目前常用的是算法是 **HMM、CRF、SVM、深度学习 **等算法，比如stanford、Hanlp分词工具是基于CRF算法。以CRF为例，基本思路是对汉字进行标注训练，不仅考虑了词语出现的频率，还考虑上下文，具备较好的学习能力，因此其对歧义词和未登录词的识别都具有良好的效果。
基于深度学习
优点：准确率高、适应性强
缺点：成本高，速度慢
例如有人员尝试使用双向LSTM+CRF实现分词器，其本质上是序列标注，所以有通用性，命名实体识别等都可以使用该模型，据报道其分词器字符准确率可高达97.5%。
常见的分词器都是使用机器学习算法和词典相结合，一方面能够提高分词准确率，另一方面能够改善领域适应性。

下面排名根据 GitHub 上的 star 数排名：

1. jieba
2. Hanlp
3. IK
4. Stanford 分词
5. ansj 分词器
6. 哈工大 LTP
7. KCWS分词器
8. 清华大学THULAC
9. ICTCLAS

1. Keras
2. Spacy
3. Gensim
4. NLTK

分词就是将句子、段落、文章这种长文本，分解为以字词为单位的数据结构，方便后续的处理分析工作。
分词的原因：

1. 将复杂问题转化为数学问题
2. 词是一个比较合适的粒度
3. 深度学习时代，部分任务中也可以「分字」

中英文分词的3个典型区别：

1. 分词方式不同，中文更难
2. 英文单词有多种形态，需要词性还原和词干提取
3. 中文分词需要考虑粒度问题

中文分词的3大难点

1. 没有统一的标准
2. 歧义词如何切分
3. 新词的识别

3个典型的分词方式：

1. 基于词典匹配
2. 基于统计
3. 基于深度学习

下载地址
下载的版本一定要和es的版本保持一致

将目录文件夹改名为ik

docker restart xxxx

ik_smart 和 ik_max_word

重启docker

Elasticsearch 是一个分布式可扩展的实时搜索和分析引擎,一个建立在全文搜索引擎 Apache Lucene™ 基础上的搜索引擎.当然 Elasticsearch 并不仅仅是 Lucene 那么简单，它不仅包括了全文搜索功能，还可以进行以下工作:

• 分布式实时文件存储，并将每一个字段都编入索引，使其可以被搜索。
• 实时分析的分布式搜索引擎。
• 可以扩展到上百台服务器，处理PB级别的结构化或非结构化数据。

先说Elasticsearch的文件存储，Elasticsearch是面向文档型数据库，一条数据在这里就是一个文档，用JSON作为文档序列化的格式，比如下面这条用户数据：

用Mysql这样的数据库存储就会容易想到建立一张User表，有balabala的字段等，在Elasticsearch里这就是一个_文档_，当然这个文档会属于一个User的_类型_，各种各样的类型存在于一个_索引_当中。这里有一份简易的将Elasticsearch和关系型数据术语对照表:

一个 Elasticsearch 集群可以包含多个索引(数据库)，也就是说其中包含了很多类型(表)。这些类型中包含了很多的文档(行)，然后每个文档中又包含了很多的字段(列)。Elasticsearch的交互，可以使用Java API，也可以直接使用HTTP的Restful API方式，比如打算插入一条记录，可以简单发送一个HTTP的请求：

更新，查询也是类似这样的操作，具体操作手册可以参见Elasticsearch权威指南

Elasticsearch最关键的就是提供强大的索引能力了，其实InfoQ的这篇时间序列数据库的秘密(2)——索引写的非常好，我这里也是围绕这篇结合自己的理解进一步梳理下，也希望可以帮助大家更好的理解这篇文章。
Elasticsearch索引的精髓：

一切设计都是为了提高搜索的性能

另一层意思：为了提高搜索的性能，难免会牺牲某些其他方面，比如插入/更新，否则其他数据库不用混了。前面看到往Elasticsearch里插入一条记录，其实就是直接PUT一个json的对象，这个对象有多个fields，比如上面例子中的_name, sex, age, about, interests_，那么在插入这些数据到Elasticsearch的同时，Elasticsearch还默默1的为这些字段建立索引–倒排索引，因为Elasticsearch最核心功能是搜索。

InfoQ那篇文章里说Elasticsearch使用的倒排索引比关系型数据库的B-Tree索引快，为什么呢？

什么是B-Tree索引?

为了提高查询的效率，减少磁盘寻道次数，将多个值作为一个数组通过连续区间存放，一次寻道读取多个数据，同时也降低树的高度。

什么是倒排索引?

继续上面的例子，假设有这么几条数据(为了简单，去掉about, interests这两个field):

ID是Elasticsearch自建的文档id，那么Elasticsearch建立的索引如下:
Name:

Age:

Sex:

Posting List

Elasticsearch分别为每个field都建立了一个倒排索引，Kate, John, 24, Female这些叫term，而[1,2]就是Posting List。Posting list就是一个int的数组，存储了所有符合某个term的文档id。
看到这里，不要认为就结束了，精彩的部分才刚开始…
通过posting list这种索引方式似乎可以很快进行查找，比如要找age=24的同学，爱回答问题的小明马上就举手回答：我知道，id是1，2的同学。但是，如果这里有上千万的记录呢？如果是想通过name来查找呢？

Term Dictionary

Elasticsearch为了能快速找到某个term，将所有的term排个序，二分法查找term，logN的查找效率，就像通过字典查找一样，这就是Term Dictionary。现在再看起来，似乎和传统数据库通过B-Tree的方式类似啊，为什么说比B-Tree的查询快呢？

Term Index

所以term index不需要存下所有的term，而仅仅是他们的一些前缀与Term Dictionary的block之间的映射关系，再结合FST(Finite State Transducers)的压缩技术，可以使term index缓存到内存中。从term index查到对应的term dictionary的block位置之后，再去磁盘上找term，大大减少了磁盘随机读的次数。
这时候爱提问的小明又举手了:"那个FST是神马东东啊?"
一看就知道小明是一个上大学读书的时候跟我一样不认真听课的孩子，数据结构老师一定讲过什么是FST。但没办法，我也忘了，这里再补下课：

FSTs are finite-state machines that map a term (byte sequence) to an arbitrary output.

⭕️表示一种状态
–>表示状态的变化过程，上面的字母/数字表示状态变化和权重
将单词分成单个字母通过⭕️和–>表示出来，0权重不显示。如果⭕️后面出现分支，就标记权重，最后整条路径上的权重加起来就是这个单词对应的序号。

FSTs are finite-state machines that map a term (byte sequence) to an arbitrary output.

FST以字节的方式存储所有的term，这种压缩方式可以有效的缩减存储空间，使得term index足以放进内存，但这种方式也会导致查找时需要更多的CPU资源。

压缩技巧

Elasticsearch里除了上面说到用FST压缩term index外，对posting list也有压缩技巧。
小明喝完咖啡又举手了:"posting list不是已经只存储文档id了吗？还需要压缩？"
嗯，再看最开始的例子，如果Elasticsearch需要对同学的性别进行索引(这时传统关系型数据库已经哭晕在厕所……)，会怎样？如果有上千万个同学，而世界上只有男/女这样两个性别，每个posting list都会有至少百万个文档id。Elasticsearch是如何有效的对这些文档id压缩的呢？

Frame Of Reference

增量编码压缩，将大数变小数，按字节存储

如果数学不是体育老师教的话，还是比较容易看出来这种压缩技巧的。
未压缩之前，6个整数，每个整数用4个字节压缩，一共需要24个字节；通过将数据增量编码，将73，300，302…，变成73, 227, 2，没有丢掉数据信息的情况下，将数据减小。标识位8，本身需要一个字节空间，表示73,227,2每个数都用8bit = 1byte来存储，需要1byte * 3 = 3bytes内存空间来存储，标识位5，本身需要1个字节空间存储，表示30，11，29都用5bit来存储，5bit * 3 = 15bit，但是需要16bit = 2bytes来存储，那么8，73,227,2，5，30，11，29,一共需要1 + 3 + 1 + 2 = 7bytes空间即可。
原理就是通过增量，将原来的大数变成小数仅存储增量值，再精打细算按bit排好队，最后通过字节存储，而不是大大咧咧的尽管是2也是用int(4个字节)来存储。

Roaring bitmaps

说到Roaring bitmaps，就必须先从bitmap说起。Bitmap是一种数据结构，假设有某个posting list：
[1,3,4,7,10]
对应的bitmap就是：
[1,0,1,1,0,0,1,0,0,1]
非常直观，用0/1表示某个值是否存在，比如10这个值就对应第10位，对应的bit值是1，这样用一个字节就可以代表8个文档id，旧版本(5.0之前)的Lucene就是用这样的方式来压缩的，但这样的压缩方式仍然不够高效，如果有1亿个文档，那么需要12.5MB的存储空间，这仅仅是对应一个索引字段(往往会有很多个索引字段)。于是有人想出了Roaring bitmaps这样更高效的数据结构。
Bitmap的缺点是存储空间随着文档个数线性增长，Roaring bitmaps需要打破这个魔咒就一定要用到某些指数特性：

"为什么是以65535为界限?"
程序员的世界里除了1024外，65535也是一个经典值，因为它=2^16-1，正好是用2个字节能表示的最大数，一个short的存储单位，注意到上图里的最后一行“If a block has more than 4096 values, encode as a bit set, and otherwise as a simple array using 2 bytes per value”，如果是大块，用节省点用bitset存，小块就豪爽点，2个字节我也不计较了，用一个short[]存着方便。
那为什么用4096来区分大块还是小块呢？
个人理解：都说程序员的世界是二进制的，4096*2bytes ＝ 8192bytes < 1KB, 磁盘一次寻道可以顺序把一个小块的内容都读出来，再大一位就超过1KB了，需要两次读。

联合索引

上面说了半天都是单field索引，如果多个field索引的联合查询，倒排索引如何满足快速查询的要求呢？

• 利用跳表(Skip list)的数据结构快速做“与”运算，或者
• 利用上面提到的bitset按位“与”

如果使用跳表，对最短的posting list中的每个id，逐个在另外两个posting list中查找看是否存在，最后得到交集的结果。
如果使用bitset，就很直观了，直接按位与，得到的结果就是最后的交集。

Elasticsearch的索引思路:

将磁盘里的东西尽量搬进内存，减少磁盘随机读取次数(同时也利用磁盘顺序读特性)，结合各种奇技淫巧的压缩算法，用及其苛刻的态度使用内存。

所以，对于使用Elasticsearch进行索引时需要注意:

• 不需要索引的字段，一定要明确定义出来，因为默认是自动建索引的
• 同样的道理，对于String类型的字段，不需要analysis的也需要明确定义出来，因为默认也是会analysis的
• 选择有规律的ID很重要，随机性太大的ID(比如java的UUID)不利于查询

关于最后一点，个人认为有多个因素:
其中一个(也许不是最重要的)因素: 上面看到的压缩算法，都是对Posting list里的大量ID进行压缩的，那如果ID是顺序的，或者是有公共前缀等具有一定规律性的ID，压缩比会比较高；

前面是针对单个字段，name,age说明的快速索引解决方案，elastic通常是全文检索，文档类型的，通常需要将文档分词。比如有这样2个文档：

1. The quick brown fox jumped over the lazy dog
2. Quick brown foxes leap over lazy dogs in summer

为了创建倒排索引，首先将每个文档的 content 域拆分成单独的 词（称它为 词条 或 tokens ），创建一个包含所有不重复词条的排序列表，然后列出每个词条出现在哪个文档。结果如下所示：
Term Doc_1 Doc_2-------------------------Quick | | XThe | X |brown | X | Xdog | X |dogs | | Xfox | X |foxes | | Xin | | Xjumped | X |lazy | X | Xleap | | Xover | X | Xquick | X |summer | | Xthe | X |