我们在14个节点的集群中安装了嵌入式Elasticsearch的Java应用程序。所有数据都驻留在中央数据库中，并在elasticsearch中编制索引以进行查询。完整的重新索引可以随时完成。
系统非常查询，写入量很小。文件数量不会高于300.000。 每个文档的大小差别很大，从几个ID到几页的单词文档中提取的文本。
我想确保在完全崩溃的情况下，一个或两个节点可用于系统工作就足够了。
写入一致性应该不是问题，因为数据的主副本在数据库中，并且似乎ES能够通过使用最新版本解决冲突数据（在我们的情况下应该可以正常）
我的第一个是使用1个碎片和13个复制品。这自然会确保所有节点都可以访问所有数据。这也可以通过拥有2个分片/ 13个副本来完成，因此这样可以确保所有数据都可用，副本的数量应该是节点的数量 - 1，而不是取决于分片的数量（可以是任何数据） ）。
如果节点数量的要求减少到“2个节点应该随时增加”，那么“x /节点数量-2”的分片/副本分配就足够了。
所以，对于这个问题：
断言上面的设置并且我的想法是正确的，1个shard / 13个副本的设置是否有意义，或者通过添加更多分片并运行例如4个分片/ 13个副本设置可以获得什么？
答案 0 :(得分：0)
经过一番研究并与ES-gurus交谈后;
只要分片大小足够小，设置此群集的最有效方法实际上只有1个分片，有13个副本。我无法确定分片的阈值大小，因此开始表现更差。
答案 1 :(得分：0)
如果索引很大......你需要多个分片（如果你想要性能）。你真的需要13复制品吗？当你只放置2个副本时，ES管理它以保持这种方式，如果主节点失败，ES将创建一个新的回复。可能你也需要一个平衡器节点。