在我目前的用例中，我使用ElasticSearch作为文档存储，我正在构建一个分面搜索功能。
docs说明以下内容：
对脚本中的字段值进行排序，聚合和访问需要不同的数据访问模式。
Doc值是磁盘上的数据结构，它是在文档索引时构建的，这使得这种数据访问模式成为可能。它们存储与_source相同的值，但是以面向列的方式存储，这对于排序和聚合更有效。
这是否意味着聚合不依赖于索引？如果是这样，建议通过设置 {＆＃34; index＆＃34;：＆＃34; no＆＃34;} 来阻止字段完全编入索引？
这是一个小偏差，但设置启用的位置在哪里？它与索引有何不同？
从更广泛的角度来看，如果聚合是我正在寻找的，我应该使用ElasticSearch吗？我应该选择像MongoDB这样的其他解决方案吗？如果是，那么性能考虑是什么？
HELP！
答案 0 :(得分：2)
绝对可以将Elasticsearch用于聚合数据的唯一目的。我已经看过几次这样的设置了。例如，在过去的一个项目中，我们会对数据进行索引，但我们只运行聚合以构建财务报告，而我们很少需要获取文档/命中。 99％的用例只是汇总数据。
如果您有这样的用例，那么您可以将映射调整为
enabled的作用是决定您的数据是否已编入索引。默认情况下是这样，但如果将其设置为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为真，那么您无需执行任何特殊操作。
<强>更新
值得注意的是，聚合依赖于doc_values（即Per Document Values .dvd和.dvm Lucene文件），它们基本上包含与倒排索引中相同的信息，但以面向列的方式组织，这使得聚合更有效。