如果有人能够为每个ES节点建议最佳分片数以获得最佳性能,或者提供任何建议的方法来获得应该使用的分片数量,我会很感激,考虑到内核数量和内存占用量.
我迟到了,但我只想指出几件事:
每个索引的最佳分片数始终为1.但是,这不提供水平缩放的可能性.
每个节点的最佳分片数始终为1.但是,您不能水平缩放超过当前节点数.
重点是分片具有索引和查询的固有成本.每个分片实际上是一个单独的Lucene索引.当您运行查询时,Elasticsearch必须针对每个分片运行该查询,然后将各个分片结果一起编译以提供最终结果以进行发送.分片的好处是索引可以分布在群集中的节点上,以提高可用性.换句话说,这是一种权衡.
最后,应该注意每个节点超过1个分片将引入I/O注意事项.由于必须单独索引和查询每个分片,因此具有2个或更多分片的节点将需要2个或更多单独的I/O操作,这些操作无法同时运行.如果您的节点上有SSD,则可以降低实际成本,因为所有I/O发生得更快.不过,这是需要注意的事情.
那么,这就引出了为什么你想要每个节点有多个分片的问题？答案就是计划的可扩展性.索引中的分片数是固定的.稍后添加更多分片的唯一方法是重新创建索引并重新索引所有数据.取决于索引的大小,这可能是也可能不是什么大不了的事.在撰写本文时,Stack Overflow的索引是203GB(参见:https://stackexchange.com/performance ).这对于重建所有数据来说是一件大事,所以重新分配将是一场噩梦.如果您有3个节点和总共6个分片,这意味着您可以在以后轻松扩展到最多6个节点而无需重新分片.
在分片之前你有三个条件考虑..
情况1)您希望将elasticsearch与故障转移和高可用性结合使用.然后你去分片.在这种情况下,您需要根据要在生产中使用的节点数[ES实例]来选择分片数.
考虑一下你想在生产中提供3个节点.然后,您需要为每个索引选择1个主分片和2个副本.如果您选择的碎片多于您需要的碎片.
情况2)您当前的服务器将保存当前数据.但是由于未来动态数据的增加,最终磁盘上没有空间,或者您的服务器无法处理大量数据,因此您需要为每个索引配置更多的分片,如2或3个分片(根据您的要求).但是不应该有任何复制品.
情况3)在这种情况下,你是情况1和2的组合情况,那么你需要结合两种配置.考虑您的数据动态增加,您还需要高可用性和故障转移.然后配置一个包含2个分片和1个副本的索引.然后,您可以在节点之间共享数据并获得最佳性能..!
注意: 然后将在每个分片中处理查询并对所有分片的结果执行mapreduce并将结果返回给我们.因此,地图缩减过程是昂贵的过程.最小分片为我们提供了最佳性能
如果您在生产中仅使用一个节点,那么每个索引只有一个主分片是最佳分片.
希望能帮助到你..!
刚从配置一些10 TB的日志存储回来，所以让我们来谈谈分片：D
节点限制主要来源：elasticsearch的权威指南
堆：最多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），它们每天都在使用新索引。
每个索引1个单碎片的理想配置在场景中非常有意义。如有必要，可以调整索引轮换周期，以使索引小于堆。
特殊情况：让我们想象一个流行的带有月度索引的互联网论坛。99％的请求达到了最后一个索引。我们必须设置多个分片（例如3个）以将负载分散到多个节点上。（注意：这可能是不必要的优化。在现实世界中，99％的命中率是不可能的，而分片副本仍然可以分配一部分只读负载）。
ElasticSearch是魔术。它是在集群中最容易设置的数据库，并且是少数能够扩展到许多节点（不包括Spanner）的数据库之一。
百亿个Elasticsearch节点可能达到万亿级。必须有许多索引和分片才能在许多计算机上分散负载，并且需要采用适当的分片配置（最终根据索引进行调整）。
魔术的最后一点是将Elasticsearch路由调整为针对特定操作的特定节点。
每个节点有多个主分片可能也是个好主意,具体取决于用例.我发现批量索引很慢,只使用了一个CPU内核 - 所以我们有空闲的CPU功率和非常低的IO,绝对硬件不是瓶颈.显示的线程池统计信息,在索引期间只有一个批量线程处于活动状态.我们有很多分析器和复杂的标记器(德语单词的分解分析).每个节点越来越多的分片导致更多的批量线程处于活动状态(节点上每个分片一个),并且它显着提高了索引的速度.
京公网安备 11010802040832号 | 京ICP备19059560号-6 