我们在一个14个节点的集群中嵌入了Elasticsearch的java应用程序。所有的数据都存储在一个中央数据库中，它们在elasticsearch中被索引以便查询。一个完整的索引可以在任何时候完成。
系统的查询量很大，写的量很小。文档的数量不会超过300.000个。每个文档的大小差别很大，有的只有几个id，有的从几个页面的word-documents中提取文本。
我想确保在完全崩溃的情况下，有一个或两个节点可供系统工作就足够了。
写一致性应该不是问题，因为数据的主副本在数据库中，似乎ES能够通过使用最新版本解决冲突的数据(在我们的情况下应该没问题)
我的第一个想法是使用1个分片和13个副本。这自然会确保所有节点都可以访问所有数据。这也可以通过拥有2个分片/13个副本来实现，因此这意味着为了确保所有数据可用，副本的数量应该是节点的数量- 1，而不是依赖于分片的数量(可以是任何东西)。
如果节点数量的要求减少到"2个节点在任何时候都应该是在线的"，那么"x/节点数量- 2"的分片/副本分布应该是足够的。
对于这个问题:
断言上述设置并且我的想法是正确的，那么1个分片/13个副本的设置是否有意义，或者通过添加更多分片并运行例如4个分片/13个副本的设置是否有任何收获?
经过一番研究并与es -guru交谈;
只要碎片大小足够小，设置这个集群的最有效的方法确实是只有1个碎片，有13个副本。我还不能精确地指出这个开始表现更差的分片的阈值大小。
如果索引很大…您将需要多个分片(如果您想要性能)。你真的需要13个复制品吗?当您只放置2个副本时，ES会设法保持这种方式，如果主节点失败，ES将创建一个新的回复。也许你也需要一个平衡器节点。