Elasticsearch 基本原理和概念（四）

柔情只为你懂 2022-12-13 04:59 421阅读 0赞

今天和大家分析es基本原理和概念：

从上面的例子中，我们看到了很多熟悉又陌生的概念，比如索引、文档等等。这些概念 和我们平时看到的数据库里的比如索引有什么区别呢？

举个例子，现在我们要保存唐宋诗词，数据库中我们们会怎么设计？诗词表 我们可能的设计如下：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25hbmRhbzE1OA_size_16_color_FFFFFF_t_70][]

要根据朝代或者作者寻找诗，都很简单，比如“ select  诗词全文  from  诗词表 where 作者 = ‘李白’”，如果数据很多，查询速度很慢，怎么办？我们可以在对应的查询字段上建立索引加速查询。 但是如果我们现在有个需求：要求找到包含“望”字的诗词怎么办？用

“ select  诗词全文  from  诗词表  where  诗词全文  like ‘ % 望 % ’”，这个意味着 要扫描库中的诗词全文字段，逐条比对，找出所有包含关键词“望”字的记录。 基本上，数据库中一般的 SQL  优化手段都是用不上的。数量少，大概性能还能接 受，如果数据量稍微大点，就完全无法接受了，更何况在互联网这种海量数据的 情况下呢？

怎么解决这个问题呢，用倒排索引。

**倒排索引**  **Inverted index**

比如现在有：

*蜀道难（唐）李白 蜀道之难难于上青天，侧身西望长咨嗟。*

*静夜思（唐）李白 举头望明月，低头思故乡。*

*春台望（唐）李隆基 暇景属三春，高台聊四望。*

*鹤冲天* *(* *宋* *)* *柳永 黄金榜上，偶失龙头望。明代暂遗贤，如何向？未遂风云便，*

*争不恣狂荡。何须论得丧？才子词人，自是白衣卿相。烟花巷陌，依约丹青屏障。*

*幸有意中人，堪寻访。且恁偎红翠，风流事，平生畅。青春都一饷。忍把浮名，*

*换了浅斟低唱！*

都有望字，于是我们可以这么保存

![20201010172648156.png][]

如果查哪个诗词中包含上，怎么办，上述的表格可以继续填入新的记录

![20201010172731245.png][]

其实，上述诗词的中每个字都可以作为关键字，然后建立关键字和文档之间 的对应关系，也就是标识关键字被哪些文档包含。

所以，倒排索引就是，将文档中包含的关键字全部提取处理，然后再将关键 字和文档之间的对应关系保存起来，最后再对关键字本身做索引排序。用户在检 索某一个关键字是，先对关键字的索引进行查找，再通过关键字与文档的对应关 系找到所在文档。 在存储在关系型数据库中的数据，需要我们事先分析将数据拆分为不同的字 段，而在 es  这类的存储中，需要应用程序根据规则自动提取关键字，并形成对 应关系。这些预先提取的关键字，在全文检索领域一般被称为 term （词项），文档 的词项提取在 es  中被称为文档分析，这是全文检索很核心的过程，必须要区分 哪些是词项，哪些不是，比如很多场景下，apple  和  apples  是同一个东西，望和 看其实是同一个动作

**Elasticsearch**  **基本概念**

Elasticsearch  中比较关键的基本概念有索引、文档、映射、映射类型、文档字段概念， 为了方便理解，可以和关系数据库中的相关概念进行个比对：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25hbmRhbzE1OA_size_16_color_FFFFFF_t_70 1][]

**Elasticsearch**  **索引**

Elasticsearch  索引是映射类型的容器。一个  Elasticsearch  索引非常像关系型

世界的数据库，是独立的大量文档集合。 当然在底层，肯定用到了倒排索引，最基本的结构就是“keyword ”和“ Posting List”， Posting list  就是一个  int  的数组，存储了所有符合某个  term  的文档  id 。另外，这个倒排索引相比特定词项出现过的文档列表，会包含更多其它信息。 它会保存每一个词项出现过的文档总数， 在对应的文档中一个具体词项出现的 总次数，词项在文档中的顺序，每个文档的长度，所有文档的平均长度等等相关 信息。

**文档**  **(Document)**

文档是  es  中所有可搜索数据的最小单位，比如日志文件中的日志项、一部 电影的具体信息等等。 文档会被序列化 JSON  格式保存到  ElasticSearch  中， JSON  对象由字段组成， 每个字段都有对象的字段类型（字符串，数值，布尔，日期，二进制，范围类型）。 同时每个文档都有一个 Unique ID ，可以自己指定  ID ，或者通过  ElasticSearch  自 动生成。所以严格来说，es 中存储的文档是一种半结构化的数据。

**映射**

映射（ mapping ）定义了每个字段的类型、字段所使用的分词器等。 get /nandao\_index/\_mapping

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25hbmRhbzE1OA_size_16_color_FFFFFF_t_70 2][]

可以显式映射，由我们在索引映射中进行预先定义；也可以动态映射，在添 加文档的时候，由 es  自动添加到索引，这个过程不需要事先在索引进行字段数 据类型匹配等等，es  会自己推断数据类型。 既然说到了字段类型，当然就离不开字段的数据类型了。

**文档字段**

文档中的一个字段  field  就相当于关系型数据库中的一列  column ，那么它肯 定有数据类型，es  提供的数据类型包括至少有：

***数据类型***

**核心数据类型** \#  字符串类型： string ，字符串类还可被分为  text  和  keyword  类型，如果我 们让 es  自动映射数据，那么  es  会把字符串定义为  text ，并且还加了一个  keyword 类型字段。 text 文本数据类型，用于索引全文值的字段。使用文本数据类型的字段，它 们会被分词，在索引之前将字符串转换为单个术语的列表( 倒排索引 ) ，分词过程 允许 ES  搜索每个全文字段中的单个单词。什么情况适合使用  text ，只要不具备 唯一性的字符串一般都可以使用 text 。 keyword，关键字数据类型，用于索引结构化内容的字段。使用  keyword  类 型的字段，其不会被分析，给什么值就原封不动地按照这个值索引，所以关键字 字段只能按其确切值进行搜索。什么情况下使用 keyword ，具有唯一性的字符串，

例如：电子邮件地址、 MAC  地址、身份证号、状态代码 ... 等等。

\#  数字型数据类型： long 、 integer 、 short 、 byte 、 double 、 float

\#  日期类型： date

\#  布尔类型： boolean

**复杂数据类型**

\#  数组：无需专门的数据类型

\#  对象数据类型：单独的  JSON  对象

\#  嵌套数据类型： nested ，关于  JSON  对象的数组

**地理数据类型：**

\#  地理点数据类型

\#  地理形状数据类型

**专门数据类型：**

\# IPv4  数据类型

\#  单词计数数据类型  token\_count

我们结合前面的映射来看看：

**创建一个新的索引** ： put /open-soft

**显式映射**

put /open-soft/_mapping { "properties" : { "corp" : { "type" : "text" },"lang" : { "type" : "text" },"name" : {
    "type" : "text" } } }

**索引或者说入库一个文档** ，注意这个文档的字段，比我们显示映射的字段要多个 star  字段：

put /open-soft/\_doc/1

"name": "Apache Hadoop",

"lang": "Java",

"corp": "Apache",

"stars":200

通过  get /open-soft/\_mapping ，我们可以看到  es  自动帮我们新增了  stars  这 个字段。

**修改映射** ，增加一个新的字段：

put/open-soft/\_mapping\{  
  "properties": \{  
    "year": \{  
      "type": "integer"  
    \}  
  \}  
\}

***数组***

不需要特殊配置，一个字段如果被配置为基本数据类型，就是天生支持数组 类型的。任何字段都可以有 0  个或多个值，但是在一个数组中数据类型必须一样。 比如：

put /open-soft/\_doc/2

"name": \["Apache Activemq","Activemq Artemis"\],

"lang": "Java",

"corp": "Apache",

"stars":\[500,200\]

是没问题的，但是如果：

put /open-soft/\_doc/3

"name": \["Apache Kafka"\],

"lang": "Java",

"corp": "Apache",

"stars":\[500,"kafka"\]

则会出错。

***对象***

JSON  文档是有层次结构的，一个文档可能包含其他文档，如果一个文档包 含其他文档，那么该文档值是对象类型，其数据类型是对象。当然 ElasticSearch 中是没有所谓对象类型的，比如：

put /open-soft/\_doc/object

\{  
  "name": \[  
    "Apache ShardingSphere"  
  \],  
  "lang": "Java",  
  "corp": "JingDong",  
  "stars": 400,  
  "address": \{  
    "city": "BeiJing",  
    "country": "亦庄"  
  \}  
\}

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25hbmRhbzE1OA_size_16_color_FFFFFF_t_70 3][]

对象类型可以在定义索引的映射关系时进行指定。

***多数据类型***

如果说数组允许你使用同一个设置索引多项数据，那么多数据类型允许使用 不同的设置，对同一项数据索引多次。带来的好处就是可以同一文本有多种不同 的索引方式，比如一个字符串类型的字段，可以使用 text  类型做全文检索，使用 keyword 类型做聚合和排序。我们可以看到  es  的动态映射生成的字段类型里， 往往字符串类型都使用了多数据类型。当然，我们一样也可以自己定义：

put /open-soft/\_mapping

\{  
  "properties": \{  
    "name": \{  
      "type": "text",  
      "fields": \{  
        "raw": \{  
          "type": "keyword"  
        \},  
        "length": \{  
          "type": "token\_count",  
          "analyzer": "standard"  
        \}  
      \}  
    \}  
  \}  
\}

在上面的代码里，我们使用 "fields" 就把  name  字段扩充为多字段类型，为 name 新增了两个子字段  raw  和  length ， raw  设置类型为  keyword ， length  设置类 型为 token\_count ，告诉  es  这个字段在保存还需要做词频统计。 通过 fields  字段设置的子字段  raw  和  length ，在我们添加文档时，并不需要 单独设置值，他们 name  共享相同的值，只是  es  会以不同的方式处理字段值。 同样在检索文档的时候，它们也不会显示在结果中，所以它们一般都是在检索中 以查询条件的形式出现，以减少检索时的性能开销。

**字段参数**

在上面的代码里出现了 analyzer 这个词，这是什么？这个叫字段参数，和 type 一样，可以用来对字段进行配置。常用的字段参数和作用如下：

***analyzer***  指定分词器。elasticsearch  是一款支持全文检索的分布式存储系统，对于  text 类型的字段，首先会使用分词器进行分词，然后将分词后的词根一个一个存储在 倒排索引中，后续查询主要是针对词根的搜索。 analyzer 该参数可以在每个查询、每个字段、每个索引中使用，其优先级如 下（越靠前越优先）：

1 、字段上定义的分词器

2 、索引配置中定义的分词器

3 、默认分词器 (standard)

***normalizer***

规范化，主要针对  keyword  类型，在索引该字段或查询字段之前，可以先对 原始数据进行一些简单的处理，然后再将处理后的结果当成一个词根存入倒排索 引中，默认为 null ，比如：

PUT index

\{  
  "settings": \{  
    "analysis": \{  
      "normalizer": \{  
        "my\_normalizer": \{  //1  
          "type": "custom",  
          "char\_filter": \[  
              
          \],  
          "filter": \[  
            "lowercase",  
            "asciifolding"  
          \]  //2  
        \}  
      \}  
    \}  
  \},  
  "mappings": \{  
    "\_doc": \{  
      "properties": \{  
        "foo": \{  
          "type": "keyword",  
          "normalizer": "my\_normalizer"  //3  
        \}  
      \}  
    \}  
  \}  
\}

代码  1 ：首先在  settings  中的  analysis  属性中定义  normalizer 。

代码  2 ：设置标准化过滤器，示例中的处理器为小写、 asciifolding 。

代码  3 ：在定义映射时，如果字段类型为  keyword ，可以使用  normalizer

引用定义好的  normalizer

***boost***

权重值，可以提升在查询时的权重，对查询相关性有直接的影响，其默认值 为 1.0 。其影响范围为词根查询 (team query), 对前缀、范围查询。 5.0  版本后已废 止。

***coerce***

数据不总是我们想要的，由于在转换  JSON body  为真正  JSON  的时候 , 整型数 字 5  有可能会被写成字符串 "5" 或者浮点数  5.0 ，这个参数可以将数值不合法的部 分去除。默认为 true 。 例如：将字符串会被强制转换为整数、浮点数被强制转换为整数。

例如存在如下字段类型：

"number\_one": \{

"type": "integer"

声明  number\_one  字段的类型为数字类型，那是否允许接收“ 6 ”字符串形 式的数据呢？因为在 JSON  中，“ 6 ”用来赋给  int  类型的字段，也是能接受的， 默认 coerce  为  true ，表示允许这种赋值，但如果  coerce  设置为  false ，此时  es 只能接受不带双引号的数字，如果在 coerce=false  时，将“ 6 ”赋值给  number\_one 时会抛出类型不匹配异常。

***copy\_to***

copy\_to  参数允许您创建自定义的 \_all  字段。换句话说，多个字段的值可以 复制到一个字段中。

例如， first\_name  和  last\_name  字段可以复制到  full\_name  字段如下 :

PUT my\_index

\{  
  "mappings": \{  
    "\_doc": \{  
      "properties": \{  
        "first\_name": \{  
          "type": "text",  
          "copy\_to": "full\_name"  
        \},  
        "last\_name": \{  
          "type": "text",  
          "copy\_to": "full\_name"  
        \},  
        "full\_name": \{  
          "type": "text"  
        \}  
      \}  
    \}  
  \}  
\}

表示字段  full\_name  的值来自  first\_name + last\_name 。

关于  copy\_to  重点说明：

1 、字段的复制是原始值。

2 、同一个字段可以复制到多个字段，写法如下：“ copy\_to”: \[ “field\_1”, “field\_2” \]

***doc\_values***

Doc values  的存在是因为倒排索引只对某些操作是高效的。 倒排索引的优 势 在于查找包含某个项的文档，而对于从另外一个方向的相反操作并不高效， 即：确定哪些项是否存在单个文档里，聚合需要这种次级的访问模式。

对于以下倒排索引：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25hbmRhbzE1OA_size_16_color_FFFFFF_t_70 4][]

如果我们想要获得所有包含  brown  的文档的词的完整列表，倒排索引是根据 项来排序的，所以我们首先在词项列表中找到  brown  ，然后扫描所有列，找到包 含  brown  的文档。我们可以快速看到  Doc\_1  和  Doc\_2  包含  brown  这个  token 。 然后，对于聚合部分，我们需要找到  Doc\_1  和  Doc\_2  里所有唯一的词项。 用倒 排索引做这件事情代价很高： 我们会迭代索引里的每个词项并收

集  Doc\_1  和  Doc\_2  列里面  token 。这很慢而且难以扩展：随着词项和文档的数量 增加，执行时间也会增加。 Doc values 通过转置两者间的关系来解决这个问题。倒排索引将词项映射到包 含它们的文档，doc values  将文档映射到它们包含的词项：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25hbmRhbzE1OA_size_16_color_FFFFFF_t_70 5][]

当数据被转置之后，想要收集到  Doc\_1  和  Doc\_2  的唯一  token  会非常容易。获 得每个文档行，获取所有的词项，然后求两个集合的并集。 doc\_values 缺省是  true ，即是开启的，并且只适用于非  text  类型的字段。

***dynamic***

是否允许动态的隐式增加字段。在执行  index api  或更新文档  API  时，对于 \_source 字段中包含一些原先未定义的字段采取的措施，根据  dynamic  的取值， 会进行不同的操作： true，默认值，表示新的字段会加入到类型映射中。 false,新的字段会被忽略，即不会存入 \_souce  字段中，即不会存储新字段， 也无法通过新字段进行查询。 strict，会显示抛出异常，需要新使用

put mapping api  先显示增加字段映射。

***enabled***

是否建立索引，默认情况下为  true ， es  会尝试为你索引所有的字段，但有时 候某些类型的字段，无需建立索引，只是用来存储数据即可。也就是说， ELasticseaech 默认会索引所有的字段， enabled  设为  false  的字段， elasicsearch  会 跳过字段内容，该字段只能从\_source  中获取，但是不可搜。只有映射类型 (type) 和 object  类型的字段可以设置  enabled  属性。

***eager\_global\_ordinals***

表示是否提前加载全局顺序号。 Global ordinals  是一个建立在  doc values  和 fielddata 基础上的数据结构 ,  它为每一个精确词按照字母顺序维护递增的编号。 每一个精确词都有一个独一无二的编号 并且 精确词 A  小于精确词  B  的编号 . Global ordinals 只支持  keyword  和  text  型字段，在  keyword  字段中 ,  默认是启 用的 而在 text  型字段中 只有  fielddata  和相关属性开启的状态下才是可用的。

***fielddata***

为了解决排序与聚合， elasticsearch  提供了  doc\_values  属性来支持列式存储， 但 doc\_values  不支持  text  字段类型。因为  text  字段是需要先分析（分词），会 影响 doc\_values  列式存储的性能。 es 为了支持  text  字段高效排序与聚合，引入了一种新的数据结构 (fielddata) ， 使用内存进行存储。默认构建时机为第一次聚合查询、排序操作时构建，主要存 储倒排索引中的词根与文档的映射关系，聚合，排序操作在内存中执行。因此 fielddata 需要消耗大量的  JVM  堆内存。一旦  fielddata  加载到内存后，它将永久 存在。通常情况下，加载 fielddata  是一个昂贵的操作，故默认情况下， text  字段的 字段默认是不开启 fielddata  机制。在使用  fielddata  之前请慎重考虑为什么要开 启 fielddata 。

***format***

在  JSON  文档中，日期表示为字符串。 Elasticsearch  使用一组预先配置的格式 来识别和解析这些字符串，并将其解析为 long  类型的数值 ( 毫秒 ) ，支持自定义格 式，也有内置格式。

比如：

PUT my\_index

\{  
  "mappings": \{  
    "\_doc": \{  
      "properties": \{  
        "date": \{  
          "type": "date",  
          "format": "yyyy-MM-dd HH:mm:ss"  
        \}  
      \}  
    \}  
  \}  
\}

elasticsearch  为我们内置了大量的格式，如下： epoch\_millis 时间戳，单位，毫秒，范围受限于 Java Long.MIN\_VALUE  和  Long.MAX\_VALUE 。 epoch\_second 时间戳，单位，秒，范围受限于 Java  的限制  Long.MIN\_VALUE  并  Long. MAX\_VALUE 除以  1000 （一秒中的毫秒数）。 date\_optional\_time 或者  strict\_date\_optional\_time 日期必填，时间可选，其支持的格式如下：date-opt-time = date-element \['T' \[time-element\] \[offset\]\]

date-element = std-date-element | ord-date-element | week-date-element

std-date-element = yyyy \['-' MM \['-' dd\]\]

ord-date-element = yyyy \['-' DDD\]

week-date-element = xxxx '-W' ww \['-' e\]

time-element = HH \[minute-element\] | \[fraction\]

minute-element = ':' mm \[second-element\] | \[fraction\]

second-element = ':' ss \[fraction\]

比如 "yyyy-MM-dd" 、 "yyyyMMdd" 、 "yyyyMMddHHmmss" 、

"yyyy-MM-ddTHH:mm:ss" 、 "yyyy-MM-ddTHH:mm:ss.SSS" 、

"yyyy-MM-ddTHH:mm:ss.SSSZ" 格式，不支持常用的 "yyyy-MM-dd HH:mm:ss" 等格式。

注意， "T" 和 "Z" 是固定的字符。

tips ：如果看到“ strict\_ ”前缀的日期格式要求，表示  date\_optional\_time  的 严格级别，这个严格指的是年份、月份、天必须分别以 4  位、 2  位、 2  位表示， 不足两位的话第一位需用 0  补齐。

basic\_date

其格式表达式为 ： yyyyMMdd

basic\_date\_time

其格式表达式为： yyyyMMdd ’ T ’ HHmmss.SSSZ

basic\_date\_time\_no\_millis

其格式表达式为： yyyyMMdd ’ T ’ HHmmssZ

basic\_ordinal\_date

4  位数的年  \+ 3  位 (day of year) ，其格式字符串为  yyyyDDD

basic\_ordinal\_date\_time

其格式字符串为  yyyyDDD ’ T ’ HHmmss.SSSZ

basic\_ordinal\_date\_time\_no\_millis

其格式字符串为  yyyyDDD ’ T ’ HHmmssZ

basic\_time

其格式字符串为  HHmmss.SSSZ

basic\_time\_no\_millis

其格式字符串为  HHmmssZ

basic\_t\_time

其格式字符串为’ T ’ HHmmss.SSSZ

basic\_t\_time\_no\_millis

其格式字符串为’ T ’ HHmmssZ

basic\_week\_date 其格式字符串为  xxxx ’ W ’ wwe ， 4  为年 ，然后用’ W ’ , 2  位  week of year

（所在年里周序号）  1  位  day of week 。

basic\_week\_date\_time

其格式字符串为  xxxx ’ W ’ wwe ’ T ’ HH:mm:ss.SSSZ.

basic\_week\_date\_time\_no\_millis

其格式字符串为  xxxx ’ W ’ wwe ’ T ’ HH:mm:ssZ.

date

其格式字符串为  yyyy-MM-dd

date\_hour

其格式字符串为  yyyy-MM-dd ’ T ’ HH

date\_hour\_minute

其格式字符串为  yyyy-MM-dd ’ T ’ HH:mm

date\_hour\_minute\_second

其格式字符串为  yyyy-MM-dd ’ T ’ HH:mm:ss

date\_hour\_minute\_second\_fraction

其格式字符串为  yyyy-MM-dd ’ T ’ HH:mm:ss.SSS

date\_hour\_minute\_second\_millis

其格式字符串为  yyyy-MM-dd ’ T ’ HH:mm:ss.SSS

date\_time

其格式字符串为  yyyy-MM-dd ’ T ’ HH:mm:ss.SSS

date\_time\_no\_millis

其格式字符串为  yyyy-MM-dd ’ T ’ HH:mm:ss

hour

其格式字符串为  HH

hour\_minute

其格式字符串为  HH:mm

hour\_minute\_second

其格式字符串为  HH:mm:ss

hour\_minute\_second\_fraction

其格式字符串为  HH:mm:ss.SSS

hour\_minute\_second\_millis

其格式字符串为  HH:mm:ss.SSS

ordinal\_date

其格式字符串为  yyyy-DDD, 其中  DDD  为  day of year 。

ordinal\_date\_time

其格式字符串为  yyyy-DDD ‘ T ’ HH:mm:ss.SSSZZ, 其中  DDD  为  day of year 。 ordinal\_date\_time\_no\_millis

其格式字符串为  yyyy-DDD ‘ T ’ HH:mm:ssZZ

time

其格式字符串为  HH:mm:ss.SSSZZ

time\_no\_millis

其格式字符串为  HH:mm:ssZZ

t\_time

其格式字符串为’ T ’ HH:mm:ss.SSSZZ

t\_time\_no\_millis

其格式字符串为’ T ’ HH:mm:ssZZ

week\_date

其格式字符串为  xxxx-'W ’ ww-e,4  位年份， ww  表示  week of year ， e  表示  day

of week 。

week\_date\_time

其格式字符串为  xxxx-'W ’ ww-e ’ T ’ HH:mm:ss.SSSZZ

week\_date\_time\_no\_millis

其格式字符串为  xxxx-'W ’ ww-e ’ T ’ HH:mm:ssZZ

weekyear

其格式字符串为  xxxx

weekyear\_week

其格式字符串为  xxxx-'W ’ ww, 其中  ww  为  week of year 。

weekyear\_week\_day

其格式字符串为  xxxx-'W ’ ww-e, 其中  ww  为  week of year,e  为  day of week 。

year

其格式字符串为  yyyy

year\_month

其格式字符串为  yyyy-MM

year\_month\_day

其格式字符串为  yyyy-MM-dd

***ignore\_above***

ignore\_above  用于指定字段索引和存储的长度最大值，超过最大值的会被忽 略。

***ignore\_malformed***

ignore\_malformed  可以忽略不规则数据，对于  login  字段，有人可能填写的 是 date  类型，也有人填写的是邮件格式。给一个字段索引不合适的数据类型发 生异常，导致整个文档索引失败。如果  ignore\_malformed  参数设为  true ，异常会 被忽略，出异常的字段不会被索引，其它字段正常索引。

***index***

index  属性指定字段是否索引，不索引也就不可搜索，取值可以为  true  或者 false，缺省为  true 。

***index\_options***

index\_options  控制索引时存储哪些信息到倒排索引中，，用于搜索和突出显 示目的。

docs 只存储文档编号

freqs  存储文档编号和词项频率。

positions 文档编号、词项频率、词项的位置被存储 offsets 文档编号、词项频率、词项的位置、词项开始和结束的字符位置都 被存储。

***fields***

fields  可以让同一文本有多种不同的索引方式，比如一个  String  类型的字段， 可以使用 text  类型做全文检索，使用  keyword  类型做聚合和排序。

***norms***

norms  参数用于标准化文档，以便查询时计算文档的相关性。 norms  虽然对 评分有用，但是会消耗较多的磁盘空间，如果不需要对某个字段进行评分，最好 不要开启 norms 。

***null\_value***

一般来说值为  null  的字段不索引也不可以搜索， null\_value  参数可以让值为 null 的字段显式的可索引、可搜索。

PUT my\_index

\{  
  "mappings": \{  
    "my\_type": \{  
      "properties": \{  
        "status\_code": \{  
          "type": "keyword",  
          "null\_value": "NULL"  
        \}  
      \}  
    \}  
  \}  
\}

PUT my\_index/my\_type/1

"status\_code": null

PUT my\_index/my\_type/2

"status\_code": \[\]

GET my\_index/\_search

\{  
  "query": \{  
    "term": \{  
      "status\_code": "NULL"  
    \}  
  \}  
\}

文档  1  可以被搜索到，因为  status\_code  的值为  null ，文档  2  不可以被搜索 到，因为 status\_code  为空数组，但是不是  null 。

***position\_increment\_gap***

文本数组元素之间位置信息添加的额外值。

举例，一个字段的值为数组类型： "names": \[ "John Abraham", "Lincoln Smith"\] 为了区别第一个字段和第二个字段，Abraham  和  Lincoln  在索引中有一个间 距，默认是 100 。例子如下，这是查询” Abraham Lincoln ”是查不到的：

PUT my\_index/groups/1

"names": \[ "John Abraham", "Lincoln Smith"\]

GET my\_index/groups/\_search

\{  
  "query": \{  
    "match\_phrase": \{  
      "names": \{  
        "query": "Abraham Lincoln"  
      \}  
    \}  
  \}  
\}

指定间距大于  10 0  可以查询到：

GET my\_index/groups/\_search

\{  
  "query": \{  
    "match\_phrase": \{  
      "names": \{  
        "query": "Abraham Lincoln",  
        "slop": 101  
      \}  
    \}  
  \}  
\}

想要调整这个值，在  mapping  中通过  position\_increment\_gap  参数指定间距 即可。

***properties***

Object  或者  nested  类型，下面还有嵌套类型，可以通过  properties  参数指定。

比如：

PUT my\_index

\{  
  "mappings": \{  
    "my\_type": \{  
      "properties": \{  
        "manager": \{  
          "properties": \{  
            "age": \{  
              "type": "integer"  
            \},  
            "name": \{  
              "type": "text"  
            \}  
          \}  
        \},  
        "employees": \{  
          "type": "nested",  
          "properties": \{  
            "age": \{  
              "type": "integer"  
            \},  
            "name": \{  
              "type": "text"  
            \}  
          \}  
        \}  
      \}  
    \}  
  \}  
\}

对应的文档结构：

PUT my\_index/my\_type/1

\{  
  "region": "US",  
  "manager": \{  
    "name": "Alice White",  
    "age": 30  
  \},  
  "employees": \[  
    \{  
      "name": "John Smith",  
      "age": 34  
    \},  
    \{  
      "name": "Peter Brown",  
      "age": 26  
    \}  
  \]  
\}

***search\_analyzer***

通常，在索引时和搜索时应用相同的分析器，以确保查询中的术语与反向索 引中的术语具有相同的格式，如果想要在搜索时使用与存储时不同的分词器，则 使用 search\_analyzer  属性指定，通常用于  ES  实现即时搜索 (edge\_ngram) 。

***similarity***

指定相似度算法，其可选值： BM25 当前版本的默认值，使用 BM25  算法。 classic 使用 TF/IDF  算法，曾经是  es,lucene  的默认相似度算法。 boolean 一个简单的布尔相似度，当不需要全文排序时使用，并且分数应该只基于查 询条件是否匹配。布尔相似度为术语提供了一个与它们的查询boost相等的分数。

***store***

默认情况下，字段值被索引以使其可搜索，但它们不存储。这意味着可以查 询字段，但无法检索原始字段值。通常这并不重要。字段值已经是\_source  字段 的一部分，该字段默认存储。如果您只想检索单个字段或几个字段的值，而不是 整个\_source ，那么这可以通过字段过滤上下文  source filting context  来实现。 在某些情况下，存储字段是有意义的。例如，如果您有一个包含标题、日期 和非常大的内容字段的文档，您可能只想检索标题和日期，而不需要从大型 \_source 字段中提取这些字段，可以将标题和日期字段的  store  定义为  ture 。

***term\_vector***

Term vectors  包含分析过程产生的索引词信息，包括 : 索引词列表 每个索引词的位置（或顺序） 索引词在原始字符串中的原始位置中的开始和结束位置的偏移量。 term vectors 会被存储，索引它可以作为一个特使的文档返回。

term\_vector  可取值：

不存储  term\_vector  信息，默认值。

yes

只存储字段中的值。

with\_positions

存储字段中的值与位置信息。

with\_offsets

存储字段中的值、偏移量

with\_positions\_offsets

存储字段中的值、位置、偏移量信息。

**元字段**  **meta-fields**

一个文档根据我们定义的业务字段保存有数据之外，它还包含了元数据字段 (meta-fields ) 。元字段不需要用户定义，在任一文档中都存在，有点类似于数据库 的表结构数据。在名称上有个显著的特征，都是以下划线“\_ ”开头。

我们可以看看： get /open-soft/\_doc/1

大体分为五种类型：身份（标识）元数据、索引元数据、文档元数据、路由 元数据以及其他类型的元数据，当然不是每个文档这些元字段都有的。

***身份（标识）元数据***

\_index: 文档所属索引  ,  自动被索引，可被查询，聚合，排序使用，或者脚 本里访问

\_type ：文档所属类型，自动被索引，可被查询，聚合，排序使用，或者脚

本里访问

\_id ：文档的唯一标识，建索引时候传入 ，不被索引，可通过 \_uid  被查询， 脚本里使用，不能参与聚合或排序

\_uid ：由 \_type  和 \_id  字段组成，自动被索引 ，可被查询，聚合，排序使用， 或者脚本里访问，6.0.0  版本后已废止。

***索引元数据***

\_all ： 自动组合所有的字段值，以空格分割，可以指定分器词索引，但是整 个值不被存储，所以此字段仅仅能被搜索，不能获取到具体的值。6.0.0  版本后 已废止。

\_field\_names ：索引了每个字段的名字，可以包含  null  值，可以通过  exists 查询或 missing  查询方法来校验特定的字段

***文档元数据***

\_source  ： 一个  doc  的原生的  json  数据，不会被索引，用于获取提取字段 值 ，启动此字段，索引体积会变大，如果既想使用此字段又想兼顾索引体积， 可以开启索引压缩。

\_source  是可以被禁用的，不过禁用之后部分功能不再支持，这些功能包括： 部分 update api 、运行时高亮搜索结果 索引重建、修改 mapping  以及分词、索引升级 debug 查询或者聚合语句

索引自动修复

\_size ： 整个 \_source  字段的字节数大小，需要单独安装一个  mapper-size  插 件才能展示。

***路由元数据***

\_routing ： 一个  doc  可以被路由到指定的  shard  上。

***其他***

\_meta ：一般用来存储应用相关的元信息。 例如：

put /open-soft/\_mapping

\{  
  "\_meta": \{  
    "class": "cn.enjoyedu.User",  
    "version": \{  
      "min": "1.0",  
      "max": "1.3"  
    \}  
  \}  
\}

今天 到此结束，下一篇我们详细分析 Elasticsearch  索引和文档的管理

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25hbmRhbzE1OA_size_16_color_FFFFFF_t_70]: /images/20221123/95f773f8d01f46819771f5b2c0a6da08.png
[20201010172648156.png]: /images/20221123/2db497f6b98d4a9f99ce9c9aa2b61b96.png
[20201010172731245.png]: /images/20221123/c113b2dd22b84b0a87a8475423d916e6.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25hbmRhbzE1OA_size_16_color_FFFFFF_t_70 1]: /images/20221123/90e301d5117647afad5d67c379734095.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25hbmRhbzE1OA_size_16_color_FFFFFF_t_70 2]: /images/20221123/e63136996ac6467fae2a244c0ae84992.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25hbmRhbzE1OA_size_16_color_FFFFFF_t_70 3]: /images/20221123/90d8c44f1bfe4d7db1c12474fcf0c401.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25hbmRhbzE1OA_size_16_color_FFFFFF_t_70 4]: /images/20221123/3169b1e78c7d404da75bb3d808bf9162.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L25hbmRhbzE1OA_size_16_color_FFFFFF_t_70 5]: /images/20221123/1896a8e72d5b402bb57e48fb348efdcc.png