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

Question

我刚开始一个家庭项目，我计划使用弹性作为数据库。我目前正处于设计阶段，并开始考虑这个问题。

所以，让我们说我得到的文章属于不同的人。 Person对象有一个ID，Article对象也有一个ID属性。 显然，这将是一个保存文章文件的索引。使用这些文档的_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字段要简单得多。