为什么不在 ElasticSearch 索引中分配多个类型来记录日志，而不是多个索引？答案

【问题标题】：Why not assign multiple types in an ElasticSearch index for logging, rather than multiple indices?为什么不在 ElasticSearch 索引中分配多个类型来记录日志，而不是多个索引？
【发布时间】：2015-07-31 02:37:22
【问题描述】：

我目前正在研究一些使用 ElasticSearch 的数据存储策略，想知道为什么要存储日志，this page 表示：

标准格式是为每一天分配一个新索引。

每天创建一个新类型名称（表）的索引（数据库）不是更有意义吗？

我从每个索引的角度来看这都与不同的 Web 应用程序相关联。

在另一种情况下，Web 应用程序使用一个索引。该索引中的一种类型用于日志记录（我们目前对 SQL Server 所做的事情）。这是一个好方法吗？

【问题讨论】：

标签： indexing elasticsearch

【解决方案1】：

有趣的想法，是的，你可能会这样做。为什么要使用多个索引？如果控制分片到节点的分配（也许您希望所有 2015 年都存储在一组节点上，2014 年，另一组），过滤缓存大小和类似的东西很重要，那么您会因为转到单个索引而失去它/多映射方法。对于非常大容量的应用程序，这种控制可能很重要。 YMMV。

关于“每个索引都与不同的 Web 应用程序相关联”的观点，别名可以（并且正在）用于在单个可搜索的保护伞下收集多个物理索引；您每天/每周/随便创建一个索引，例如 logs-20150730、logs-20150731... 并将 logs 别名分配给系列中的所有索引.净效应与拥有一个“索引”相同。

别名方法的好处是清除/修剪旧数据是微不足道的；无论您的数据保留策略是什么，只要在其内容过期时删除索引即可。使用多重映射，您必须删除索引中的必要映射（可行，但相当 I/O 侵入性，因为您可能会在映射分配的每个分片中塞入东西。）

【讨论】：

因此，在用户拥有收集大量数据的项目的 Web 应用程序场景中，您可以为用户、他们的个人资料等创建一个索引，然后使用一种 ProjectData 类型创建多个索引，其中包含每个索引所有用户当天的项目数据。如果我们只想在任何给定时间保留三个月的数据，那么清除很简单。然而，不同的用户有不同的清除日期呢？这种方法听起来如何？为什么不在同一个索引中创建新的 ProjectData 类型呢？