您的数据按索引组织，每个索引由分片组成，并分布在多个节点上。如果需要为新文档建立索引，则将生成新的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
602392714
清零编程群