我的索引之一中有4000多个不同的字段。随着时间的推移，这个数字可能会越来越大。 由于Elasticsearch给出每个索引1000个字段的默认限制。一定有原因。
现在，我认为我不应该增加Elasticsearch设置的限制。 因此，我应该将单个大索引分解为多个小索引。
在移到多个索引之前，我有以下几个问题：
小的多个索引的数量最多可以增加50个。因此，一次搜索全部50个索引会比单个大索引的搜索速度变慢？
由于字段数量众多，真的需要将我的单个大索引分解为多个索引吗？
当我使用小的多个索引时，分片的总数将急剧增加（超过250个分片）。每个索引将具有5个分片（默认数字，我不想更改）。搜索这些多个索引将同时搜索这250个分片。这会影响我的搜索效果吗？注意：这些分片的时间可能也会增加。 当我使用仅包含5个分片和大量文档的单一大索引时，这不是这5个分片的重载吗？
答案 0 :(得分：0)
这在很大程度上取决于您的基础结构。如果运行具有50个分片的单个节点，则查询将比仅包含1个分片的查询运行更长的时间。如果您有50个节点各持有一个分片，则它的运行速度可能会比具有1个分片的一个节点快（如果您有一个大数据集）。最后，您必须对真实数据进行测试才能确定。
当存在大量字段时，ES会遇到性能问题，并且更有可能发生错误。主要问题是每个字段都必须以集群状态存储，这会对您的主节点造成影响。另外，在很多情况下，您必须使用大量稀疏数据（90％的字段为空）。
根据经验，一个分片应包含30 GB到50 GB的数据。对于您的用例中的分片过载，我不会太担心。反之亦然。
我建议使用较少的分片来测试您的用例，降低到1个分片，1个副本作为索引。与您的小型数据集相比，搜索多个碎片（5个主要碎片，乘以副本）然后再次组合结果所产生的开销是巨大的。
请记住，document_type行为已更改，并将进一步更改。由于6.X，每个索引只能有一个document_type，因此从7.X开始，document_type会被完全删除。当API侦听_doc时，_doc是建议在6.X中使用的document_type。如果需要将数据存储在一个索引中，请为每个_type移至一个索引，或者引入一个新字段来存储您的类型。