elasticsearch 如何在不强制合并的情况下减少ElasticSearch lucene段,elasticsearch,lucene,elasticsearch,Lucene" /> elasticsearch 如何在不强制合并的情况下减少ElasticSearch lucene段,elasticsearch,lucene,elasticsearch,Lucene" />
Fatal编程技术网
  • elasticsearch/
  • elasticsearch 如何在不强制合并的情况下减少ElasticSearch lucene段

elasticsearch 如何在不强制合并的情况下减少ElasticSearch lucene段

lucene

elasticsearch 如何在不强制合并的情况下减少ElasticSearch lucene段,elasticsearch,lucene,elasticsearch,Lucene,我们有一个存储150万条记录的集群，总容量为3.5GB。每30分钟更新或创建约2-5k条记录。到目前为止，在对预先存在的数据进行大量索引之后，我们一直在强制合并，将段的数量从30-35减少到1，这大大提高了搜索的性能。几天后，分段的数量通常会上升，并在7或8左右趋于平稳，性能仍然正常 问题是我们计划将数据扩展到80GB左右。如果我们这样做，我担心的是在初始质量索引后使用强制合并，该段将大于5GB，此时将不考虑通过ElasticSearch进行自动合并，性能将降低。如果不使用强制合并，虽然我相信段

我们有一个存储150万条记录的集群，总容量为3.5GB。每30分钟更新或创建约2-5k条记录。到目前为止，在对预先存在的数据进行大量索引之后，我们一直在强制合并，将段的数量从30-35减少到1，这大大提高了搜索的性能。几天后，分段的数量通常会上升，并在7或8左右趋于平稳，性能仍然正常

问题是我们计划将数据扩展到80GB左右。如果我们这样做，我担心的是在初始质量索引后使用强制合并，该段将大于5GB，此时将不考虑通过ElasticSearch进行自动合并，性能将降低。如果不使用强制合并，虽然我相信段的数量会太多

有没有一种方法可以在不调用强制合并API的情况下强制弹性搜索进行更积极的优化？我们在晚上或周末都没有用户，因此理想情况下我们可以对其进行大规模索引，然后在整个周末对细分进行优化，使其数量减少，而不必担心在这段时间内的搜索性能