database - 将ID存储在ElasticSearch索引的_type字段中是个好主意吗？

Question

我刚刚开始一个家庭项目，并且打算使用Elastic作为数据库。我目前正处于设计阶段，并开始考虑这一点。

假设我有属于不同人的文章。 Person对象具有ID，并且Article对象也具有ID属性。
显然会有一个保存Article文档的索引。使用这些文档的_type字段存储一个Person的ID(这表示该文章属于哪个Person)似乎是一个好主意。
但是，我从未见过有人使用此字段来进行此类操作。

在元数据中搜索比在_source数据中搜索更快吗？我的意思是，如果我不使用_type来存储ID，则Article对象将具有OwnerID字段或类似的字段。

举一个实际的例子，假设我要查找所有与政治相关的文章，并以任何顺序由XY撰写。

第一个版本(请注意XY位于标题中):

GET /my_index/XY/_search
{
    "query" : {
        "constant_score" : { 
            "filter" : {
                "term" : { 
                    "genre" : "politics"
                }
            }
        }
    }
}

第二版:

GET /my_index/article/_search
{
   "query" : {
      "constant_score" : { 
         "filter" : {
            "bool" : {
              "must" : [
                 { "term" : {"ownerID" : XY}}, 
                 { "term" : {"genre" : "politics"}} 
              ]
           }
         }
      }
   }
}

他们中的任何一个都比另一个更好吗？
我很乐观，即使有5个人打算使用这个网站，即使有5000人，我也希望做出一个好的设计。
如果索引中有5000种不同类型，这有关系吗？

Answer 1

是的，这确实很重要，这就是为什么要使用第二个版本的原因。

如果您决定使用人员ID作为文章的类型，并且有5000个人，那么my_index索引最终将具有5000种映射类型，并且所有映射类型都具有相同的字段。如果您想在某个时候在文章中添加一个新字段，则必须修改所有5000种映射类型。这可能就是为什么您从未见过有人使用过这种类型的原因。

与第二个版本一样，为文章提供一个索引和一种映射类型，然后为一个ownerID字段，将更加简单。