让我们假设我有一个很大的索引，由5亿个文档组成，默认情况下，ES由于低于原因而创建5个主要碎片，我也使用相同的设置。
-
performance ： - 在碎片中搜索的时间较少，而没有文件(在我的用例中为1亿个(，而不是只有1个碎片和大量文档(5亿(。此外，允许跨碎片分配和并行化操作。
-
水平可扩展性(HS(： - 水平拆分/缩放内容卷。
但是，当我们默认搜索时，它只会到1片并给出结果。在这种情况下，相关性并不准确(因为IDF受到主要影响(，如果我的匹配文档在另一个碎片上，甚至可能不会给出任何结果。它称为碎片效果。
上面的问题在此处详细说明了以下2个选项可以避免此问题，但我认为这两个解决方案都有一些缺点： -
1。文档路由： i这种情况所有文档都将在同一碎片上失去碎片的全部目的。
2。dfs_query_then_fetch搜索类型：与之相关的性能成本。
我有兴趣在下面知道：
- ES默认情况下有什么作用？还是可以控制它的任何配置？
- ES提供了其他开箱即用解决方案，以避免 sharding效果？
首先，如果不准确，则首先是问题：
但是，当我们搜索默认情况下，它只会到1个碎片，并给出 resul t。在这种情况下，相关性不准确(因为IDF主要是 受影响(，如果我的匹配 文档在另一个碎片上。它被称为碎片效果。
粗体部分是错误的。搜索请求发送到所有碎片(当然，或者没有人会使用Elasticsearch！(，但是分数是按碎片计算的。因此，是的，您可能会有多个碎片的准确性问题，但前提是您的文档很少。有5亿的准确性将不是问题(除非您对文档路由的不良用途，请参阅此处的更多信息
因此，当您搜索查询的10个结果时，每个碎片返回查询的10个最佳匹配项，然后由协调节点汇总了碎片的结果，以为整个索引提供最佳的10个结果。
您可以使用5个碎片，而不必担心任何相关问题。但是不要试图避免碎片效果！这就是使Elasticsearch如此酷的原因：D