我正在构建一个定期查询系统资源使用情况的应用程序，并将数据记录到ElasticSearch中。我想最终将此信息显示为给定时间段的图表。请注意，通常用户需要查看设定时间段的统计信息 -
正因为如此，我一直在考虑将数据存储到ElasticSearch中以获得最佳搜索速度的最有效方法。显然，每个条目都有一个单独的DateTime字段（低至毫秒），但如果我只能对特定索引执行查询，搜索速度会快得多。
我的计划是将索引设置为当前日期（即2014_04_09）。根据{{3}}，您可以将多个索引链接到单个别名。在这种情况下，我会为2014_04以及2014设置上面的别名。这背后的想法是我可以在2014_04索引上执行搜索，这将自动搜索4月份的所有单个索引日。这是否有效，如果是的话，是否最佳？
有没有其他人在ElasticSearch中有类似的DateTime查询经验？谢谢！
答案 0 :(得分：2)
我会阅读这个article的全部内容，以便为您提供更多信息，它确实涉及Elasticsearch和Timestamped数据。希望这会有所帮助。
答案 1 :(得分：1)
正如您在评论中所说的那样，将这些组合成一个索引会更有意义，因为它是相同的信息，它将使未来的查询更多更简单。
通过每日，每月和每年制作一个索引，那么您将不得不对文档或进行三重索引来提出复杂的逻辑来控制别名，在我看来，这不是值得创造大量指数（每天一个）。如果您正在进行日志记录，那么logst将显然是一个更好的答案，正如Nate所指出的那样。在这种情况下，当你没有提供任何价值时，你可以turn off indices ("close")，这可能是值得注意的，因此除了占用磁盘空间之外，它们不会产生任何负面影响。
关于日志记录主题，创建N索引将固有地导致多个分片（至少N）。单个添加many shards will unnecessarily slow things down就足够了。使用别名进行工作会在添加其他索引时创建频繁的维护。
通过将这些组合到一个索引中，您可以轻松地按需执行分析和您可以在时机到来时更轻松地跨多个节点扩展Elasticsearch。有用的是，您几乎肯定会发现更复杂的聚合，您可能会从更简单的索引中受益。
即使缓存过滤，您也会收到适用于您的过滤器的更新。通过生成一个简单的过滤器，运行它，然后在其预期的结果集中添加其他内容，可以很容易地证明这一点。