一、近实时
Near Realtime，也称NRT。这里包含两个含义
- 从数据写入到能被搜索到这个全过程会有1s左右的延迟
- 直接检索和分析海量数据，可以达到秒级。小数据量肯定毫秒级
二、天然支持集群
一个集群包含多个node（节点，至少两个，否则不叫集群），每个节点属于哪个集群是通过一个配置（集群名称，默认是elasticsearch）来决定的。启动多个es实例就自动构成一个集群。它默认会找9300-9305这端口范围的实例，官方有写：
https://www.elastic.co/guide/en/elasticsearch/reference/current/discovery-settings.html
三、Node
Node：节点。多个Node凑成一个集群，我理解每个Elasticsearch实例就是一个Node。
四、field
就是字段，一个document里可包含多个field，看完下面的document就明白了。
五、Document
文档，ES中的最小数据单元，通常用JSON表示，理解成mysql里的一条数据。
{
"id": 1,
"name": "小米",
"price": {
"型号1": 999,
"型号2": 1999,
"型号3": 2999
}
}
六、index
索引，包含一堆有相似结构的文档数据。举个例子：商品索引、用户索引这是两个完全不同的东西，所以建议弄两个index。 可以粗糙理解成mysql的库的概念。有点模糊？看完下面的type就懂了。
七、type
每个index下的具体分类。一个index可以有多个type。比如上面index举例的商品索引，下面可以包含家电商品、生鲜商品、生活用品等，可以粗糙理解成mysql表的概念。
八、小结以及注意
Index理解成数据库、type理解成数据表、document理解成数据行。一个index下有多个type，每个type下有多个document。
Elasticsearch已经将type这个概念去掉了，也就是只有index和document的概念，相当于index就对应到mysql的库表。
因为type的概念是错误的使用方式，毕竟在RDBMS中，表与表之间的数据是分割存储的，而ES中同一个索引的不同type数据最终是放在一起的，必须保证不同type之间同名field的类型一致，还不算其他乱七八糟的问题。设计上就不合理。
九、shard
分为两种：Primary Shard以及Replica Shard。
- 每个shard都可以理解成是一个lucene实例，负责搜索分析和倒排索引。
- 1个index默认包含5个Primary Shard和1个Replica Shard（这里的1个每个PrimaryShard都对应1个ReplicaShard），所以默认1个index一共有10个shard，5P5R。
- Replica Shard就是副本shard，理解成“从节点”。防止单点故障，减轻PrimaryShard的压力。
- Primary Shard的数量是创建index的时候设置的，如果后期想更改需要重建索引，代价很大。Replica Shard可以随时修改数量。
- 一个document的数据只能落到一个Primary上，但是可能落到多个Replica上
- ES会自动在nodes上为我们做shard的负载均衡。
假设只有1个index，每个index默认5P5R。假设只有一台node，那肯定这10个shard都在这一台node上，假设新增了一台node实例与之前的凑成了集群。那么ES会自动将这个shard平分到两台node上，比如：
Anode：2个PrimaryShard+3个ReplicaShard（这3个是Bnode中3P的副本，这样可以保证高可用）
Bnode：3个PrimaryShard+2个ReplicaShard（这2个是Anode中2P的副本，这样可以保证高可用）
- 实现最小高可用的node至少需要2个。
Primary和Replica不能同时存到同一个node上，否则这个node挂了就单点故障了 ，不叫高可用。
转载：https://blog.csdn.net/ctwctw/article/details/105977144