太多字段对弹性搜索索引不利？答案

【问题标题】：Too many fields bad for elasticsearch index?太多字段对弹性搜索索引不利？
【发布时间】：2014-03-21 14:15:34
【问题描述】：

假设我有一千个键，我想存储相关的值。直观的方法似乎类似于

{
   "key1":"someval",
   "key2":"someotherval",
    ...
}

对于具有数千个键的弹性搜索索引来说，这是一种糟糕的设计模式吗？以这种方式引入的每个键是否会为索引下的每个文档产生开销？

【问题讨论】：

【解决方案1】：

如果您知道您将拥有的键数量有上限，那么几千个字段不是问题。

问题是当你有一组无限的键时，例如当键从一个值派生时，您将拥有一个不断增长的映射，因此还有集群状态。它还可能导致古怪的搜索。

这是一个足够常见的问题/问题，我在Troubleshooting Elasticsearch searches, for Beginners 上的文章中专门针对它进行了一节。

简而言之，数千个字段没有问题 - 无法控制映射。

【讨论】：

除了你提到的不断增长的映射和集群状态之外，我担心每个文档是否会有开销。我的意思是举个例子，我可能有一个只与不到 10 个文档相关的键，但是说索引中有 100 万个文档。不使用该键的其他文档最终是否会有一些空字段/引用（例如在 mysql 中，当您有太多具有空值的列时）？
倒排索引的工作方式，这不是问题。本质上，一个术语在字典中的字段是一种“前缀”。这里还有一点：found.no/foundation/elasticsearch-from-the-bottom-up
但是“你不控制映射”是什么意思？如果我得到了我事先不知道的密钥，但我知道不会有超过 10000 或 100000 个不同的密钥，那为什么不好？以这种方式将新字段添加到映射时究竟会发生什么？

【解决方案2】：

Elasticsearch 不适合文档中的 1000 多个键值模式。如果您想实时更新它们，请尝试使用 redis 或 riak。

如果您在文档/记录中有数千个键，基本上它们会变成字段，而值会变成文本和索引。

从大数据的信息检索角度来看，建议使用较少的大字段而不是大量的小字段，以获得更快的搜索性能。

【讨论】：