Elasticsearch索引策略创建最佳实践/性能

Question

我正在设计一个基于ElasticSearch的搜索系统，在阅读了很多之后，我看到一些系统，比如日志，使用多个索引的策略来保存相同的内容，类似于mylogs-12-02-2020，并且每天创建一个索引，然后为了搜索，它们在所有符合mylogs- * pattern的索引中执行搜索，每个索引都有它的主碎片和副本。我的问题将是关于搜索的性能，它将更好地表现为查看一个包含500万个文档的索引，其中包含n个碎片，或者查找50个包含100,000个文档的索引。有谁有什么最佳实践经验吗？

我假设我的系统每天大约增加20万份文件。

在多个索引中分离的最佳实践是什么，还是在不同的节点中有一个具有多个主碎片的单一索引(这样它们在搜索/索引时就不会争夺相同的资源)？

在对mylogs-* elastic进行搜索时，它是否与索引并在其碎片中的每个索引中并行？

Answer 1

默认情况下，Elasticsearch索引每个有5个主碎片和1个副本。但问题是，默认配置并不适合每个用例。

对于搜索查询，碎片大小是非常关键的。如果分配给索引的碎片太多，Lucene段就会很小，从而导致开销的增加。当同时执行多个查询时，大量的小碎片也会降低查询吞吐量。另一方面，太大的碎片会导致搜索性能的下降和故障恢复时间的延长。因此，根据Elasticsearch的建议，一个碎片的大小应该在20到40 GB左右。

请记住，它本身是一个单独的搜索引擎，而不是索引。索引是一种数据组织机制，允许用户以某种方式对数据进行分区。仅此而已！

有关更多细节，读这篇文章。

Answer 2

Elasticsearch由@Umar提供的默认配置是旧的，从7.0 ES最新主要版本开始，主碎片减少到1，您可以在ES 官方违规变更公告中检查这一点。

没有人能够设计出最优的ES指数，并且需要在这段时间内进行连续的微调。影响设计考虑的因素。

1. 读写量大的系统。
2. 基于时间的索引(如日志搜索)，通常在较新的日志或电子商务产品目录或网站搜索中进行，在这些索引中，不能将索引划分为基于时间的数据。
3. ES集群(多租户与专用于单一索引的比较)。

以上只是几个示例，我可以给出其他因素的100个，您可以在设计ES索引配置时考虑这些因素。的想法是先从更关键的params开始(比如改变主碎片需要重新索引)，还考虑到近期的增长和基于当前系统性能的微调。

我强烈建议您阅读我的详细博客，它将通过一个真实的案例研究来详细回答您的问题(在一个索引中搜索多个文档，而不是搜索更多的索引/文档少的碎片)。

上面的博客还解释了ES将长期默认的主碎片从5更改为1.的决定。

回答以下问题：

问:在对mylogs-* elastic进行搜索时，它是否与索引并在其碎片中的每个索引中并行？

答:是的，ES具有分布式体系结构，由于ES索引是由Lucene组成的，这是一个成熟的搜索引擎，如果需要访问多个碎片(无论是相同的索引还是多个索引)，则每个ES查询将由多个线程并行执行，如果线程是空闲的，否则一旦线程完成，它将被用于查询另一个碎片。这就是为什么ES比其他分布式系统快得多的原因。