【问题标题】:Elastic search - one index vs multiple indexes?弹性搜索 - 一个索引与多个索引?
【发布时间】:2017-11-25 18:32:24
【问题描述】:

我正在研究一种解决方案,用于将应用程序日志存储在 Elastic Search 中,用于跨多个开发团队的许多应用程序。每个日志条目的结构都与一个“app”字段相同,以指示应用程序。

#1 目标是支持在单个“应用程序”内进行高效查询。跨所有应用程序查询虽​​然仍然很重要,但将是次要的。

我正在尝试确定什么是最好的:

编辑:在这两种情况下,我都会使用基于时间的索引。

多个索引系列

每个“应用程序”都会有一系列基于时间的索引(app1-2017-04-01、app1-2017-04-02、...等)用户将直接针对这些较小的索引执行搜索。这里的想法是,由于索引的大小较小,因此查询它们可能更快?

单索引系列

使用一个巨大的索引系列来表示所有应用程序日志(例如,logs-2017-04-01、logs-2017-04-02、...等) 用户会查询“app”字段以缩小搜索结果。

在这种情况下哪个更快?我很好奇额外索引的开销成本

【问题讨论】:

  • 在处理日志时,您确实希望使用基于时间的索引。我这样做的方式是让每个应用程序写入自己的月度索引(appname__2017-06、anotherapp__2017-06 等)。这样,当需要删除旧数据时,您可以删除整个月,而不是运行昂贵且缓慢的删除查询。
  • @Johnny 目前我正在为每个应用编写基于每日时间的索引。我的问题是我应该使用一个巨大的基于时间的索引还是许多较小的基于时间的索引
  • 你从错误的角度来处理这个问题。你应该问自己一组不同的问题。保留期限是多少?有多少个应用程序?您预计每个应用每天将拥有多少数据(以 GB 为单位)?有多少个 ES 节点?这些节点的硬件资源是什么?您是主要查询最新时期的索引还是旧索引也有相同数量的查询?

标签: elasticsearch


【解决方案1】:

在大多数情况下,多个索引更好:

  1. 搜索较小的数据集更快
  2. 映射结构的限制较少。如果您需要为新数据更改它,您可以保留旧数据而无需重新索引,只需为新索引放置新映射
  3. 它更具可扩展性和灵活性。您可以将旧索引保存在不同的硬盘驱动器或不同的机器上。
  4. 如果需要,您仍然可以搜索多个索引。
  5. 索引的开销很小。如果每个索引有很多文档,则文档占用的空间比索引元数据多得多。如果没有,您可以花更短的时间来拆分日志索引

【讨论】:

    【解决方案2】:

    我将提供假设性指导,因为您选择忽略我的问题的答案。

    当涉及到日志记录用例(基于时间的索引)时,手头必须有一些关于未来计划的数据:您希望将日志记录数据保留多长时间(保留期),用途是什么收集数据的模式(查询频率,索引频率),每天会有多少数据(这里指的是磁盘上的数据,也就是分片大小)。在考虑“per-app-index”或“single-index”问题之前,请考虑以下建议。在您对分片大小进行数学计算后,在选定的保留期内将有多少,然后您可以考虑每个应用程序或单个索引。

    尤其取决于分片大小和第二个保留期,需要考虑基于时间的索引是每天、每周还是每月。一个好的分片大小的经验法则是最大 30-50GB,高于此值的所有内容都会导致任何恢复、分片重定位、搜索可能变慢并可能影响集群稳定性。

    如果您的应用能够每天生成超过上述数量的大量数据,则不应选择为每个应用创建索引。如果尺寸更小,那么这又取决于。一个节点上的大量分片正在浪费资源,并且会使搜索速度变慢。每个分片都有一组固定的内存,因为它存在而被使用。此外,在执行搜索时,每个分片将由一个线程执行其搜索。一个线程基本上是一个 CPU 核心。搜索中使用的时间跨度越高(搜索的索引越多),发生的并发搜索次数越多,尝试使用 CPU 内核的多个线程之间的操作系统级别的上下文切换就越高。总而言之,不要试图在单个节点中挤入数百个分片,除非在任何给定时间只会使用其中的一部分。如果您计划在大多数时间查询集群中的所有数据,那么您希望在每个节点上拥有的分片数量会急剧减少。否则您的集群将无法跟上负载。

    如果您的日志记录用例是大部分在最新数据(最近几天到一周)上具有高活动性的情况,那么请考虑热温架构的方法:https://www.elastic.co/blog/hot-warm-architecture-in-elasticsearch-5-x

    构建和配置集群的练习总是涉及测试。因此,请尝试在尽可能与真实数据相同的数据上测试查询的性能。此外,在具有生产集群中节点硬件规格的一个节点上执行此操作。

    【讨论】:

      【解决方案3】:

      就性能而言,使用大索引比使用几个小索引更好,正如您在 Adrien Grand 的文章Index vs. Type 中看到的那样。 p>

      索引存储在一组分片中,这些分片本身就是 Lucene 指数。这已经让您看到了使用新的限制 始终索引:Lucene 索引在 磁盘空间、内存使用和使用的文件描述符。为了那个原因 原因,单个大索引比几个小索引更有效 指数:Lucene 指数的固定成本更好地摊销 很多文件。

      我的建议是为所有应用程序使用一个基于时间的索引,其中每个应用程序都是不同类型的索引。它让您在搜索每个应用程序日志时更容易,同时在搜索所有应用程序时也很简单。

      例如:

      如果您只想在一个应用中搜索,您可以使用:

      http://yourserver:9200/logs-2017-04-01/app1/_search

      对于所有应用程序:

      http://yourserver:9200/logs-2017-04-01/_search

      另一个值得评估的好点是每个应用程序可以有不同数量的日志条目。这样,如果每个应用程序都有一个不同的索引,那么在为每个应用程序调整分片大小时会非常困难。因此,仅使用一个索引将使您在调整集群大小时更容易。如果索引太大,只需将其拆分为更多分片。

      【讨论】:

      • 在谈论性能时,您不需要只考虑查询数量,而是考虑 Lucene 索引将如何使用您的资源。每个索引都是不同的 Lucene 索引,这意味着您需要考虑每个索引使用的磁盘空间、内存使用情况和文件描述符。
      • 这是一个公平的观点,但我不同意在这种情况下这是最相关的(应该有多少应用程序才能使其相关......)。分片是允许您实际扩展集群以获得性能的单元。但除此之外,混合应用程序日志意味着 Elasticsearch 必须搜索每个查询的每个分片,即使用户可能只搜索特定应用程序的日志。
      • 我同意@BrunodosSantos。而且,正如我在最初帖子的 cmets 中所说,发帖人提出的问题是错误的。这篇文章的其他两个答案也是如此:他们错了。我每天都看到用户推动他们集群的资源边界,因为他们不考虑保留期、索引的大小、他们可以使用的资源等。他们在投入生产之前没有进行适当的测试,然后他们抱怨性能.. .
      • 任何工程问题的答案几乎总是“视情况而定”。所以说答案是“错误的”对我来说似乎很激进。您问的是重要问题(可用资源、数据量等),但它们不一定相关:如果您没有资源,那么 any 答案是错误的。我们在这里隐含地假设情况并非如此。也可以应用进一步的性能调整技术(热温架构、删除旧日志等),但同样,在这种情况下提及它们是无关紧要的。含糊的答案不是很有用。
      • @federicojasson 如果您没有正确调整集群大小并正确构建索引,那么每个人现在关注的问题都将成为空谈。您配置索引的方式(基于它们在磁盘上的大小、每天/每周/每月等)将很重要。如果您使用每个应用程序的索引而不考虑这些索引的大小,您最终可能会在每个节点上拥有 1000 个分片,并且白白浪费硬件资源。这种调优方案很困难,我同意“视情况而定”,但在跳转到每个应用程序的索引之前,需要考虑其他事情。
      【解决方案4】:

      为不同的应用保留不同的索引可以为您提供灵活性,并且最终可以通过调整每个应用的分片/副本的数量来帮助您提高性能。在任何情况下,您始终可以通过定义别名或简单地使用通配符来允许交叉搜索。

      考虑到多个团队将访问数据,为不同的应用程序保留不同的索引也更加清晰。最后,如果您最终想要添加某种访问控制(使用 Shield/X-Pack),拥有不同的索引肯定会让事情变得更容易。

      【讨论】:

      • 现在他们已经删除了mapping types,我认为你的回答是 lucene 工作原理的本质
      猜你喜欢
      • 2023-01-31
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 2013-01-06
      • 1970-01-01
      相关资源
      最近更新 更多