1.核心概念

Near Realtime（NRT）：近实时。从写入数据到数据可以被搜索到有一个小延迟（大概1秒）；基于es执行搜索和分析可以达到秒级
Cluster：集群，包含多个节点，每个节点属于哪个集群是通过集群名称（默认名称：elasticsearch）决定的
Node：集群中的一个节点，节点也有名称（默认是随机分配的），节点名称很重要（在执行运维管理操作的时候），节点会根据配置文件的集群名来加入集群。如果直接启动一堆节点，那么它们会自动组成一个elasticsearch集群，当然一个节点也可以组成一个elasticsearch集群。在ElasticSearch中每个Node都是公平的，都可以读写。master和slave的区别是：master可以维护集群状态、故障转移
shard：主分片。为了满足海量数据存储，es将一个index中的数据分开存储到多个shard中，分布在多台服务器上存储。有了shard就可以横向扩展，存储更多数据，让搜索和分析等操作分布到多台服务器上去执行，提升吞吐量和性能。每个shard都是一个lucene index。
replica：任何一个服务器随时可能故障或宕机，此时shard可能就会丢失，因此可以为每个shard创建多个replica副本。replica可以在shard故障时提供备用服务，保证数据不丢失，多个replica还可以提升搜索操作的吞吐量和性能。primary shard（建立索引时一次设置，不能修改，默认5个），replica shard（随时修改数量，默认1个），默认每个索引10个shard，5个primary shard，5个replica shard，最小的高可用配置，是2台服务器

Index：索引，包含一堆有相似结构的文档数据，比如可以有一个客户索引，商品分类索引，订单索引，索引有一个名称。一个index包含很多document，一个index就代表了一类类似的或者相同的document。比如说建立一个product index，商品索引，里面可能就存放了所有的商品数据，所有的商品document。
Type：类型，每个索引里都可以有一个或多个type，type是index中的一个逻辑数据分类，一个type下的document，都有相同的field，比如博客系统，有一个索引，可以定义用户数据type，博客数据type，评论数据type
Document&field：文档，es中的最小数据单元，一个document可以是一条客户数据，一条商品分类数据，一条订单数据，通常用JSON数据结构表示，每个index下的type中，都可以去存储多个document。一个document里面有多个field，每个field就是一个数据字段。

1.1 ES数据结构和数据库对比

Elasticsearch	数据库
Document	行
Type	表
Index	库

2. 为什么ES 6.0+移除了type类型？

2.1 背景

起初，我们说"索引"和关系数据库的“库”是相似的，“类型”和“表”是对等的。这是一个不正确的对比，导致了不正确的假设。在关系型数据库里,"表"是相互独立的,一个“表”里的列和另外一个“表”的同名列没有关系，互不影响。
但在ES里type不是这样的，ES使用的是Lucence引擎，在一个index里，所有不同类型的同名字段内部使用的是同一个字段存储。这可能导致一些问题，例如你希望同一个索引中"deleted"字段在一个类型里是存储日期值，在另外一个类型里存储布尔值。
从Elasticsearch的第一个发布版本以来，每一条Document都被存储在一个单独的index里，每一条Document被赋予了一个type。type和index的关系为N：1，type和Document的关系为1：N

2.2 举个例子

一个index下，不同type一般会有相同的字段和不同的字段。假设：

user类型有full_name字段、user_name字段、个email字段。

tweet类型有content字段、tweet_at字段、user_name字段

每一个type都有一个_type元字段来存储type名称，并且根据URL里指定的typeName，搜索被限定在一个或多个类型(type)里:

GET twitter/user,tweet/_search
{
  "query": {
    "match": {
      "user_name": "kimchy"
    }
  }
}

_type字段用来和文档的_id字段联合生成_uid字段，所以有着相同_id的不同类型的文档可以存在同一个index里。type也可用来建立Document间的父子关系，所以A类型的Document可能是B类型Document的父亲。

2.2 为什么类型被移除了？

不同类型的type中相同名称的字段数据类型必须相同。上面例子中，user类型的user_name字段和tweet类型的user_name字段是存储在一个字段里的，两个类型里的user_name必须有一样的字段定义。
在同一个索引中，存储仅有小部分字段相同或者全部字段都不相同的文档，会导致数据稀疏，影响Lucene有效压缩数据的能力。
一个index只存储一种类型的Document的优点：
- lucene索引中数据比较整齐（相对于稀疏），利于lucene进行压缩。
- 文本相关性打分更加精确（tf、idf，考虑idf中命中文档总数）

2.3 type移除时间表

Elasticsearch 5.6.0

index.mapping.single_type设置为true后，索引将像6.x版本一样开启单type特性。
替代父子关系的join 字段在5.6里创建的索引是可用的

Elasticsearch 6.x

5.x创建的索引在6.x里继续有效，就像在5.x一样
在6.x里新建的索引只允许单个类型。这个类型可以被命名成任何名字，但是只能有一个类型。推荐的名字是_doc，这样index API 就和7.0里有一样的路径了：PUT {index}/_doc/{id} 和 POST {index}/_doc _type字段不再和_id一起组合成_uid字段了，_uid字段成为_id字段的别名
新的索引不再支持旧风格的父子关系，应该使用join 字段代替。
default 映射类型变为舍弃的
在6.7,索引创建、索引模板、映射API支持一个查询参数（include_type_name）,用来指示请求和响应是否包含一个tpye名字.默认值是true，对于准备升级到7.0的应该显式设置其值。不设置include_type_name 会导致一个警告。没有使用指定type的索引，将使用一个假定的名字_doc。

Elasticsearch 7.x

在请求中指定类型是不推荐的。因此，索引一个文档不再需要一个文档类型。新的索引文档API是PUT {index}/_doc/{id} (需要指定明确的id时)和POST {index}/_doc (自动生成id时)
include_type_name 参数再索引创建、索引模板、映射API中默认值为false。任何时刻设置这个参数将导致一个过期警告。 default 映射类型被移除

Elasticsearch 8.x

在请求里指定类型将不在被支持
include_type_name 参数被移除

3. 元数据

ES的搜索和插入都是基于元数据的，ES元数据分成三种类型：

index元数据
type元数据(ES6.0+默认类型名_doc)
id元数据

三种元数据的关系是，index元数据包含type元数据、type元数据包含id元数据。

举例：

写场景：插入一条id元数据，就必须指定index元数据和type元数据（ES6.0+默认名称_doc），当然也可以只插入index元数据，而不插入type元数据和id元数据。
读场景：搜索一条id元数据，就必须指定index元数据和type元数据（ES6.0+默认名称_doc），当然也可以只搜索index元数据。当搜索index元数据的时候，会把index下所有的type，type下所有的id都返回。

3.1 index元数据

index元数据含义：

index元数据代表一个document存放在哪个index中，一个document只能存放在一个index中，不能存放在多个index

index存放原则

类似的数据放在一个index，不类似的数据放不同inxex 类似的意思是：多个document的fields相差不大，如果多数个document的fields基本都不一样，就不适合放在一个index中。

命名规范

index名称必须是小写的，不能用下划线开头，不能包含逗号

3.2 type元数据

ES6.0+不建议使用多type，后续版本会废弃

3.3 id元数据

代表document的唯一标识，与index和type一起，可以唯一标识和定位一个document
我们可以手动指定document的id（put /index/type/id），也可以不指定，由es自动为我们创建一个id

ES入门篇3--核心概念