【烈日炎炎战后端】Elecsticsearch（1.5万字）

超、凢脫俗 2022-11-24 11:27 202阅读 0赞

### Elecsticsearch ###

*   *   *   *  1. Elecsticsearch介绍
             *  2. Elecsticsearch核心概念
             *  3. Elecsticsearch中的倒排索引
             *  4. Elasticsearch分布式搜索引擎架构图
             *  5. Elasticsearch节点自动发现机制
             *  6. Elasticsearch搜索数据过程
             *  7. Elasticsearch写数据的过程
             *  8. Elasticsearch读数据过程
             *  9. Elasticsearch文档的索引更新和删除
             *  10. Elasticsearch如果保证在并发情况下读写一致？
             *  11. Elasticsearch对于大数据量的聚合如何实现？
             *  12. Elasticsearch在海量数据中怎样提高效率
             *  13.Elasticsearch 字段数据类型

#### 1. Elecsticsearch介绍 ####

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

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

**集群分布式底层实现**：ES实际上就是利用分片来实现分布式。分片是数据的容器，文档保存在分片内，分片又被分配到集群内的各个节点里。 当你的集群规模扩大或者缩小时， ES会自动的在各节点中迁移分片，使得数据仍然均匀分布在集群里。在索引建立的时候就已经确定了主分片数，但是副本分片数可以随时修改。默认情况下，一个索引会有5个主分片，而其副本可以有任意数量。

主分片和副本分片的状态决定了集群的健康状态。每一个节点上都只会保存主分片或者其对应的一个副本分片，相同的副本分片不会存在于同一个节点中。如果集群中只有一个节点，则副本分片将不会被分配，此时集群健康状态为yellow，存在丢失数据的风险。

> 1.  **分布式的含义**
> 
> 分布式系统（distributed system）是建立在网络之上的软件系统。正是因为软件的特性，所以分布式系统具有高度的内聚性和透明性。因此，网络和分布式系统之间的区别更多的在于高层软件（特别是操作系统），而不是硬件。
> 
> 1.  **可拓展的含义**
> 
> 可伸缩性(可扩展性)是一种对软件系统计算处理能力的设计指标，高可伸缩性代表一种弹性，在系统扩展成长过程中，软件能够保证旺盛的生命力，通过很少的改动甚至只是硬件设备的添置，就能实现整个系统处理能力的线性增长，实现高吞吐量和低延迟高性能。
> 
> 可伸缩性和纯粹性能调优有本质区别， 可伸缩性是高性能、低成本和可维护性等诸多因素的综合考量和平衡，可伸缩性讲究平滑线性的性能提升，更侧重于系统的水平伸缩，通过廉价的服务器实现分布式计算；而普通性能优化只是单台机器的性能指标优化。他们共同点都是根据应用系统特点在吞吐量和延迟之间进行一个侧重选择，当然水平伸缩分区后会带来[CAP定理][CAP]约束。
> 
> 软件的可扩展性设计非常重要，但又比较难以掌握，业界试图通过云计算或高并发语言等方式节省开发者精力，但是，无论采取什么技术，如果应用系统内部是铁板一块，例如严重依赖数据库，系统达到一定访问规模，负载都集中到一两台数据库服务器上，这时进行分区扩展伸缩就比较困难，正如[Hibernate框架][Hibernate]创建人Gavin King所说：关系数据库是最不可扩展的。
> 
> 1.  **实时搜索**
> 
> 实时搜索（Real Time Search）简而言之就是对互联网上的一些信息进行即时、快速搜索，实现即搜即得的效果。
> 
> 1.  **Lucene（雷森）**
> 
> 它不是一个完整的全文检索引擎，而是一个全文检索引擎的架构，提供了完整的查询引擎和索引引擎，部分[文本分析][Link 1]引擎（英文与德文两种西方语言）。Lucene的目的是为软件开发人员提供一个简单易用的工具包，以方便的在目标系统中实现全文检索的功能，或者是以此为基础建立起完整的全文检索引擎。
> 
> 1.  **Elasticsearch设计理念**
> 
> 一切设计都是为了提高搜索的性能
> 
> 1.  **全文搜索**
> 
> **全文搜索**是指计算机搜索程序通过扫描文章中的每一个词，对每一个词建立一个索引，指明该词在文章中出现的次数和位置，当用户查询时，搜索程序就会根据事先建立的索引进行查找，并将查询结果返回给用户。

#### 2. Elecsticsearch核心概念 ####

**1. 节点（node）**

**一个节点是集群中的一个服务器**，作为集群的一部分，存储数据，参与集群的索引和搜索功能。一个节点也是由一个名字来标识的。默认情况下，这个名字是一个随机的漫威漫画角色的名字，这个名字会在启动的时候赋予节点，这个名字对于管理工作来说挺重要的，因为在这个管理过程中，要确定网络中的哪些服务器对应于Elasticsearch集群中的哪些节点。

**2. 集群（cluster）**

**代表一个集群，集群中有多个节点node**，其中一个为主节点，这个主节点可以通过选举产生的，主节点是对于集群内部来说的。ES的一个概念就是**去中心化**，字面上理解就是无中心化节点，这是对于集群外部来说的，因为从外部来看ES集群，在逻辑上是一个整体，你与任何一个节点的通信和整个ES集群通信是等价的

一个集群就是由一个或者多个节点组织在一起，它们共同持有整个的数据，并在一起提供索引和搜索功能。一个集群由一个唯一的名字标识。一个节点只能通过指定某个集群的名字，来加入这个集群。

> **节点状态**：绿色（健康），黄色（预警），红色（报错）。

**3. 分片（shards）**

**shards代表索引分片**，ES可以把一个完整的索引分成多个分片，这样的好处是可以把一个大的索引拆分成多个，分布到不同的节点上。构成分布式搜索。分片的数量只能在索引创建前指定，并且索引创建后不能更改。  
分片有两个好处，一是可以水平扩展，另一个是可以并发提高性能。

**4. 备份/副本（replicas）**

ES默认为一个索引创建5个主分片, 并分别为其创建一个副本分片. 也就是说每个索引都由5个主分片成本, 而每个主分片都相应的有一个copy.replicas代表索引副本，**副本指的是对主分片的备份**，这种备份是精确复制模式。ES可以设置多个索引副本，副本的作用一是提高系统的容错性，实现高可用（HA），当某个节点某个分片损坏或丢失时可以从副本中恢复；二是提高ES的查询效率，ES会自动对搜索请求进行负载均衡。

**5. 索引（index）**

ES将它的**数据存储在一个或多个索引（index）中**。类似sql中的数据库。可以向索引中写入文档或者读取文档，并通过ES内部使用Lucene将数据索引或从索引中检索数据，一个索引就是一个拥有几分相似特征的文档的集合（类似于我们在数据库中的库结构），一个索引由一个名字来标识，并且在我们要对对这个索引中的文档进行索引，搜索，更新和删除的时候，都要使用到这个名字。

**6. 类型（type）**

每个文档都有与之对应的类型定义。这允许用户在一个索引中存储多种文档类型，并为不同文档类型提供不同的映射

**7. 文档（document）**

文档是ES中主要的实体。对所有使用ES的案例来说，他们最终都可以终结为对文档的搜索。文档由字段构成。

**8. 映射（mapping）**

所有文档写进索引之前都会先进行分析，如果将输入的文本分割为词条，哪些词条又会被过滤，这种行为叫做映射（mapping）。一般由用户自己定义规则。

#### 3. Elecsticsearch中的倒排索引 ####

> [link1][]
> 
> [link2][]

**倒排索引就建立分词与文档之间的映射关系**，在倒排索引之中，**数据时面向分词的而不是面向文档的**.

**在搜索引擎中，每个文档都有一个对应的文档 ID，文档内容被表示为一系列关键词的集合.例如，文档 1 经过分词，提取了 20 个关键词，每个关键词都会记录它在文档中出现的次数和出现位置.**

那么，**倒排索引就是关键词到文档 ID 的映射，每个关键词都对应着一系列的文件，这些文件中都出现了关键词.**

举个栗子.

有以下文档：

![img][]

对文档进行分词之后，得到以下倒排索引.

![img][img 1]

另外，实用的倒排索引还可以记录更多的信息，比如文档频率信息，表示在文档集合中有多少个文档包含某个单词.那么，**有了倒排索引，搜索引擎可以很方便地响应用户的查询.比如用户输入查询 `Facebook`，搜索系统查找倒排索引，从中读出包含这个单词的文档，这些文档就是提供给用户的搜索结果.**

要注意倒排索引的两个重要细节：

*  倒排索引中的所有词项对应一个或多个文档；
 *  倒排索引中的词项根据字典顺序升序排列

上面只是一个简单的栗子，并没有严格按照字典顺序升序排列.

#### 4. Elasticsearch分布式搜索引擎架构图 ####

> https://www.cnblogs.com/ningskyer/articles/5789010.html

![img][img 2]

#### 5. Elasticsearch节点自动发现机制 ####

在Elasticsearch内部，通过在集群中配置一个相同的集群节点。就能将不同节点连接到一个集群，它是如何做到的呢？

Elasticsearch的选主是ZenDiscovery模块负责的，Zen discovery是内建的、默认的、用于Elasticsearch的发现模块。它提供了单播和基于文件的发现，可以通过插件扩展到支持云环境和其他形式的发现。有两种方法可用于配置种子节点列表：**单播**和**基于文件**。建议种子节点列表主要由集群中那些 Master-eligible 的节点组成。

**单播模式：**

节点首先执行ping（节点之间通过这个RPC来发现彼此）命令，ping命令的返回结果是该节点的基本信息和该节点认为的主节点。

**那么ping命令是如何实现选举的呢?**

Elasticsearch的选主是ZenDiscovery模块负责的，主要包含Ping和Unicast（单播模块包含一个主机列表以控制哪些节点需要ping通）这两部分；

对所有可以成为master的节点（node.master: true）根据nodeId字典排序，每次选举每个节点都把自己所知道节点排一次序，然后选出第一个（第0位）节点，暂且认为它是master节点.  
　　如果对某个节点的投票数达到一定的值（可以成为master节点数n/2+1）并且该节点自己也选举自己，那这个节点就是master.否则重新选举一直到满足上述条件。

**为什么节点数是n/2+1？**

Elasticsearch中的节点（比如共20个），其中的10个选了一个master，另外10个选了另一个master，怎么办？

当集群master候选数量不小于3个时，可以通过设置最少投票通过数量（discovery.zen.minimum\_master\_nodes）超过所有候选节点一半以上来解决脑裂问题；  
当候选数量为两个时，只能修改为唯一的一个master候选，其他作为data节点，避免脑裂问题.

> **选举主节点详细解释：**
> 
> 作为 ping 过程的一部分，一个集群的主节点需要是被选举或者加入进来的(即选举主节点也会执行ping，其他的操作也会执行ping)。这个过程是自动执行的。通过配置`discovery.zen.ping_timeout`来控制节点加入某个集群或者开始选举的响应时间(默认3s)。
> 
> 在这段时间内有3个 ping 会发出。如果超时,重新启动 ping 程序。在网络缓慢时，3秒时间可能不够，这种情况下，需要慎重增加超时时间，增加超时时间会减慢选举进程。
> 
> 一旦节点决定加入一个存在的集群，它会发出一个加入请求给主节点，这个请求的超时时间由`discovery.zen.join_time`控制，默认是 ping 超时时间(`discovery.zen.ping_timeout`)的20倍。
> 
> 当主节点停止或者出现问题，集群中的节点会重新 ping 并选举一个新节点。有时一个节点也许会错误的认为主节点已死，所以这种 ping 操作也可以作为部分网络故障的保护性措施。在这种情况下，节点将只从其他节点监听有关当前活动主节点的信息。
> 
> 如果`discovery.zen.master_election.ignore_non_master_pings`设置为`true`时（默认值为`false`），`node.master`为`false`的节点不参加主节点的选举，同时选票也不包含这种节点。
> 
> 通过设置`node.master`为`false`，可以将节点设置为非备选主节点，永远没有机会成为主节点。
> 
> `discovery.zen.minimum_master_nodes`设置了最少有多少个备选主节点参加选举，同时也设置了一个主节点需要控制最少多少个备选主节点才能继续保持主节点身份。如果控制的备选主节点少于`discovery.zen.minimum_master_nodes`个，那么当前主节点下台，重新开始选举。
> 
> `discovery.zen.minimum_master_nodes`必须设置一个恰当的备选主节点值(`quonum`，一般设置 为备选主节点数/2+1)，尽量避免只有两个备选主节点，因为两个备选主节点`quonum`应该为2，那么如果一个节点出现问题，另一个节点的同意人数最多只能为1，永远也不能选举出新的主节点，这时就发生了脑裂现象。

#### 6. Elasticsearch搜索数据过程 ####

es最强大的是做全文检索，搜索过程大体上分为**查询**和**取回**这两个阶段，搜索的底层原理：倒排索引，**查询**阶段通过结果分词得到文档标识符，协调结点在对其进行处理后，再**取回**实际的文档数据。

1.  客户端发送请求到一个coordinate node（协调节点）
2.  协调节点将搜索请求转发到所有的shard（分片）对应的primary shard（主分片）或replica shard（副本分片）也可以。
3.  query phase（查询阶段）：每个shard将自己的搜索结果（其实就是一些doc id（文档标识符）），返回给协调节点，由协调节点进行数据的合并、排序、分页等操作，产出最终结果
4.  fetch phase（取回阶段）：接着由协调节点，根据doc id（文档标识符）去各个节点上拉取实际的document（document）数据，最终返回给客户端

> **搜索的底层原理**：，广播查询请求到所有相关分片，并将它们的响应整合成全局排序后的结果集合，这个结果集合会返回给客户端.
> 
> 1.  当一个节点接收到一个搜索请求，这这个节点就会变成协调节点，第一步就是将广播请求到搜索的每一个节点的分片拷贝，查询请求可以被某一个主分片或某一个副分片处理，协调节点将在之后的请求中轮训所有的分片拷贝来分摊负载.
> 2.  每一个分片将会在本地构建一个优先级队列，如果客户端要求返回结果排序中从from 名开始的数量为size的结果集，每一个节点都会产生一个from+size大小的结果集，因此优先级队列的大小也就是from+size，分片仅仅是返回一个轻量级的结果给协调节点，包括结果级中的每一个文档的ID和进行排序所需要的信息.
> 3.  协调节点将会将所有的结果进行汇总，并进行全局排序，最总得到排序结果.
> 4.  查询过程得到的排序结果，标记处哪些文档是符合要求的，此时仍然需要获取这些文档返回给客户端
> 5.  协调节点会确定实际需要的返回的文档，并向含有该文档的分片发送get请求，分片获取的文档返回给协调节点，协调节点将结果返回给客户端.

#### 7. Elasticsearch写数据的过程 ####

1.  客户端选择一个node发送请求过去，这个node就是coordinating node (协调节点)
2.  coordinating node，对document（文档）进行路由，将请求转发给对应的node（有primary shard）
3.  实际上的node上的primary shard（主分片）处理请求，然后将数据同步到replica node（副本结点）
4.  coordinating node，如果发现primary node和所有的replica node都搞定之后，就会返回请求到客户端

> **写入数据的底层原理**
> 
> 1.  数据先写入到buffer里面，在buffer里面的数据时搜索不到的，同时将数据写入到translog日志文件之中
> 2.  如果buffer快满了，或是一段时间之后，就会将buffer数据refresh到一个新的OS cache之中，然后每隔1秒，就会将OS cache的数据写入到segment file之中，但是如果每一秒钟没有新的数据到buffer之中，就会创建一个新的空的segment file，只要buffer中的数据被refresh到OS cache之中，就代表这个数据可以被搜索到了.当然可以通过restful api 和Java api，手动的执行一次refresh操作，就是手动的将buffer中的数据刷入到OS cache之中，让数据立马搜索到，只要数据被输入到OS cache之中，buffer的内容就会被清空了.同时进行的是，数据到shard之后，就会将数据写入到translog之中，每隔5秒将translog之中的数据持久化到磁盘之中
> 3.  重复以上的操作，每次一条数据写入buffer，同时会写入一条日志到translog日志文件之中去，这个translog文件会不断的变大，当达到一定的程度之后，就会触发commit操作.
> 4.  将一个commit point写入到磁盘文件，里面标识着这个commit point 对应的所有segment file
> 5.  强行将OS cache 之中的数据都fsync到磁盘文件中去.  
>     解释：translog的作用：在执行commit之前，所有的而数据都是停留在buffer或OS cache之中，无论buffer或OS cache都是内存，一旦这台机器死了，内存的数据就会丢失，所以需要将数据对应的操作写入一个专门的日志问价之中，一旦机器出现宕机，再次重启的时候，es会主动的读取translog之中的日志文件的数据，恢复到内存buffer和OS cache之中.
> 6.  将现有的translog文件进行清空，然后在重新启动一个translog，此时commit就算是成功了，默认的是每隔30分钟进行一次commit，但是如果translog的文件过大，也会触发commit，整个commit过程就叫做一个flush操作，我们也可以通过ES API，手动执行flush操作，手动将OS cache 的数据fsync到磁盘上面去，记录一个commit point，清空translog文件  
>     补充：其实translog的数据也是先写入到OS cache之中的，默认每隔5秒之中将数据刷新到硬盘中去，也就是说，可能有5秒的数据仅仅停留在buffer或者translog文件的OS cache中，如果此时机器挂了，会丢失5秒的数据，但是这样的性能比较好，我们也可以将每次的操作都必须是直接fsync到磁盘，但是性能会比较差.
> 7.  如果时删除操作，commit的时候会产生一个.del文件，里面讲某个doc标记为delete状态，那么搜索的时候，会根据.del文件的状态，就知道那个文件被删除了.
> 8.  如果时更新操作，就是讲原来的doc标识为delete状态，然后重新写入一条数据即可.
> 9.  buffer每次更新一次，就会产生一个segment file 文件，所以在默认情况之下，就会产生很多的segment file 文件，将会定期执行merge操作
> 10. 每次merge的时候，就会将多个segment file 文件进行合并为一个，同时将标记为delete的文件进行删除，然后将新的segment file 文件写入到磁盘，这里会写一个commit point，标识所有的新的segment file，然后打开新的segment file供搜索使用.
> 
> 总之，segment的四个核心概念，**refresh**，**flush**，**translog**、**merge**

**写数据底层原理**

![img][img 3]

![img][img 4]![img][img 4]

#### 8. Elasticsearch读数据过程 ####

查询，GET某一条的数据，写入某个document，这个document会自动给你分配一个全局的唯一ID，同时根据这个ID进行hash路由到对应的primary shard上面去，当然也可以手动的设置ID。

1.  客户端发送任何一个请求到任意一个node，成为coordinate node
2.  coordinate node 对document进行路由，将请求转发到对应的node，此时会使用round-robin**随机轮训算法**，在primary shard 以及所有的replica中随机选择一个，让读请求**负载均衡**，
3.  接受请求的node，返回document（**文件**）给coordinate note。
4.  coordinate node返回给客户端

1.写入document时，每个document会自动分配一个全局唯一的id即doc id，同时也是根据doc id进行hash路由到对应的primary shard上。也可以手动指定doc id，比如用订单id，用户id。
    2.读取document时，你可以通过doc id来查询，然后会根据doc id进行hash，判断出来当时把doc id分配到了哪个shard上面去，从那个shard去查询

#### 9. Elasticsearch文档的索引更新和删除 ####

> **文档**是ES中主要的实体。对所有使用ES的案例，它们最终都可以总结为对文档的搜索。文档由字段构成。

**1. Elasticsearch索引文档的过程**

协调节点默认使用文档 ID 参与计算（也支持通过 routing），以便为路由提供合适的分片。

shard = hash(document_id) % (num_of_primary_shards)

1、当分片所在的节点接收到来自协调节点的请求后，会将请求写入到 Memory Buffer，然后定时（默认是每隔 1 秒）写入到 Filesystem Cache，这个从 Momery Buffer 到 Filesystem Cache 的过程就叫做 refresh；

2、当然在某些情况下，存在 Momery Buffer 和 Filesystem Cache 的数据可能会丢失，ES 是通过 translog 的机制来保证数据的可靠性的。其实现机制是接收到请求后，同时也会写入到 translog 中，当 Filesystem cache 中的数据写入到磁盘中时，才会清除掉，这个过程叫做 flush；

3、在 flush 过程中，内存中的缓冲将被清除，内容被写入一个新段，段的 fsync将创建一个新的提交点，并将容刷新到磁盘，旧的 translog 将被删除并开始一个新的 translog。

4、flush 触发的时机是定时触发（默认 30 分钟）或者 translog 变得太大（默认为 512M）时；

**补充：关于 Lucene 的 Segement：**

1、Lucene 索引是由多个段组成，段本身是一个功能齐全的倒排索引。

2、段是不可变的，允许 Lucene 将新的文档增量地添加到索引中，而不用从头重

建索引。

3、对于每一个搜索请求而言，索引中的所有段都会被搜索，并且每个段会消耗

CPU 的时钟周、文件句柄和内存。这意味着段的数量越多，搜索性能会越低。

4、为了解决这个问题，Elasticsearch 会合并小段到一个较大的段，提交新的合并段到磁盘，并删除那些旧的小段。

**2.Elasticsearch更新和删除文档的过程**

删除和更新也都是写操作，但是Elasticsearch中的文档是不可变的，因此不能被删除或者改动以展示其变更；  
　　磁盘上的每个段都有一个相应的.del文件.当删除请求发送后，文档并没有真的被删除，而是在.del文件中被标记为删除.该文档依然能匹配查询，但是会在结果中被过滤掉.当段合并时，在.del文件中被标记为删除的文档将不会被写入新段.  
　　在新的文档被创建时，Elasticsearch会为该文档指定一个版本号，当执行更新时，旧版本的文档在.del文件中被标记为删除，新版本的文档被索引到一个新段.旧版本的文档依然能匹配查询，但是会在结果中被过滤掉.

#### 10. Elasticsearch如果保证在并发情况下读写一致？ ####

可以通过版本号使用**乐观并发控制**，以确保新版本不会被旧版本覆盖，由应用层来处理具体的冲突；  
　　另外对于**写操作**，一致性级别支持quorum/one/all，默认为quorum，即只有当大多数分片可用时才允许写操作.但即使大多数可用，也可能存在因为网络等原因导致写入副本失败，这样该副本被认为故障，分片将会在一个不同的节点上重建.  
　　对于**读操作**，可以设置replication为sync(默认)，这使得操作在主分片和副本分片都完成后才会返回；如果设置replication为async时，也可以通过设置搜索请求参数\_preference为primary来查询主分片，确保文档是最新版本.

#### 11. Elasticsearch对于大数据量的聚合如何实现？ ####

Elasticsearch 提供的首个近似聚合是cardinality 度量.它提供一个字段的基数，即该字段的distinct或者unique值的数目.它是基于HLL算法的.HLL 会先对我们的输入作哈希运算，然后根据哈希运算的结果中的 bits 做概率估算从而得到基数.其特点是：可配置的精度，用来控制内存的使用（更精确 ＝ 更多内存）；小的数据集精度是非常高的；我们可以通过配置参数，来设置去重需要的固定内存使用量.无论数千还是数十亿的唯一值，内存使用量只与你配置的精确度相关 .

#### 12. Elasticsearch在海量数据中怎样提高效率 ####

1.  filesystem cache  
    ES的搜索引擎是严重的依赖底层的filesystem cache，如果给filesystem cache更多的内存，尽量让内存可以容纳所有的index segment file 索引数据文件
2.  数据预热  
    对于那些你觉得比较热的数据，经常会有人访问的数据，最好做一个专门的缓存预热子系统，就是对热数据，每隔一段时间，你就提前访问以下，让数据进入filesystem cache里面去，这样期待下次访问的时候，性能会更好一些.
3.  冷热分离

关于ES的性能优化，数据拆分，将大量的搜索不到的字段，拆分到别的存储中去，这个类似于MySQL的分库分表的垂直才分.

1.  document的模型设计

不要在搜索的时候去执行各种复杂的操作，尽量在document模型设计的时候，写入的时候就完成了，另外对于一些复杂的操作，尽量要避免

1.  分页性能优化

翻页的时候，翻得越深，每个shard返回的数据越多，而且协调节点处理的时间越长，当然是用scroll，scroll会一次性的生成所有数据的一个快照，然后每次翻页都是通过移动游标完成的. api 只是在一页一页的往后翻

作者：雨露  
链接：https://segmentfault.com/a/1190000015256970  
来源：SegmentFault 思否  
著作权归作者所有.商业转载请联系作者获得授权，非商业转载请注明出处.

#### 13.Elasticsearch 字段数据类型 ####

https://www.cnblogs.com/valor-xh/p/6250302.html  
Elasticsearch 可以支持单个document中含有多个不同的数据类型。

--------------------

**核心数据类型（Core datatypes）**

*  字符型（[String datatype][]）：string
 *  数字型（[Numeric datatypes][]）：long：64位存储 , integer：32位存储 , short：16位存储 , byte：8位存储 , double：64位双精度存储 , float：32位单精度存储
 *  日期型（[Date datatype][]）：date
 *  布尔型（[Boolean datatype][]）：boolean
 *  二进制型（[Binary datatype][]）：binary

**复杂数据类型（Complex datatypes）**

*  数组类型（
    
    Array datatype
    
    ）：数组类型不需要专门指定数组元素的type，例如：
    
     *  字符型数组: \[ “one”, “two” \]
     *  整型数组：\[ 1, 2 \]
     *  数组型数组：\[ 1, \[ 2, 3 \]\] 等价于\[ 1, 2, 3 \]
     *  对象数组：\[ \{ “name”: “Mary”, “age”: 12 \}, \{ “name”: “John”, “age”: 10 \}\]
 *  对象类型（[Object datatype][]）： *object* 用于单个JSON对象；
 *  嵌套类型（[Nested datatype][]）： *nested* 用于JSON数组；

**地理位置类型（Geo datatypes）**

*  地理坐标类型（[Geo-point datatype][]）： *geo\_point* 用于经纬度坐标；
 *  地理形状类型（[Geo-Shape datatype][]）： *geo\_shape* 用于类似于多边形的复杂形状；

**专业类型（Specialised datatypes）**

*  IPv4 类型（[IPv4 datatype][]）： *ip* 用于IPv4 地址；
 *  Completion 类型（[Completion datatype][]）： *completion* 提供自动补全建议；
 *  Token count 类型（[Token count datatype][]）： *token\_count* 用于统计做了标记的字段的index数目，该值会一直增加，不会因为过滤条件而减少。
 *  [mapper-murmur3 ][mapper-murmur3]类型：通过插件，可以通过 *murmur3* 来计算index的 hash 值；
 *  附加类型（Attachment datatype）：采用[mapper-attachments ][mapper-attachments]插件，可支持 *attachments* 索引，例如Microsoft Office 格式，Open Document 格式，ePub, HTML 等。

[CAP]: http://www.jdon.com/37625
[Hibernate]: https://www.jdon.com/dl/best/hibernate.htm
[Link 1]: https://baike.baidu.com/item/%E6%96%87%E6%9C%AC%E5%88%86%E6%9E%90/11046544
[link1]: https://blog.csdn.net/laoyang360/article/details/84727820?utm_medium=distribute.pc_relevant_t0.none-task-blog-BlogCommendFromMachineLearnPai2-1.compare&depth_1-utm_source=distribute.pc_relevant_t0.none-task-blog-BlogCommendFromMachineLearnPai2-1.compare
[link2]: https://blog.csdn.net/u013465194/article/details/83305411
[img]: /images/20221124/618f8600d70141359435b34ca6b21371.png
[img 1]: /images/20221124/ae1c1dde9c9c4680af4a6b4f76ceab80.png
[img 2]: /images/20221124/4625208a75934c93b462e6ad23c9b227.png
[img 3]: /images/20221124/fdb0ac7033e143dcaabcba6d0b712c11.png
[img 4]: /images/20221124/126a82cda68a47b38ca780786221ff0e.png
[String datatype]: https://www.elastic.co/guide/en/elasticsearch/reference/2.3/string.html
[Numeric datatypes]: https://www.elastic.co/guide/en/elasticsearch/reference/2.3/number.html
[Date datatype]: https://www.elastic.co/guide/en/elasticsearch/reference/2.3/date.html
[Boolean datatype]: https://www.elastic.co/guide/en/elasticsearch/reference/2.3/boolean.html
[Binary datatype]: https://www.elastic.co/guide/en/elasticsearch/reference/2.3/binary.html
[Object datatype]: https://www.elastic.co/guide/en/elasticsearch/reference/2.3/object.html
[Nested datatype]: https://www.elastic.co/guide/en/elasticsearch/reference/2.3/nested.html
[Geo-point datatype]: https://www.elastic.co/guide/en/elasticsearch/reference/2.3/geo-point.html
[Geo-Shape datatype]: https://www.elastic.co/guide/en/elasticsearch/reference/2.3/geo-shape.html
[IPv4 datatype]: https://www.elastic.co/guide/en/elasticsearch/reference/2.3/ip.html
[Completion datatype]: https://www.elastic.co/guide/en/elasticsearch/reference/2.3/search-suggesters-completion.html
[Token count datatype]: https://www.elastic.co/guide/en/elasticsearch/reference/2.3/token-count.html
[mapper-murmur3]: https://www.elastic.co/guide/en/elasticsearch/plugins/2.3/mapper-size.html
[mapper-attachments]: https://www.elastic.co/guide/en/elasticsearch/plugins/2.3/mapper-attachments.html