number_of_replicas副本数,用于备份分片的,和分片里面的数据保持一致,主要响应读操作,副本越多读取就越快。此外,副本数是可以修改的。但是在集群环境中,副本数应小于等于节点数减1,否则会降低集群的健康值。
我们前面说,一个节点应该只有一个主分片。但是实际中,我们需要预估一下将来的分片数,并且提前做规划。在《Elastic Search权威指南》中,提到了扩容设计。其中指出,在初期,我们可以只有一个节点,并且可以在该节点中建立多个主分片。当访问量增加,节点负荷过大时,我们可以增加新的节点,更加奇妙的是Elasticsearch 会自动将其中部分分片移动至到新的节点。就如下图所示
扩容设计
引自:https://www.elastic.co/guide/cn/elasticsearch/guide/current/overallocation.html
此外,新的版本的副本复制策略同6.6不太一样,具体可以参考https://www.jianshu.com/p/a164b86445b6

五、文档,元数据

1,文档
在大多数应用中,多数实体或对象可以被序列化为包含键值对的 JSON 对象。 一个键 可以是一个字段或字段的名称,一个值 可以是一个字符串,一个数字,一个布尔值, 另一个对象,一些数组值,或一些其它特殊类型诸如表示日期的字符串,或代表一个地理位置的对象
2,文档元数据
一个文档不仅仅包含它的数据 ,也包含元数据 ——有关 文档的信息。 三个必须的元数据元素如下:
_index
文档在哪存放
一个索引 应该是因共同的特性被分组到一起的文档集合。 例如,你可能存储所有的产品在索引products中,而存储所有销售的交易到索引sales中。 虽然也允许存储不相关的数据到一个索引中,但这通常看作是一个反模式的做法。
实际上,在Elasticsearch 中,我们的数据是被存储和索引在分片 中,而一个索引仅仅是逻辑上的命名空间, 这个命名空间由一个或者多个分片组合在一起。 然而,这是一个内部细节,我们的应用程序根本不应该关心分片,对于应用程序而言,只需知道文档位于一个索引 内。 Elasticsearch 会处理所有的细节。
_type
文档表示的对象类别
数据可能在索引中只是松散的组合在一起,但是通常明确定义一些数据中的子分区是很有用的。 例如,所有的产品都放在一个索引中,但是你有许多不同的产品类别,比如 "electronics" 、 "kitchen" 和"lawn-care"。
需要注意的是,Elastic Search 6之后,_type 只有一个,而到了Elastic Search 7 之后,取消了 _type。

为什么 _type 被移除了?

起初,我们说"索引"和关系数据库的“库”是相似的,“类型”和“表”是对等的。这是一个不正确的对比,导致了不正确的假设。在关系型数据库里,"表"是相互独立的,一个“表”里的列和另外一个“表”的同名列没有关系,互不影响。但在类型里字段不是这样的。在一个Elasticsearch索引里,所有不同类型的同名字段内部使用的是同一个lucene字段存储。也就是说,上面例子中,user类型的user_name字段和tweet类型的user_name字段是存储在一个字段里的,两个类型里的user_name必须有一样的字段定义。这可能导致一些问题,例如你希望同一个索引中"deleted"字段在一个类型里是存储日期值,在另外一个类型里存储布尔值。最后,在同一个索引中,存储仅有小部分字段相同或者全部字段都不相同的文档,会导致数据稀疏,影响Lucene有效压缩数据的能力。因为这些原因,我们决定从Elasticsearch中移除类型的概念。