在我当前的用例中，我使用 ElasticSearch 作为文档存储，并在此基础上构建分面搜索功能。
docs 声明如下：
在脚本中排序、聚合和访问字段值需要不同的数据访问模式。
Doc 值是磁盘上的数据结构，在文档索引时构建，这使得这种数据访问模式成为可能。它们存储与 _source 相同的值，但以面向列的方式存储，这种方式对于排序和聚合更有效。
这是否意味着聚合不依赖于索引？如果是这样，是否建议通过设置 {"index": "no"} 来防止字段被完全索引？
这是一个小的偏差，但是设置启用是从哪里来的呢？它与 index 有何不同？
更广泛地说，如果我只需要聚合，我应该使用 ElasticSearch 吗？我应该选择 MongoDB 等其他解决方案吗？如果有，性能方面的考虑是什么？
帮助！
【问题讨论】：
标签： elasticsearch lucene
绝对可以将 Elasticsearch 用于聚合数据的唯一目的。我见过几次这样的设置。例如，在过去的一个项目中，我们会为数据编制索引，但我们只运行聚合以构建财务报告，而且我们很少需要获取文档/点击。 99% 的用例只是汇总数据。
如果您有这样的用例，那么您可以将映射调整为
enabled 的作用是决定你的数据是否被索引。默认情况下为 true，但如果您将其设置为 false，您的数据将被简单地存储（在 _source 中）但被分析器完全忽略，即它不会被分析、标记和索引，因此，它不会不可搜索，您将能够检索_source，但不能搜索它。如果需要使用聚合，那么enabled需要为true（默认值）
store 参数决定是否要存储该字段。默认情况下，字段值被索引，但不存储，因为它已经与_source 本身一起存储，您可以使用源过滤来检索它。对于聚合，此参数不起任何作用。
如果您的用例仅涉及聚合，您可能会想设置_source: false，即根本不存储_source，因为您只需要索引字段值以聚合它们，但这很少是个好主意for various reasons。
因此，要回答您的主要问题，聚合确实取决于索引，但用于聚合的（doc-）值写入专用文件，其内部结构比从索引访问数据更具性能和最优性为了构建聚合。
如果您使用的是 ES 1.x，请确保为您要聚合的所有字段（分析的字符串和布尔字段除外）将 doc_values 设置为 true。
如果你使用的是 ES 2.x，doc_values 默认为 true，所以你不需要做任何特别的事情。
更新：
值得注意的是，聚合依赖于doc_values（即Per Document Values .dvd 和.dvm Lucene 文件），它基本上包含与倒排索引中相同的信息，但以面向列的方式组织时尚，这使得聚合更加高效。
【讨论】：
.dvd 和.dvm 文件），这与倒排索引中的信息基本相同，但以面向列的方式组织，这使得聚合更加高效。