elasticsearch 改进Elasticsearch上的映射性能

我的弹性集群包含带有巨大映射文件的索引。这是因为我的一些索引包含多达60k个不同的字段

为了详细说明我的设置，每个索引都包含来自单个源的信息。每个源都有几种类型的数据（我称之为层），这些数据在对应于源的索引中被索引为不同的类型。每个层具有不同的属性（平均20个）。为了避免字段名冲突，它们被索引为“LayerId\u 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个碎片

---

我非常感谢您对我建议的两个解决方案或任何其他备选方案的意见

请问您的用例是什么？为什么使用Elasticsearch？当不知道如何查询数据时，很难提出任何有意义的建议。