ElasticSearch分布式搜索，如何理解Shards和Replicas

我们相信：世界是美好的，你是我也是。平行空间的世界里面，不同版本的生活也在继续...

贯穿于ElasticSearch分布式搜索的过程中，有两个基本概念Shards和Replicas。本文试图通过苏南大叔自己的理解，来对这两个概念进行一下通俗化的理解。和官方的说法肯定有出入，仅仅是自己的理解而已。

苏南大叔的“程序如此灵动”博客，记录苏南大叔的代码编程经验总结。本文测试环境：win10，elasticsearch@8.17.1，kibana@8.17.1。Shards和Replicas是ElasticSearch中的两个重要概念，它们在ElasticSearch的分布式搜索和数据管理中起着关键作用。‌

前文回顾

出于测试目的，测试机上面仅仅会安装一个ElasticSearch实例。

• Shards意思是分片，至少有一个分片。
• Replicas意思是副本，如果不需要副本备份的话，必然可以设置为零个副本了。

在前面的文章里面，为了测试ElasticSearch的分布式集群特性，苏南大叔又开启了一个ElasticSearch的从节点。从而，为本文的Shards和Replicas概念解释，留下了可能性。参考文章：

• https://newsn.net/say/elastic-cluster.html

查看已有设置

ElasticSearch里面的索引的概念，可以理解为普通数据库中的表。所以，ElasticSearch装在索引里面的文档，也就是表里面的数据了。

shards和replicas，是建立在索引的概念基础上的。如果没有索引，那么也就没有shards和replicas的概念。可以通过下面的方法，查看每个索引的shard和replica的数量。（范例中的索引名为my_index）

GET /my_index/_settings?pretty

shards 分片

注意拼写，并不是shares，所以并不是"分享"。官方解释shards为【分片(s)】，单数shard，百度翻译里面翻译为【碎片】。翻译成碎片的话，其实更好理解。它解决的问题，就是“工作分担”的问题。

每个索引里面文档，可以分布式存储在多个shards节点里面。那么，这些待检索的文档，分步在多个节点上之后，在搜索的时候，就可以并行处理了，性能上就会有更好的性能提升。可以理解为“人多力量大”，节点多，每个节点负责的数据就少，处理的速度就更快了。

对于一个elastic search的索引来说，它的shards数量一旦设置好，就不应该变动。因为文档到底存放在哪个服务器上，是有公式的。其中的shards数量就是重要变量因素。

Replicas 副本

‌Replicas官方翻译是副本(s)，单数replica，百度翻译为“复制品/仿品”。所以，它解决的问题就是“数据冗余”的问题，注意不是要消除“冗余”，而是创造“冗余”。它要解决的问题，就是“数据的可用性”。

它为每个shard分区，都创造N个副本，然后，这些副本又分步在不同的节点上。那么，就最大限度的保证了数据的可用性。

• 某个节点发生故障时，该节点上的shard如果有Replica存在于其他节点上，那么这些副本就可以保证数据不会丢失，并且服务还可以继续运行。
• 读取操作（如搜索请求）可以在所有副本之间进行负载均衡，这样可以提高查询的吞吐量和响应速度‌。

经验值建议

在创建索引时可以指定Shards和Replicas的数量。默认情况下，一个Index有5个Shards和1个Replica。通常，Shards的数量应该设置为节点数量的平方根，例如一个拥有10个节点的集群，建议将Shards设置为5或7。Replicas的数量可以根据数据的可用性和查询需求进行调整，通常设置为1到2个‌。

总结

所以，对于分区和副本来说，必须有分区，可以没有副本。但是，建议设置副本。从数据在节点上的分步来说，你中有我，我中有你。所有文档，按着分区，分布在不同的节点上。又在不同的节点上，存储了自己的多个副本。

更多elastic search经验文章，请点击：

• https://newsn.net/tag/elastic/

如果本文对您有帮助，或者节约了您的时间，欢迎打赏瓶饮料，建立下友谊关系。
本博客不欢迎：各种镜像采集行为。请尊重原创文章内容，转载请保留作者链接。