我正在对 ElasticSearch 的单节点集群进行一些基准测试。
我遇到的情况是更多的碎片会减少 索引性能-至少在单个节点中-（延迟和吞吐量）
这些是我的一些数字：
我使用批量 API 得到了相同的结果。所以我想知道这是什么关系以及为什么会发生这种情况？
注意：我没有资源问题！资源免费（CPU 和内存）
【问题讨论】：
标签： elasticsearch
只是为了让你在同一个页面上：
您的数据按索引组织，每个索引都由分片组成并分布在多个节点上。如果需要索引一个新文档，则会生成一个新的 id，并根据该 id 计算目标分片。之后，将写入委托给节点，该节点持有计算的目标分片。这将在您的所有分片中很好地分发您的文档。
现在通过 id 查找文档很容易，因为包含所需文档的分片可以仅根据 id 计算。无需搜索所有分片。顺便说一句，这就是为什么您之后不能更改分片数量的原因。更改的分片编号将导致您的分片之间的文档分布不同。
现在，为了清楚起见，每个分片都是一个单独的 lucene 索引，由位于磁盘上的段文件组成。写入时，将创建新的段。如果达到特定数量的段文件，则将合并这些段。 因此，仅引入更多分片而不将它们分配到其他节点只会为您的单个节点引入更高的 I/O 和内存消耗。 搜索时，将对每个分片执行查询。之后需要将所有分片的结果合并为一个结果 - 更多分片，更多 cpu 工作要做......
回到你的问题：
对于您的写入繁重的索引情况，只有一个节点，索引和分片的最佳数量是 1！
但是对于搜索情况（不通过 id 访问），每个节点的最佳分片数是可用的 CPU 数。这样，可以在多个线程中进行搜索，从而获得更好的搜索性能。更正：搜索和索引是多线程的，单个分片可以充分利用一个节点的所有 CPU 内核。
但是分片有什么好处呢？
可用性：通过将分片复制到其他节点，如果您的某些节点无法再访问，您仍然可以提供服务！
性能：将主分片分配到不同的节点，也将分配工作负载。
因此，如果您的方案写入繁重，请尽量减少每个索引的分片数量。如果您需要更好的搜索性能，请增加分片数量，但请牢记“物理”。如果您需要可靠性，请考虑节点/副本的数量。
进一步阅读：
https://www.elastic.co/guide/en/elasticsearch/reference/current/_basic_concepts.html
https://www.elastic.co/guide/en/elasticsearch/reference/current/tune-for-indexing-speed.html
https://www.elastic.co/guide/en/elasticsearch/reference/current/tune-for-search-speed.html
https://www.elastic.co/de/blog/how-many-shards-should-i-have-in-my-elasticsearch-cluster
【讨论】：
我遇到了更多分片会减少索引的情况 性能 - 至少在单个节点中 - （包括延迟和 吞吐量）
供参考：Elasticsearch 是一个分布式数据库。数据存储在“索引”中，索引被拆分为“碎片”。每个“分片”都分配在一个节点上（如果可能，分配一个不同的节点）。
拥有更多分片可以使用更多机器。这就是“分布式数据库”中“分布式”的实际工作方式。 Elasticsearch 将在后台自动分配和移动分片，以平衡所有机器的磁盘使用情况。
使用 1 个分片，数据被拆分到一个节点，这为您提供了每秒 N 次读取和 M 次写入的基线。
使用 3 个分片，数据被拆分到三个节点上，这为您提供了 3 倍的吞吐量。
当然这是假设有 3 台机器可用。如果只有一台机器，那么无论哪种方式，这台机器都在做所有的处理，拥有更多的分片没有任何影响。
分片有一点开销，必须分配查询并合并返回结果，因此将分片数量加倍不会使性能完全翻倍（预计大约 +90%）。
您的集群只有一台机器。增加分片数量会降低性能，因为它只会增加开销。
附：默认情况下，分片有一个副本，如果主分片消失（机器故障），副本将接管，这就是弹性的工作原理。具有 5 个分片和 5 个副本的索引可以充分利用 10 个节点。这意味着使用许多节点只需要很少的分片。
P.P.S 根据我的经验，shard=5 的配置是最大值。除非使用大型集群（10 多台机器）或 TB 级索引，否则您永远不应设置更多。
【讨论】：