我正在研究一种解决方案，将应用程序日志存储在Elastic Search中，用于许多开发团队中的许多应用程序 . 每个日志条目的结构与“app”字段相同，以指示应用程序 .
第一个目标是支持在单个“应用程序”中进行有效查询 . 查询所有应用程序虽然仍然很重要，但仍然是次要的 .
我正在努力确定什么是最好的：
编辑：在这两种情况下，我将使用基于时间的索引 .
multiple index series
每个“app”都有一系列基于时间的索引（app1-2017-04-01，app1-2017-04-02，...等） . 用户可以直接对这些较小的索引执行搜索 . 这里的想法是，由于索引的大小较小，可能查询它们更快？
single index series
使用一个巨大的索引系列来表示所有应用程序日志（例如logs-2017-04-01，logs-2017-04-02，...等）用户将查询“app”字段以缩小搜索结果范围 .
Which is faster in this case? I'm curious about the overhead cost of additional indexes
4 回答
在大多数情况下，多个索引更好：
搜索较小的数据集更快
您在映射结构方面受到的限制较少 . 如果您需要为新数据更改它，您可以保留旧数据而无需重新索引，只需为新索引添加新映射
它更具可扩展性和灵活性 . 您可以将旧索引保留在不同的硬盘驱动器或不同的计算机上 .
如果需要，您仍然可以搜索多个索引 .
索引的开销很小 . 如果每个索引有大量文档，则文档占用的空间比索引元数据多得多 . 如果没有，您可以花费较小的时间段来拆分日志索引
我将提供假设的指导，因为您选择忽略我的问题的答案 .
当涉及到日志记录用例（基于时间的索引）时，必须掌握有关未来计划的一些数据：您希望保留记录数据的时间（保留期），将使用的模式是什么收集的数据（查询频率，索引频率），每天将有多少数据（这里指的是磁盘上的数据，也就是碎片大小） . 在考虑“每应用程序索引”或“单索引”问题之前，请考虑以下建议 . 在对分片大小进行数学计算，选择保留期的数量后，您可以考虑每个应用程序或单个索引 .
特别是根据碎片大小和第二个保留期，需要考虑基于时间的索引是每日，每周还是每月 . 对于分片大小的一个很好的经验法则是最大30-50GB，高于此值的所有内容都将使任何恢复，分片重定位，搜索可能更慢并且可能影响群集稳定性 .
如果您的应用程序能够每天生成大量数据，而这些数据将超过上述数量，则不应选择为每个应用程序生成索引 . 如果尺寸较小，那么它又取决于 . 一个节点上的大量分片正在浪费资源并且会使搜索速度变慢 . 每个分片都有一组固定的内存，只是因为它存在而被使用 . 此外，在执行搜索时，每个分片将通过一个线程执行其搜索 . 一个线程基本上是一个CPU核心 . 搜索中使用的时间 Span 越大（搜索的索引越多），发生的并发搜索次数越多，尝试使用CPU核心的多个线程之间的操作系统级别的上下文切换越高 . 总而言之，不要试图在单个节点中挤出数百个分片，但在任何给定时间只会使用其中一些分片 . 如果您计划在大多数时间查询群集中的所有数据，那么您希望在每个节点上拥有的分片数量会大幅缩减 . 否则，您的群集将无法跟上负载 .
如果您的日志记录用例是 mostly 对最新数据（过去几天到一周）的活动较高的那个，那么请考虑热门架构的方法：https://www.elastic.co/blog/hot-warm-architecture-in-elasticsearch-5-x
构建和配置集群的练习总是涉及测试 . 那么，请尝试在尽可能与现实数据相同的数据上测试查询的性能 . 此外，在具有 生产环境 群集中节点的硬件规格的一个节点上执行此操作 .
在性能方面，最好使用大指数而不是几个小指数，正如您在文章 Index vs. Type 上看到的 Adrien Grand .
我的建议是对所有应用程序使用一个基于时间的索引，其中每个应用程序是索引的不同类型 . 在搜索每个应用程序日志时，它将使您更容易，并且在同时搜索所有应用程序时非常简单 .
例如：
如果您只想在一个应用中搜索，您可以使用：
http://yourserver:9200/logs-2017-04-01/app1/_search并适用于所有应用：
http://yourserver:9200/logs-2017-04-01/_search评估的另一个好处是每个应用程序可以具有不同数量的日志条目 . 这样，如果每个应用程序都有一个不同的索引，那么在为每个应用程序调整碎片大小时会非常困难 . 因此，在调整群集大小时，只使用一个索引会使您更容易 . 如果索引太大，只需将其拆分为更多分片 .
为不同的应用程序保留不同的索引可以提供灵活性，最终可以通过调整每个应用程序的分片/副本数来帮助您提高性能 . 在任何情况下，您始终可以通过定义别名或仅使用通配符来允许交叉搜索 .
考虑到多个团队将访问数据，为不同的应用程序保留不同的索引也更加清晰 . 最后，如果你最终想要添加某种访问控制（使用Shield / X-Pack），拥有不同的索引肯定会让事情变得更容易 .