1.ELK之Elasticsearch&Kibana一篇入门(安装/分片/操作流程/常用语句/分词)

③Logstash 是一个开源的数据收集引擎；它可以按照我们定制的规范实时的进行数据收集、解析和存储。也就是说Logstash有3个核心组成部分，分别是数据收集、数据解析和数据转存。这个三个部分组成了一个类似于管道的数据流，由输入端进行数据的采集，管道本身做数据的过滤和解析，输出端把过滤和解析后的数据输出到目标数据库中。更多关于Logstash参见这里

④Beats 为此网上也有一种说法将ELKB，这里的B是的就是Beats。总的来讲Beats和Logstash一样都是为了收集和摄取数据，但是目前来讲Beats更轻量些(资源利用高效/无依赖/小型)。不过Beats也一直在迭代和增强，目前两者的差距在逐渐拉小。

关于 Beats参见这里

一、ES相关概念

手册路径：官网→最上方“learn→docs”→下翻至Guide→然后就可以看到各版本的指令文档了。

搜索：对于以下找不到的关键词(如template)点击右上方的“🔍”就可以搜索相关内容了。

如下为5.3版本直达链接：这里

官方手册。右侧选择版本后就可以选择关心的api手册内容了。

1.1、ES简介 ←→ MYSQL

Elasticsearch(ES)是一个基于Lucene构建的开源、分布式、RESTful接口的全文搜索引擎。ES还是一个分布式文档数据库，其中每个字段均是被索引的数据且可被搜索。它能够扩展至数以百计的服务器存储已经处理PB级别的数据。

（1）ES与Lucene的关系。ES是基于Apache Lucene实现的，ES则提供了更高层次的封装以及分布式方面的增强与扩展(更丰富的查询语句等)。在应用开发中直接使用ES会很简单，如果直接使用Lucene就要与大量的集成工作。

1) Elasticsearch基于Lucene构建，Elasticsearch利用Lucene做实际的工作；
2) ELasticsearch中的每个分片都是一个独立的Lucene实例(对就是分片)；
3) Elasticsearch在Lucene基础上(即利用Lucene的功能)提供了一个分布式的、基于JSON的REST API 来更方便地使用Lucene的功能；
4) Elasticsearch提供其他支持功能,如线程池,队列,节点/集群监控API,数据监控API,集群管理等。

入门ES的话稍微了解下Lucene即可。但是如果想往高级走，还是需要学习lucene底层原理的。因为倒排索引、打分机制、全文检索原理、分词原理等等都是不会过时的技术。

1.2、ES概念与读写流程(官网)

ES官网的2.x版本的中文手册：集群内的原理 | Elasticsearch: 权威指南 | Elastic

ES官网8.x版本的英文手册：Size your shards | Elasticsearch Guide [8.11] | Elastic

1.2.1、集群cluster

首先看一下一个ES集群大概的组织形式图。非常直观！！！！！

①一个集群由多个Node节点组成，每个node就是一个ES实例；

②每个节点上会有多个Shard(分片)，分为主分片(primary shard)和副分片(replaca shard)；

③每个分片即可视为一个Lucene实例(Lucene Index)，本身就是一个完整的搜索引擎；

④Lucene Index是一个统称，它由多个Segment(段文件/即倒排索引)组成；

⑤每个段文件存储着的就是文档。

(1)集群就是由一个或多个拥有相同cluster.name配置的节点组成的，所有的节点共同承担数据和负载的压力。当有节点加入集群或从集群移除节点时，集群会重新平均分布所有的数据。

(2)集群中有多个节点(node)其中有一个为主节点，通过选举产生。注意这个主节点是对集群内部来说的，es的一个概念就是去中心化字面上理解就是无中心节点。这个无中心是对集群外部来说的，即从外部来看es集群逻辑上是一个整体。也就是说你与任何一个节点的通信与整个es集群通信是等价的。

(3)作为用户我们可以将请求发送到集群中的任何节点，包括主节点。每个节点都知道任意文档所处的位置，并且能够将我们的请求直接转发到文档的存储节点。无论我们将请求发送到哪个节点，它都能收集到数据并返回给客户端。ES对这一切的管理都是透明的。

(4)ES利用分片将数据分布式的存储于集群各节点。当集群规模扩大或者缩小时，ES会自动的在各个节点中迁移分片，使得数据仍然均匀分布在集群中。具体来说，ES集群是在 data tiers层面自动的进行数据均衡。所谓data tier其实就是一个集群的node的一个分组。在每个data tiers中ES都会尝试将索引的分片分布在尽可能多的节点上。

Size your shards | Elasticsearch Guide [8.11] | Elastic

Data tiers | Elasticsearch Guide [8.11] | Elastic

A data tier is a collection of nodes with the same data role that typically share the same hardware profile。

(5)一个分片可以是主分片或者副本分片。索引内任意文档都属于一个主分片，所以主分片的数据决定了索引能够保存的最大数据量。

图示为三个节点。其中任何一个都是有可能故障或者宕机的，此时其承载的shard的数据就会丢失；通过设置一个或者多个replica shard就可以在发生故障的时候提供备份服务。一方面可以保证数据不丢失，另一方面还可以提升操作的吞吐量和性能。

我们可以通过如下指令查询集群健康状况：

GET /_cluster/health


#其返回如下：
{
  "cluster_name" : "es-138exzsp",
  "status" : "green",
  "timed_out" : false,
  "number_of_nodes" : 3,
  "number_of_data_nodes" : 3,
  "active_primary_shards" : 614,
  "active_shards" : 1228,
  "relocating_shards" : 0,
  "initializing_shards" : 0,
  "unassigned_shards" : 0,
  "delayed_unassigned_shards" : 0,
  "number_of_pending_tasks" : 0,
  "number_of_in_flight_fetch" : 0,
  "task_max_waiting_in_queue_millis" : 0,
  "active_shards_percent_as_number" : 100.0
}

status 字段指示着当前集群在总体上是否工作正常。，它的三种颜色含义如下：

green：所有的主分片和副本分片都正常运行。

yellow：所有的主分片都正常运行，但不是所有的副本分片都正常运行。

red：有主分片没能正常运行。

1.2.2、节点node(client/master/data)

前面有提到了发生宕机时master会参与恢复，这里简要的介绍下master。其实除了master ES集群中的节点根据其被配置后所实际执行的功能可以大致分为 client/master/data三种。

查看节点信息(谁是master节点)，如下图有"*"号的就是master节点。

GET _cat/nodes?v

前面所说的配置无非就是主节点和数据节点的配置，如下:

node.master: true
node.data: false

(1) 主节点(master node)

elasticsearch.yml

node.master: true
node.data: false

主要功能：维护元数据，管理集群节点状态；不负责数据写入和查询。
配置要点：内存可以相对小一些，但是机器一定要稳定，最好是独占的机器。

当node.master被设置为true的时候就为主节点。理想情况下这个master节点就干一些管理性质的工作，比如维护索引元数据(创建删除索引)、负责切换primary shard和replica shard身份等。主节点的稳定性非常重要。默认情况集群中任何一个node.master没有被设为false的节点都有可能被选为主节点，为了让集群更加稳定分离主节点和数据节点是一个比较好的选择。

要是master节点宕机了，那么会自动重新选举一个节点为master。

如果非master节点宕机了，会有master节点让宕机节点上的primary shard的身份转移到其他机器上的replica shard。等到宕机机器重启恢复后，master节点会控制将缺失的replica shard分片补充过去，同步后续修改数据之类的，让集群恢复到有容错保障的状态。

稳定的主节点对集群的健康是非常重要的。默认情况下任何一个集群中的节点都有可能被选为主节点。索引数据和搜索查询等操作会占用大量的CPU、内存、IO资源，为了确保一个集群的稳定，分离主节点和数据节点是一个比较好的选择。我们可以通过配置指定一个节点应该是数据节点还是master节点。

(2) 客户端节点(client node)

elasticsearch.yml

node.master: false
node.data: false
 
主要功能：负责任务分发和结果汇聚，分担数据节点压力。
配置要点：大内存，最好是独占的机器

当node.master/data都被设置为false的时候即为客户端节点。此时该节点只能处理路由请求、处理搜索、分片索引操作等。独立的客户端节点在大型集群中是非常有用的，它协调主节点和数据节点。

(3) 数据节点(data node)

elasticsearch.yml

node.master: false
node.data: true


主要功能：负责数据的写入与查询，压力大。
配置要点：大内存，最好是独占的机器。

node.master未设置为false、data被设置为true即为数据节点。数据节点的作用就是实际承载数据的节点，也是执行增删改查、聚合操作的节点。数据节点对cpu、内存、io要求较高。注意当资源不够用的时候需要向集群中添加新的节点。

(4) 混合节点(mixed node) 不建议


elasticsearch.yml

node.master: true
node.data: true

(5) ES的扩容

ES的扩容就是新增节点(node)，然后在将所有的shard在节点之间进行一个重新的分配(负载均衡）就可以了。

1.2.3、分片shard

ES就是利用分片来实现分布式的，通过将索引分解成多个分片分布在不同的节点上从而实现横向扩展。分片是数据的容器，文档就保存在分片内，分片又被分配到集群的各个节点中。当集群规模扩大或者缩小的时候，ES会自动地在各个节点中迁移分片。

我们可以通过shards指令查看分片的具体信息。命令会列出详细的列出哪些节点包含哪些分片。也会告诉你这个分片的主/副信息、每个分片的文档数和这些文档在磁盘上占用的字节数。同时也会告诉你这些节点位于那个ip。

#查看所有分片的情况
GET /_cat/shards?v
#指定查看某个索引的分片的情况
GET /_cat/shards/es_qidian_flow_online_v2_202202?v

GET /_cat/shards/es_qidian_flow_online_v2_202202?pretty&v

注：GET /_cat/shards?v 这里"v"而不是"?v",如上这里是url链接参数的语法而已。他的的作用就是列出表头(还是要比较好,不熟悉的情况至少知道每个字段的含义)。如下为一个实例。

下图为消息记录搜索功能对应的一个索引的具体分片信息，结合前面的示意图进行解读。

①可以看到node节点号和ip是完全能对应上的;也可以看到对于消息记录搜索这个case总共有三个节点和腾讯云上能看到的配置相同。

②shard列为分片号,分别为0~8；针对其中任一分片例如4,可以看到其有一个主分片(p)和一个副分片(r)。其中每一个分片有点像是mongodb的1主1从的一份副本集,不过在具体组织上还是有区别的。即mongodb任一个主or从其实都是对应一个mongod实例；但是对于这里的es而言总共只有三个node，2*9=18个主副分片都是分布在这三个node上，只不过在组织的时候尽量让主副分片不落在同一个node上就可以了。和前面的示意图也完全一致。

③docs可以看到每个分片的文档数,可以留意到同一分片的主副节点的文档数是完全一致的。这从侧面也说明了主副节点之间"副本集"的关系(一份数据冗余存储)。

④store可以看到磁盘存储空间的占用情况。

⑤增减节点(node)的时候shard会自动在nodes中负载均衡;其实从上面截图中我们也可以看到三个节点承载的分片数是差不多的。

⑥primary shard的数量在建立索引的时候设置后续不能修改(代价极高)；但是副本分片数可以随时修改。默认情况会分别创建5个primary shard和5个replica shard。关于截图这个case的9个分片就是创建索引的时候指定的，如下模板和索引中都能看到相关设置。

注：当然硬要修改分片数也是可以的，es也提供了相应的api来进行reindex。不过这个代价有点高，要重建整个索引。

思考：其实之所以代价高是es的路由机制决定的，分片数变化后就routing不到原来的数据了。当然我们可以进行更深层次的思考，尤其是和mongodb这种可以任意扩充分片的数据库进行对比。会发现本质原因对于ES来说shard就是承载数据的最小单位，写入的时候也完全是按照shard的数量进行的路由；而mongodb最小承载单位是chunk，chunk不是固定在某个shard一成不变，而是在balancer的控制下动态地游走于各个shard之间。

⑦primary shard不能和自己的replica shard放到同一个节点上(否则该节点挂了后这个分片的数据就彻底丢失了，起不到容错作用)，但是可以和其他shard的replica节点放到一个节点上。

注：对于只有一个节点的集群来说即便指定replica shard也是没有意义的。此时副分片状态依然是unassigned —— 它们都没有被分配到任何节点。在同一个节点上既保存原始数据又保存副本是没有意义的，因为一旦失去了那个节点，我们也将丢失该节点上的所有副本数据。

⑧每个doc肯定只存在于某一个primary shard以及其对应的replica shard中，不可能存在于多个primary shard上。

⑨replica的容错。举个例子master节点(node)宕机后，其上存在的primary shard也一并异常。这个时候会选举产生一个新的master，它会将异常primary shard对应的replica shard提升为primary shard。重启宕机node，master copy备份的数据到重启后的node，然后还会同步宕机所落后的数据，并将这个shard降级为replica。注：关于node下面会讲到。

⑩replica提供读扩展能力。副节点的增多在能提高冗余的同时也有助于提高集群整体的吞吐量。不过这个肯定是要配合硬件资源的增加的，否则也只是相互抢占资源而已。

注：统计数据量的时候副本集只能算一份数据，不要重复统计了哦！(大概8亿/月)

在日常使用中我们应该如何调整分片的大小呢？—— 很多靠谱的建议。

具体参见官网： Size your shards | Elasticsearch Guide [8.11] | Elastic

简单列下：

(1)单个节点上可以存储的数据量是有限的，因此您可以通过添加节点以及增加匹配的索引和分片数量来增加集群的容量。

(2)但是每个索引和分片都会有自己对应的开销(内存/CPU)，索引将数据划分到过多的分片也是不合理的。

(3)删除的文档并不会立即从ES的文件系统中删除。而是在每个相关分片上将文档标记为已删除。被标记的文档会继续占用资源，一直到定期的段合并的时候才会删除(之后物理空间会自动释放)。对于删除索引，ES是立即删除并释放资源的。

(4)大部分情况下数量更少但是却更大的分片比使用N多小分片要节省资源；搜索1千个50MB的分片比所有包含同样数据的单个50GB分片成本要高的多。不过，过分大的分片也会导致搜索速度变慢。

(5)分片在物理大小上没有硬性的限制，理论上每个分片最多包含20亿个文档。就实际使用来说每个分片数据保持在2亿条以下，10GB到50GB之间是适合于绝大多数情况。

(6)可以通过配置如下参数显式限制单个节点上的分片数量以避免热点节点。

index.routing.allocation.total_shards_per_node

(7)对于完全不被搜索和聚合查询的字段在创建mapping的时候可以明确其index属性为false，以减少不必要的开销。注：参见mapping

Mapping | Elasticsearch Guide [8.11] | Elastic

(8)我们可以通过如下语句调整集群的最大可承载分片数。

PUT /_cluster/settings
{
"persistent":{
"cluster.max_shards_per_node":1100
}
}

(9)对于3节点，每个节点8核32G配置的es集群来说。主副加起来200个分片完全是ok的。注：也不是越多越好，分片数更多消耗内存也随之增加。

关于ES分片设置的6个建议_es 分片数量多少合适_暮暮七的博客-CSDN博客

ES为什么不支持shard-spliting？

ES认为分片分裂(shard-spliting)是一个糟糕的想法：

（1）spliting一个分片几乎等于重新索引分片数据。它远比将一个分片从一个节点复制到另一个节点要繁重的多。

（2）spliting需要拥有足够的空间支持另一份数据的拷贝。通常来说当你意识到需要横向扩展的时候已经没有足够的剩余空间来做这件事情了。

分片预分配 | Elasticsearch: 权威指南 | Elastic

ES可以通过reindex实现分片分裂

所谓reindex：将一个index的数据复制到到另一个已经存在的索引；只复制数据不复制原索引的mapping、shard、replica等配置信息，即shard/replica都是可以重新定义的，借此可以实现扩分片等目的。但是和移动分片比起来这依然是一个资源消耗较大的操作。即便如此，至少ES有了重新定义分片数的方法了。

reindex可以实现集群内的index1→index2，也可以实现跨集群的index1→index2。

Reindex API | Elasticsearch Guide [8.9] | Elastic

https://www.cnblogs.com/erlou96/p/16878218.html

elasticsearch 基础 —— ReIndex_es 复制mapping-CSDN博客

1.2.4、ES的分片在集群节点间的均衡策略(分片分配)及存在问题

关于分片分配可以参照官网。说起来很简单就是shard在node上如何分配。

ES自身是又一个分配算法的，这个具体就不研究了。但是作为使用者要知道两个相对较坑的事情。

①ES的分片分配看来是所有主副节点的分配，看起来并去区分主节点还是副节点。也就是可能出现分片个数在node之间确实均衡分配了，但是主分片过于集中某些node的情况。

②ES诸如滚动重启之类的操作非常有可能导致索引主分片和副本分片分布不均匀的问题。例如，更晚重启的节点上因为更晚被检测丢失，其上的主分片就会全部落到已经重启成功的节点上。即便该节点重启成功了，其上的分片依然会被当成副本分片。

解决思路：

①一般情况下不需要人为干预；过于失衡的情况下也可以人工干预。

②例如对于腾讯云上的ES集群，就可以通过Cerebro来手动调整主分片的分布。

③还有一个思路就是。先将副本数设置为0，这样仅剩的主分片就会触发冲平衡。待这些主分片重平衡完成后再恢复副本分片数。

如下为Cerebro操作界面。

1.2.5、索引(Index) ←→ Database

索引这个词在ElasticSearch中有三种意思( ES中的“索引”非传统索引的含义，是ES中的一个概念词汇)：

（1）索引(名词)。类比到关系型数据库，索引就是数据库(Database)。例如"create database mydb"。ES中的索引就理解为db，我们可以向索引写入文档或者从索引中读取文档。ElasticSearch将它的数据存储在一个或多个索引中；在数据量较大的应用中一个月或者一天就创建一个索引不在少数。另外，索引名称必须全部小写，不建议写成驼峰式。

（2）索引(动词)。保存一个文档到索引(名词)的过程。类似于Sql语句中的insert关键词，如果该文档已经存在那就相当于数据库的update。

（3）倒排索引。对于mysql或mongodb来说利用B+树提升数据检索速度。相对应地 ElasticSearch使用了一个叫做“倒排索引”的结构来达到相同的目的。

注：一定程度上es的索引(index)也有些mysql的表(table)的潜质。因为一般情况下我们会把相同特征(Filed数量和类型基本相同)的文档放到同一个索引里面。这样方便提前通过mapping来规定各个Filed的类型。

1.2.6、类型(Type)

类比到关系型数据库，类型(Type)就是表(Table)。之前的版本中索引和文档中间还有类型的概念，即每个索引下可以建立多个类型，文档存储的时候需要指定index的type(类似于每个database和每条数据之间还要有个Table)。从6.0.0以后单个索引中只能有一个类型了，7.0.0以后不建议使用，8.0.0以后将完全不支持。注：这样做的目的主要是为了提高查询效率。

1.2.7、文档(Document)

Index里面单条记录称为Document(文档)，等同于关系型数据库表中的行；关于doc这个命名ES和MongoDB很类似。Document是ElasticSearch中的主要实体，对ES的搜索最终都归结为对文档的搜索。文档由字段构成；文档是无模式的、即并非所有的文档都需要拥有相同的字段，他们不限于一种模式(schema)。下面看看一条文档数据有哪些字段。

(1)_index：文档所属索引的名称。

(2)_type：文档所属类型名。

(3)_id：主键ID 即docid。写入的时候可以指定docid,如果不指定系统会自动生成一个唯一的UUID。_id是ES的默认字段并且非Doc Values所以默认情况下不可用于排序或聚合，如果非要用于排序or聚合的话建议将这个值作为doc一个字段用以支持。

另外，ES默认生成的_id比用户自定义_id更高效，因为ES不用花费多余的资源检查这个文档的_id是否与ES已有数据重复。具体参见如下链接。

注：据腾讯云helper 自动生成_id比用户执行docid写入性能快30%。

_id field | Elasticsearch Guide [8.9] | Elastic
https://medium.com/@musabdogan/understanding-elasticsearchs-auto-generated-id-is-duplication-a-concern-3ced51e14f93

_id用于去重：

插入数据的时候通过指定docid就可以实现主键去重；

ES也可以将_id指定为其他字段，如下：

curl -XPOST localhost:9200/test -d '{
 "settings" : {
     "number_of_shards" : 1,
     "number_of_replicas":0
 },
 "mappings" : {
     "test1" : {
         "_id":{"path":"mainkey"},
         "_source" : { "enabled" : false },
         "properties" : {
             "mainkey" : { "type" : "string", "index" : "not_analyzed" }
         }
     }
 }
}'

(4)_version：文档的版本信息，用于冲突处理。ES使用version来保证对文档的变更能以正确的顺序执行，避免乱序造成数数据错误。具体参见官网

ElasticSearch采用乐观并发控制。Elasticsearch是分布式的，当文档被创建、更新或删除，文档的新版本会被复制到集群的其它节点。Elasticsearch即是同步的又是异步的，意思是这些复制请求都是平行发送的，并无序(out of sequence)的到达目的地。这就需要一种方法确保老版本的文档永远不会覆盖新的版本。
这时就用到了元数据“_version”，每个文档都有一个_version号码，这个号码在文档被改变时加1，Elasticsearch使用这个_version保证所有修改都被正确排序。当一个旧版本出现在新版本之后，它会被简单的忽略。

#如下指定我们此次修改应用的版本是1;
PUT /website/blog/1?version=1 
{
  "title": "My first blog entry",
  "text":  "Starting to get the hang of this..."
}

#目标文档只有在_version为1的时候才能更改成功,相应中数据的_version已经变为2了。
{
  "_index":   "website",
  "_type":    "blog",
  "_id":      "1",
  "_version": 2
  "created":  false
}

#如果我们继续执行上述语句会返回 409 Conflict HTTP 响应码，和一个如下所示的响应体。
{
   "error": {
      "root_cause": [
         {
            "type": "version_conflict_engine_exception",
            "reason": "[blog][1]: version conflict, current [2], provided [1]",
            "index": "website",
            "shard": "3"
         }
      ],
      "type": "version_conflict_engine_exception",
      "reason": "[blog][1]: version conflict, current [2], provided [1]",
      "index": "website",
      "shard": "3"
   },
   "status": 409
}

#接下来怎么做就是应用程序的事情了。

(5)_seq_no：严格递增的顺序号。每个文档一个，Shard级别的严格递增，后写入Doc的_seq_no大于先写入的Doc的_seq_no。

(6)_primary_term：和_seq_no一样是一个整数，每当Primary Shard发生重新分配时，比如重启，Primary选举等，_primary_term会递增1.

(7)found：查询ID正确就为true；如果ID不正确就查不到数据，found字段就是false。

(8)_source：文档原始的JSON数据。默认情况下源文档被存储在_source这个字段中，查询的时候也是返回这个字段。这允许你可以从搜索结果中访问原始的对象，这个对象返回一个精确的Json字符串，这个对象不显示索引分析后的其他任何数据。

1.2.8、settings

索引的settings信息分为静态信息和动态信息两部分。静态信息不可更改，例如分片数；动态信息只可以修改的信息。参见官网这里。

REST访问语句：

#更新特定索引
PUT /myindex/_settings
{
    #具体操作
}


#更新所有索引
PUT */_settings
{
 "index.blocks.read": true   #具体操作
}

1.2.9、映射(mappings)

1.2.9.1、mapping基本介绍

Dynamic mapping | Elasticsearch Guide [8.11] | Elastic

mapping类似于关系型数据库中的表结构定义(注:es不会像sql那样限制的那么死)。就是对索引库中索引的字段名称及数据类型进行定义，类似于mysql中的表结构信息。当然不指定mapping也是可以的，因为ES会自动根据数据格式识别它的类型。如果你需要对某些字段添加特殊属性(例如:定义使用其他分词器、是否分词、是否存储等)就必须手动添加mapping。注：实际使用都会指定mapping。

在ES中添加数据不指定数据类型时，ES会有自动映射机制(dynamic mapping)；对字符串映射为string，数字映射为long。

索引中的每个文档都有一个类型Type(Sql中的table)，每个类型(Type)拥有自己的映射(mapping)或者叫模式定义(schema definition)。映射除了前面说的定义了字段名称、字段数据类型以外还定义字段被ES处理的方式。例如所有Doc在写进索引之前都会先进行分析，如何将输入的文本分割为词条、哪些词条又会被过滤等都是映射(mapping)的一部分。

查看mapping：

#没有type_name可以
GET /index_name/_mapping
#有type_name也可以
GET /index_name/type_name/_mapping

ES的数据类型：

字符串类型: keyword、text
数字类型: interger long
小数类型: float double
布尔类型: boolean
日期类型: date


注:keyword一般用于关键词、关键词；text存储一段文本。
两者的本质区别是text会分词,keyword不会分词。

注：ElasticSearch与关系型数据库的类比！！！！

关系型数据库（比如Mysql）	非关系型数据库（Elasticsearch）
数据库Database	索引Index
表Table	类型Type
数据行Row	文档Document
数据列Column	字段Field
约束 Schema	映射Mapping

explicit mapping：

除了默认的动态映射(dynamic mapping)我们显然也是可以明确指定mapping的，即explicit mapping(明确映射)。原因很简单我们肯定比ES猜测的要准确，我们可以指定我们想要的mapping。我们可以指定每个字段(field)的数据类型、也可以指定是否对每个字段建索引。

如下指定employee-id字段的类型为keyword，另外执行了这个字段 index 参数值为false。后者的含义是employee-id字段只被存储不被索引(此时该字段不能被聚合和搜索)。

The index option controls whether field values are indexed. It accepts true or false and defaults to true.

PUT /my-index-000001/_mapping
{
  "properties": {
    "employee-id": {
      "type": "keyword",
      "index": false
    }
  }
}

注：默认情况下ES会自动为其索引的每个文档的每个字段创建映射(这里理解为创建索引)。每个被映射的字段在磁盘上都会对应一些数据结构，有了这些结构才能对该字段进行高效的搜索、聚合，有关每个映射字段的详细信息也保存在内存中。然而在很多情况下这种开销不是必须的，当你知道某个字段完全不会用于聚合和搜索的时候我们就可以利用前面说的explicit mapping来避免这种开销。

12.9.2、设置某字段只索引不存储

elasticsearch设置字段不索引，或源数据只索引不存储_es字段不建索引-CSDN博客

es的_source ,index,store重要字段的理解！！！！！！_健康平安的活着的博客 - java技术圈 - java技术社区

Elasticsearch的mapping设置：enabled, index, doc_values, store, _source到底是什么鬼？ | IdeaWand

mapping:

        {
        "_source": {
            "enabled": false
        },
        "_all": {
            "enabled": true,
            "store": false,
            "analyzer": "index_ansj"
        },
            "properties": { 
            "content": { "store": false,"search_analyzer": "query_ansj","analyzer": "index_ansj","term_vector": "with_positions_offsets","type": "string"},
            "no": { "index": "not_analyzed","store": true,"type": "string"}
            }
        }

增加数据：
{"content":"我是一个中国人","no":1}

1.2.10、索引别名(aliases)

一个索引别名可以映射到多个真实索引。

Elasticsearch Index Aliases详解_中间件兴趣圈-CSDN博客_is_write_index

1.2.11、索引模板(_template)

实际工作中对于源源不断产生的大量数据周期性的创建新索引是非常普遍的操作。如果每次都手动指定索引库的配置信息(settings和mappings)的话会非常麻烦。这个时候就有创建索引模板的必要了！

索引可使用预定义的模板进行创建，这个模板称为Index templates。模板设置包括settings、mappings这些东西，通过模式匹配的方式可以实现所有索引重用一个模板。

模板样例：

{
  "order": 0,                               // 模板优先级
  "template": "sample_info*",               // 模板匹配的名称方式
  "settings": {...},                        // 索引设置
  "mappings": {...},                        // 索引中各字段的映射定义
  "aliases": {...}                          // 索引的别名
}

#实际创建模板的时候将其上面一坨put进行就好了如
PUT /_template/es_qidian_flow_oa_template
{
    #上面那一坨
}

关于order：

有的时候会有多个模板，如果恰好匹配上了两个或多个模板那么要怎么生成索引呢？

ES 会按照一定的规则来尝试自动 merge 多个都匹配上了的模板规则，最终运用给到索引上。在某些方面命中的两个模板配置可能是不一样的这个时候应该用谁的呢？其实template 是可以设置 order 参数的！不写这个参数，默认的 order 值就是 0。order 值越大，在 merge 规则的时候优先级越高。