我的弹性集群包含带有巨大映射文件的索引。这是因为我的一些索引包含多达 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 个字段，因此总共有数百个字段）。但是，这会带来一些开销，但最重要的是，我觉得这基本上将我的数据库简化为关系数据库，并且我失去了处理任意结构文档的能力。
关于我的集群的一些技术细节：
弹性搜索 2.3.5 版
22 个节点，其中 3 个是主节点，每个节点包含 16 Gb 的 ram，2 Tb 的磁盘存储。我目前总共有 6 Tb 的数据，分布在 12 亿个文档、55 个索引和 1500 个分片上。
感谢您对我建议的两个解决方案或您想到的任何其他替代方案的意见！