elasticsearch 高可用性的碎片/副本设置

我们有一个java应用程序，在14个节点的集群中嵌入了Elasticsearch。所有数据都驻留在一个中央数据库中，并在elasticsearch中索引以进行查询。可以随时进行完全重新索引

系统的查询量很大，写入量很小。文件的数量不会超过，比如说，300.000份。 每个文档的大小差别很大，从几个ID到从多个页面的word文档中提取的文本

我想确保在出现全面故障的情况下，一个或两个节点足以让系统工作

写一致性不应该是一个问题，因为数据的主副本在数据库中，而且ES似乎能够通过使用最新版本来解决冲突数据（在我们的情况下这应该是正确的）

我的第一个想法是使用1个碎片和13个副本。这自然会确保所有节点都可以访问所有数据。这也可以通过拥有2个碎片/13个副本来实现，因此为了确保所有数据都可用，副本的数量应该是节点的数量-1，而不是取决于碎片的数量（可以是任何数据）

如果将节点数量的要求减少到“随时应启动2个节点”，则“x/节点数量-2”的碎片/副本分布就足够了

因此，对于问题：

---

断言上述设置并且我的想法是正确的，使用1个碎片/13副本的设置有意义吗，或者添加更多碎片并运行例如4个碎片/13副本设置会有什么好处吗？

经过一番研究并与ES专家交谈后

---

只要碎片大小足够小，建立这个集群的最有效方法就是只使用1个碎片，13个副本。我无法精确地确定碎片的阈值大小，因为它的性能开始变差

如果指数很大。。。您将需要多个碎片（如果您想要性能）。你真的需要13个复制品吗？当您仅放置2个副本时，ES将管理该副本以保持这种状态，如果主节点出现故障，ES将创建一个新的应答。可能您也需要一个平衡器节点