ES是一个搜索引擎，同时它也是一个分布式文档存储数据库（当然是非关系型的）。为了保证后续的实战教程顺利进行，这里通过对比传统的关系型数据库MySQL介绍在ES中的一些术语。
在MySQL中共有数据库（Database）、表（Table）、记录（Row）、列（Column）的概念，同样在ES中也有类似的概念，索引（Index），类型（Type），文档（Document），字段（Field）。
可以这么理解：
| | 数据库 | 表 | 记录 | 列 |
| ----- | ------ | -------- | -------- | ------ |
| MySQL | DB | Table | Row | Column |
| ES | Index | Document | Document | Field |
### 索引Index
ES中的索引概念可不是关系型数据库中的“索引”，ES中的索引指的是存储数据的地方，类似关系型数据库中的数据库概念。
### 类型Type
有的文章指出ES中的类型Type对应的就是关系型数据库中的表，在使用ES中我们会遇到另外一个概念**映射（Mapping）**，也有不少的文章指出Mapping对应的就是关系型数据库中的表。关系型数据库中表与表是物理独立的，即使在两个表中存在相同名称不同类型的列，这在我们的关系型数据库也是极为合理的，但这在ES中就不合理，ES中即使是在同一个索引Index下，如果字段Field存在于不同的类型Type中，即使他们代表不同的含义，但是只要它们的**名称相同也必须要求类型相同**，在ES中类型Type对应于关系型数据库中表的概念已经名存实亡。实际上在ES中Type作为表的概念在后期版本中越来越被弱化，在未被ES正式移除前，ES后期版本已经不允许一个索引Index创建多个Type，相信在后面的版本会彻底移除类型Type。
（注：ES6已经不允许一个Index创建多个Type，[https://github.com/elastic/elasticsearch/pull/24317](https://github.com/elastic/elasticsearch/pull/24317)）
如果在现阶段一定要理解ES中的Type，那么一定要和Mapping结合起来。可以理解为类型Type就是定义一个表，仅仅是定义而已，而映射Mapping定义了表结构（有哪些列，列的类型是什么）。
### 文档Document
在非关系型数据库中，有部分被称之为“文档数据库”，对应于关系型数据库中的一行记录。
### 字段Field
对应关系型数据库中的列。
### 节点
一个ES实例称之为一个节点，单机部署的ES有且只有一个节点，集群部署的ES有多个节点且有一个主节点。
### 分片
ES可作为分布式集群部署，同样也可以作为单机单节点部署。ES中的数据被分散存储在分片中，ES屏蔽了底层的分片实现，我们直接与索引交互而不与分片交互。分片数量的多少与是否是集群部署和单机部署无关，即使是单机部署在创建索引时仍然也可以指定划分多个分片（默认5个主分片1份备份（包含5个备分片））。分片有主分片和备分片之分，顾名思义，备分片是主分片的备份，当主分片出现故障时，备份片充当主分片。
#### 对于单机部署
单机部署的ES，即表示ES有且只有一个节点，在创建索引时，如果不指定主分片与备分片的数量，默认创建5个主分片和1份备份（5个备分片），实际上对于单机部署的ES服务来讲，多个主分片并没有意义，多个分片存在的意义本身就是将数据分散存储到多个ES节点中进行同时查询，此时只有一个节点多个分片也没有意义。备分片在单机部署中同样也没有意义，备份存在的意义本身就是当主分片故障时，仍然能对外提供服务，此时主备都在一个节点上，如果主分片故障，备分片也同样会导致故障。
#### 对于集群部署
对于集群部署的ES来讲，此时存在多个节点，主分片的分配与备分片机制就显得尤为重要（这涉及查询性能以及服务高可用），例如现在有3个节点，此时如果在创建索引时只分配1个主分片就显得有点浪费（注：主分片一旦在创建索引时确定便不能修改）。主分片的划分并没有一定放之四海而皆准的规则，更多的是取决于用户的数据量以及ES节点数量等。通常所理解的是，分片数量越多越好，因为这能将数据分散到不同分片，以便以后在扩容新增节点时，ES能将自动将分片重新进行均匀分布。但这条理论也不绝对，如果你的节点只有3个，设置了100个分片，每个节点就有33个节点，当搜索请求调度到同一节点的不同分片时，此时会引发硬件资源（CPU）的抢夺，造成性能问题。反过来，如果3个节点只分配了3个分片，随着业务的发展，数据量越来越大，单个分片已不能承受它最大的数据量，此时就算新增节点，但是分片数量只有3个，分片的数量在创建索引时便确定且不可修改，此时只能通过重新创建索引。
既要对合理的数据增长有一个判断（规划较大的分片），又要对期望有一个度的把握（合理的分片数量）。官方给出了一点建议，每个分片的数据量最好是在20G~40G左右，这就意味着如果你有4个节点，数据量预估在200G左右甚至更大，此时分片数量设置为5~10个比较合适，7、8个差不多，每个节点有2个分片。（官方博客的建议，[https://www.elastic.co/cn/blog/how-many-shards-should-i-have-in-my-elasticsearch-cluster](https://www.elastic.co/cn/blog/how-many-shards-should-i-have-in-my-elasticsearch-cluster)）
上面谈到的是主分片，副分片的划分也同等重要。如果不对分片备份，主分片故障则导致数据丢失，部分数据不可查询。副本分片设置过多造成额外的存储空间，默认情况下，创建索引时会创建一个分片副本（一个分片副本不代表一个备分片，如果有5个主分片，那么分片副本就有5个备分片，同理如果指定创建两个分片副本，此时一共就有10个备分片。）需要注意的是备分片是可以修改的，所以备分片可以直接采用默认一个分片副本。