ElasticSearch-分片如何影响索引性能？

我正在对ElasticSearch的单节点集群进行一些基准测试。

我面对这样的情况，更多的分片将至少在单个节点中降低索引性能（延迟和吞吐量）

这些是我的一些数字：

使用批量API的结果相同。所以我想知道这是什么关系，为什么会这样呢？

注意：我没有资源问题！资源是免费的（CPU和内存）

您的数据按索引组织，每个索引由分片组成，并分布在多个节点上。如果需要为新文档建立索引，则将生成新的ID，并根据该ID计算目标分片。之后，将写操作委派给该节点，该节点保存计算出的目标分片。这样可以将文档很好地分布在所有分片上。

现在，通过id查找文档非常容易，因为包含所需文档的分片可以仅基于id进行计算。无需搜索所有碎片。顺便说一句，这就是为什么您以后不能更改分片数量的原因。更改的分片编号将导致整个分片上的文档分布不同。

现在，为了清楚起见，每个分片都是一个单独的Lucene索引，由位于磁盘上的段文件组成。编写时，将创建新的段。如果将达到特定数量的段文件，则将合并这些段。因此，仅引入更多的分片而不将它们分配给其他节点，只会为单个节点引入更高的I

/ O和内存消耗。搜索时，将针对每个分片执行查询。之后，所有分片的结果需要合并为一个结果-更多分片，更多的cpu工作要做…

对于您的写重索引情况，只有一个节点，索引和分片的最佳数量为1！但是对于搜索情况（不按ID进行访问），每个节点的最佳分片数是可用的CPU数。这样，可以在多个线程中进行搜索，从而获得更好的搜索性能。

但是分片有什么好处？

因此，如果您的方案写的很繁琐，请使每个索引的分片数量保持较低。如果需要更好的搜索性能，请增加分片的数量，但要牢记“物理”。如果需要可靠性，请考虑节点/副本的数量。

进一步阅读：

https://www.elastic.co/guide/zh-

CN/elasticsearch/reference/current/_basic_concepts.html

https://www.elastic.co/guide/zh-CN/elasticsearch/reference/current/tune-for-

indexing-

speed.html

https://www.elastic.co/guide/zh-CN/elasticsearch/reference/current/tune-for-

search-

speed.html

https://www.elastic.co/de/blog/how-many-shards-should-i-have-in-my-

elasticsearch-cluster

https://thoughts.t37.net/designing-the-perfect-elasticsearch-cluster-the-

almost-definitive-guide-e614eabc1a87