如果有人能够为每个ES节点建议最佳分片数以获得最佳性能，或者提供任何建议的方法来获得应该使用的分片数量，我将不胜感激，考虑到内核数量和内存占用量。
答案 0 :(得分：51)
我来晚了，但我只是想指出几件事：
重点是分片的索引和查询都有固有的成本。每个分片实际上是一个单独的Lucene索引。当您运行查询时，Elasticsearch必须针对每个分片运行该查询，然后将各个分片结果一起编译以提供最终结果以进行发送。分片的好处是索引可以分布在群集中的节点上以获得更高的可用性。换句话说，这是一种权衡。
最后，应该注意每个节点超过1个分片将引入I / O注意事项。由于必须单独索引和查询每个分片，因此具有2个或更多分片的节点将需要2个或更多单独的I / O操作，这些操作不能同时运行。如果您的节点上有SSD，则可以降低实际成本，因为所有I / O都会更快 。不过，还有一点需要注意。
那么，那就引出了为什么你想要每个节点有多个分片的问题？答案就是计划的可扩展性。索引中的分片数是固定的。稍后添加更多分片的唯一方法是重新创建索引并重新索引所有数据。取决于索引的大小，这可能是也可能不是什么大不了的事。在撰写本文时，Stack Overflow的索引是203GB（参见：https://stackexchange.com/performance）。重新创建所有数据非常重要，因此重新分配将是一场噩梦。如果您有3个节点和总共6个分片，这意味着您可以在以后轻松扩展到最多6个节点，而无需重新分片。答案 1 :(得分：8)
在分片之前你需要考虑三个条件..
情况1） 您希望将elasticsearch与故障转移和高可用性结合使用。然后你去分片。 在这种情况下，您需要根据要在生产中使用的节点数[ES实例]来选择分片数。
考虑一下你想在生产中提供3个节点。然后，您需要为每个索引选择1个主分片和2个副本。如果您选择的碎片多于您需要的碎片。
情况2） 您当前的服务器将保留当前数据。但是由于未来动态数据的增加，你可能最终没有磁盘上的空间，或者你的服务器无法处理太多的数据，那么你需要配置更多的分片，比如2或3个分片（它符合你的要求）为每个索引。但是不应该有任何复制品。
在情况1＆amp; 2.然后你需要结合两种配置。考虑您的数据动态增加，您还需要高可用性和故障转移。然后配置一个包含2个分片和1个副本的索引。然后，您可以在节点之间共享数据并获得最佳性能..！注意： 然后将在每个分片中处理查询并对所有分片的结果执行mapreduce并将结果返回给我们。因此，地图缩减过程是昂贵的过程。最小分片为我们提供了最佳性能
如果您在生产中仅使用一个节点，那么每个索引只有一个主分片是最佳分片。
希望它有帮助..！
答案 2 :(得分：5)
每个节点有多个主分片也许是个好主意，具体取决于用例。我发现批量索引很慢，只使用了一个CPU内核 - 所以我们有空闲的CPU功率和非常低的IO，绝对硬件不是瓶颈。显示的线程池统计信息，在索引期间只有一个批量线程处于活动状态。我们有很多分析器和复杂的标记器（德语单词的分解分析）。每个节点越来越多的分片导致更多的批量线程处于活动状态（节点上每个分片一个），并且它显着提高了索引的速度。
答案 3 :(得分：5)
刚从配置10 TB的日志存储中恢复过来让我们进行分享：D
主要来源：The definitive guide to elasticsearch
HEAP：最多32 GB ：
如果堆小于32 GB，JVM可以使用压缩指针，这会节省大量内存：每个指针4个字节而不是8个字节。
HEAP：最多50％的服务器内存。其余的留给文件系统缓存（因此64 GB服务器是常见的最佳位置）：
Lucene充分利用了由内核管理的文件系统缓存。没有足够的文件系统缓存空间，性能将受到影响。此外，专用于堆的内存越多意味着使用doc值的所有其他字段的可用内存越少。
[索引拆分] N个分片可以将负载分散到N个服务器：
1个分片可以使用来自1个节点的所有处理能力（它就像一个独立的索引）。分片索引的操作在所有分片上同时运行，结果汇总。
更少的碎片更好（理想的是1个碎片）：
分片的开销很大。请参阅此基准数字https://blog.trifork.com/2014/01/07/elasticsearch-how-many-shards/
服务器越少越好（理想的是1台服务器（带有1个分片）]）：
索引上的负载只能通过分片在节点之间分割（分片足以使用节点上的所有资源）。更多的分片允许使用更多的服务器，但是更多的服务器会带来更多的数据聚合开销...没有免费的午餐。
我们将所有内容放在一个大索引中，让elasticsearch完成与分片数据相关的所有艰苦工作。应用程序中没有任何逻辑，因此更容易开发和维护。
假设我们计划将来索引最多为111 GB，并且我们的云提供商已经拥有50 GB服务器（25 GB堆）。
这意味着我们应该有5个分片。
注意：大多数人倾向于高估他们的成长，尽量做到现实。例如，这个111GB的例子已经是一个BIG索引。为了进行比较，stackoverflow索引是430 GB（2016），它是全球排名前50的网站，完全由数百万人的书面文本构成。
如果单个索引的数据太多或管理起来太烦人，那么下一步就是按时间段拆分索引。
最极端的例子是记录每天使用新索引的应用程序（logstach和graylog）。
每个索引的单个分片的理想配置在场景中非常有意义。如有必要，可以调整索引循环周期，以使索引保持小于堆。
特殊情况：让我们设想一个有月度指数的热门互联网论坛。 99％的请求都是最后一个索引。我们必须设置多个分片（例如3个）以在多个节点上分散负载。 （注意：这可能是不必要的优化。在现实世界中不太可能达到99％的命中率，并且碎片副本可以分配部分只读加载。）
ElasticSearch很神奇。它是在群集中设置的最简单的数据库，它是能够扩展到多个节点（Spanner除外）的极少数数据库之一。
可以使用数百个弹性搜索节点进行exascale。必须有许多索引和分片来分散那么多机器上的负载，并采用适当的分片配置（最终根据索引进行调整）。
魔术的最后一点是将elasticsearch路由调整为针对特定操作的特定节点。
答案 4 :(得分：0)
我还没有对此进行测试，但是aws对ES best practises有很好的了解。请看Choosing Instance Types and Testing部分。
答案 5 :(得分：0)
如果您的数据可以按逻辑部分拆分，并且您的查询通常是针对性的，那么根据该逻辑进行分片以获得“自定义路由”机制的好处是个好主意。
例如，您拥有50个州的房地产数据，并且总是按1个或多个州查询，您将根据州名称创建50个分片和路线。
不要盲目地向所有分片广播，而是告诉Elasticsearch“嘿！搜索此分片上的数据！就在那里，我保证！“例如，您可以根据state_code路由文档。或者他们的邮政编码或邮编。或者在您的应用程序中通常搜索/过滤的任何内容。
路由确保具有相同路由值的所有文档都将定位到同一分片，从而无需广播搜索。
详情请见此处： https://www.elastic.co/blog/customizing-your-document-routing
如果您的问题适合自定义路由所服务的市场，则可能会显着提高性能。
答案 6 :(得分：0)
Elastic.co recommends至：
[…]将每个节点的分片数量保持在已配置的每GB堆20个以下