我的弹性簇包含带有巨型映射文件的索引。这是因为我的一些索引包含多达60k个不同的字段。
为了详细介绍我的设置，每个索引都包含来自单一来源的信息。每个源都有几种类型的数据（我称之为层），它们在与源相对应的索引中被索引为不同类型。每层都有不同的属性（平均20个）。为避免字段名冲突，它们被索引为“ LayerId_FieldId”。
我正在尝试找到一种减小映射大小的方法（据我了解，这可能会导致性能问题）。一种选择是每层有一个索引（也许将大的层分布在几个索引上，每个索引负责不同的时间段）。我现在大约有4000个不同的索引层，所以可以说，在这种方法中，我将有5000个不同的索引层。弹性好吗？如此大量的索引，其中有些索引非常小（有些层只有100项之多），我应该担心（如果有的话）吗？
第二种可能的解决方法如下。与其以发送给我的方式保存图层的数据，例如：
"LayerX_name" : "John Doe",
"LayerX_age" : 34,
"LayerX_isAdult" : true,
它将另存为：
"value1_string" : "John Doe",
"value2_number" : 34,
"value3_boolean" : true,
在后一个选项中，我将必须保留一些元数据索引，以将通用名称链接到真实字段名称。在上面的示例中，我需要知道对于X层，字段“ value1_string”对应于“ name”。因此，每当我收到要编制索引的新文档时，都必须查询元数据，以便知道如何将给定的字段映射到我的通用名称中。这使我可以进行恒定的大小映射（例如，每个值类型50个字段，因此总共有数百个字段）。但是，这会带来一些开销，但是最重要的是，我感到这基本上将数据库缩减为一个关系数据库，并且失去了处理任意结构的文档的能力。
有关集群的一些技术细节：
Elasticsearch版本2.3.5
22个节点，其中3个是主节点，每个节点包含16 Gb的ram，2 Tb 光盘存储。我目前总共有6 Tb的数据分布在1.2之上 十亿个文档，55个索引和1500个分片。
感谢您对我建议的两种解决方案或您想到的任何其他替代方案的投入！