Elasticsearch 参考指南（删除映射类型）

时间  2019-11-09
标签 elasticsearch 参考 指南 删除 映射 类型 栏目 日志分析 繁體版
原文   原文链接

删除映射类型

在Elasticsearch 7.0.0或更高版本中建立的索引再也不接受 _default_映射，索引在6.x中建立将继续在Elasticsearch 6.x中运行，类型在api 7.0中是不受支持的，它会中断对索引建立、put映射、get映射、put模板、get模板和get字段映射API的更改。

什么是映射类型？

自从第一次发布Elasticsearch以来，每一个文档都存储在一个索引中，并分配了一个映射类型，映射类型用于表示被索引的文档或实体的类型，例如twitter索引可能具备user类型和tweet类型。数据库

每一个映射类型均可以有本身的字段，所以user类型能够有full_name字段、user_name字段和email字段，而tweet类型能够有content字段、tweeted_at字段，和user类型同样，还有user_name字段。segmentfault

每一个文档都有一个包含类型名称的_type元字段，经过在URL中指定类型名称，能够将搜索限制为一个或多个类型：api

GET twitter/user,tweet/_search
{
  "query": {
    "match": {
      "user_name": "kimchy"
    }
  }
}

_type字段与文档的_id相结合生成_uid字段，所以具备相同_id的不一样类型的文档能够存在于一个索引中。app

还使用映射类型在文档之间创建父子关系，所以类型为question的文档能够是类型为answer的文档的父文档。ui

为何要删除映射类型？

最初，讨论了“索引”相似于SQL数据库中的“数据库”，以及“类型”等价于“表”。code

这是一个错误的类比，致使了错误的假设，在SQL数据库中，表是相互独立的，一个表中的列与另外一个表中具备相同名称的列没有关系，这与映射类型中的字段不一样。继承

在Elasticsearch索引中，不一样映射类型中具备相同名称的字段在内部由相同的Lucene字段支持，换句话说，使用上面的示例，user类型中的user_name字段存储在与tweet类型中的user_name字段彻底相同的字段中，并且两个user_name字段在这两种类型中必须具备相同的映射（定义）。索引

例如，当你想要删除一个类型中的date字段和同一个索引中的另外一个类型中的boolean字段时，这可能会致使失败。ip

最重要的是，存储在同一索引中具备不多或没有共同字段的不一样实体会致使数据稀疏，并影响Lucene有效压缩文档的能力。文档

基于这些缘由，决定将映射类型的概念从Elasticsearch中移除。

映射类型的替代方案

每种文档类型的索引

第一种选择是为每一个文档类型都有一个索引，你能够将tweets存储为tweets和user索引，而不是将tweets和users存储在单个twitter索引中，索引之间是彻底独立的，所以索引之间不存在字段类型的冲突。

这种方法有两个好处：

  • 数据更多是密集的，所以受益于Lucene中使用的压缩技术。
  • 用于在全文搜索中得分的统计术语更可能准确，由于同一索引中的全部文档都表示一个实体。

每一个索引均可以根据它将包含的文档数量适当调整大小：你能够为users使用较少的主碎片，而为tweet使用较多的主碎片。

自定义类型字段

固然，集群中能够存在多少主碎片是有限制的，所以你可能不但愿为了一个只有几千个文档的集合而浪费整个碎片，在本例中，你能够实现本身的自定义类型字段，其工做方式与旧的_type相似。

让咱们以上面的user/tweet为例，最初，工做流应该是这样的：

PUT twitter
{
  "mappings": {
    "user": {
      "properties": {
        "name": { "type": "text" },
        "user_name": { "type": "keyword" },
        "email": { "type": "keyword" }
      }
    },
    "tweet": {
      "properties": {
        "content": { "type": "text" },
        "user_name": { "type": "keyword" },
        "tweeted_at": { "type": "date" }
      }
    }
  }
}

PUT twitter/user/kimchy
{
  "name": "Shay Banon",
  "user_name": "kimchy",
  "email": "shay@kimchy.com"
}

PUT twitter/tweet/1
{
  "user_name": "kimchy",
  "tweeted_at": "2017-10-24T09:00:00Z",
  "content": "Types are going away"
}

GET twitter/tweet/_search
{
  "query": {
    "match": {
      "user_name": "kimchy"
    }
  }
}

你能够经过添加自定义类型字段来实现相同的功能，以下所示：

PUT twitter
{
  "mappings": {
    "_doc": {
      "properties": {
        "type": { "type": "keyword" }, 
        "name": { "type": "text" },
        "user_name": { "type": "keyword" },
        "email": { "type": "keyword" },
        "content": { "type": "text" },
        "tweeted_at": { "type": "date" }
      }
    }
  }
}

PUT twitter/_doc/user-kimchy
{
  "type": "user", 
  "name": "Shay Banon",
  "user_name": "kimchy",
  "email": "shay@kimchy.com"
}

PUT twitter/_doc/tweet-1
{
  "type": "tweet", 
  "user_name": "kimchy",
  "tweeted_at": "2017-10-24T09:00:00Z",
  "content": "Types are going away"
}

GET twitter/_search
{
  "query": {
    "bool": {
      "must": {
        "match": {
          "user_name": "kimchy"
        }
      },
      "filter": {
        "match": {
          "type": "tweet" 
        }
      }
    }
  }
}
  • 显式type字段替代了隐式_type字段。

没有映射类型的父/子关系

之前，父—子关系表示为将一个映射类型表示为父，将一个或多个其余映射类型表示为子，没有类型，咱们就不能再使用这种语法，除了表示文档之间关系的方式已更改成使用新的join字段外，父—子特性将继续像之前同样工做。

删除映射类型的时间表

对于用户来讲，这是一个巨大的变化，因此已经尝试让它尽量地不那么痛苦，更改将按以下方式进行：

Elasticsearch 5.6.0

  • 在索引上设置index.mapping.single_type: true将启用在6.0中强制执行的单类型/索引行为。
  • 在5.6中建立的索引中可使用父—子join字段替换。

Elasticsearch 6.x

  • 在5.x中建立索引将继续在6.x中运行就像5.x。
  • 索引在6.x中建立只容许每一个索引使用单一类型，类型可使用任何名称，但只能有一个，首选的类型名称是_doc，所以索引API具备与7.0中相同的路径：PUT {index}/_doc/{id} and POST {index}/_doc。
  • _type名称不能再与_id组合以造成_uid字段，_uid字段已成为_id字段的别名。
  • 新的索引再也不支持旧式的父/子索引，而是应该使用join字段。
  • _default_映射类型已弃用。
  • 在6.8中，索引建立、索引模板和映射API支持查询字符串参数（include_type_name），该参数指示请求和响应是否应该包含类型名称。它默认为true，应该设置为一个显式值，以便准备升级到7.0，未设置include_type_name将致使一个弃用警告，没有显式类型的索引将使用虚拟类型名称_doc。

Elasticsearch 7.x

  • 在请求中指定类型已弃用，例如，索引文档再也不须要文档type，对于显式id，新的索引API是PUT {index}/_doc/{id}，对于自动生成的id则是POST {index}/_doc，注意，在7.0中，_doc是路径的一个永久部分，它表示端点名称，而不是文档类型。
  • 索引建立、索引模板和映射API中的include_type_name参数默认为false，彻底设置该参数将致使一个弃用警告。
  • 删除_default_映射类型。

Elasticsearch 8.x

  • 再也不支持在请求中指定类型。
  • 删除include_type_name参数。

将多类型索引迁移到单类型

Reindex API可用于将多类型索引转换为单类型索引，下面的例子能够在Elasticsearch 5.6或Elasticsearch 6.x中使用，在6.x，不须要指定index.mapping.single_type做为默认值。

每种文档类型的索引

第一个示例将twitter索引拆分为tweets索引和users索引：

PUT users
{
  "settings": {
    "index.mapping.single_type": true
  },
  "mappings": {
    "_doc": {
      "properties": {
        "name": {
          "type": "text"
        },
        "user_name": {
          "type": "keyword"
        },
        "email": {
          "type": "keyword"
        }
      }
    }
  }
}

PUT tweets
{
  "settings": {
    "index.mapping.single_type": true
  },
  "mappings": {
    "_doc": {
      "properties": {
        "content": {
          "type": "text"
        },
        "user_name": {
          "type": "keyword"
        },
        "tweeted_at": {
          "type": "date"
        }
      }
    }
  }
}

POST _reindex
{
  "source": {
    "index": "twitter",
    "type": "user"
  },
  "dest": {
    "index": "users"
  }
}

POST _reindex
{
  "source": {
    "index": "twitter",
    "type": "tweet"
  },
  "dest": {
    "index": "tweets"
  }
}

自定义类型字段

下一个示例添加一个自定义类型字段，并将其设置为原始_type的值，它还将类型添加到_id中，以防有任何不一样类型的文档具备冲突的id：

PUT new_twitter
{
  "mappings": {
    "_doc": {
      "properties": {
        "type": {
          "type": "keyword"
        },
        "name": {
          "type": "text"
        },
        "user_name": {
          "type": "keyword"
        },
        "email": {
          "type": "keyword"
        },
        "content": {
          "type": "text"
        },
        "tweeted_at": {
          "type": "date"
        }
      }
    }
  }
}


POST _reindex
{
  "source": {
    "index": "twitter"
  },
  "dest": {
    "index": "new_twitter"
  },
  "script": {
    "source": """
      ctx._source.type = ctx._type;
      ctx._id = ctx._type + '-' + ctx._id;
      ctx._type = '_doc';
    """
  }
}

7.0中的无类型API

在Elasticsearch 7.0中，每一个API都支持无类型请求，指定类型将产生一个弃用警告。

即便目标索引包含自定义类型，无类型API也能够工做，例如，若是索引具备自定义类型名称 my_type，则可使用无类型 index调用向其添加文档，并使用无类型 get调用加载文档。

索引API

索引建立、索引模板和映射API支持一个新的include_type_name URL参数，该参数指定请求和响应中的映射定义是否应该包含类型名称，版本6.8中的参数默认为true，以匹配在映射中使用类型名称的7.0以前的行为，它在7.0版本中默认为false，将在8.0版本中删除。

它应该在6.8中明确设置，以便准备升级到7.0，为了不6.8中的弃用警告，能够将参数设置为true或false，在7.0中，设置include_type_name将致使一个弃用警告。

查看一些与Elasticsearch交互的例子，这个选项设置为false：

PUT index?include_type_name=false
{
  "mappings": {
    "properties": { 
      "foo": {
        "type": "keyword"
      }
    }
  }
}
  • 映射直接包含在mappings键下，没有类型名称。
PUT index/_mappings?include_type_name=false
{
  "properties": { 
    "bar": {
      "type": "text"
    }
  }
}
  • 映射直接包含在mappings键下，没有类型名称。
GET index/_mappings?include_type_name=false

上面的调用返回：

{
  "index": {
    "mappings": {
      "properties": { 
        "foo": {
          "type": "keyword"
        },
        "bar": {
          "type": "text"
        }
      }
    }
  }
}
  • 映射直接包含在mappings键下，没有类型名称。

文档API

在7.0中，必须使用{index}/_doc路径调用索引API，以便自动生成_id，使用显式id调用{index}/_doc/{id}。

PUT index/_doc/1
{
  "foo": "baz"
}
{
  "_index": "index",
  "_id": "1",
  "_type": "_doc",
  "_version": 1,
  "result": "created",
  "_shards": {
    "total": 2,
    "successful": 1,
    "failed": 0
  },
  "_seq_no": 0,
  "_primary_term": 1
}

相似地，get和delete API使用路径{index}/_doc/{id}：

GET index/_doc/1
在7.0中， _doc表示端点名称，而不是文档类型， _doc组件是文档 index、 get和 delete API路径的永久部分，在8.0中不会被删除。

对于同时包含类型和端点名（如_update）的API路径，在7.0中端点将当即跟随索引名：

POST index/_update/1
{
    "doc" : {
        "foo" : "qux"
    }
}

GET /index/_source/1

类型也不该该再出如今请求体中，下面的bulk索引示例省略了URL和单个批量命令中的类型：

POST _bulk
{ "index" : { "_index" : "index", "_id" : "3" } }
{ "foo" : "baz" }
{ "index" : { "_index" : "index", "_id" : "4" } }
{ "foo" : "qux" }

搜索API

在调用诸如_search、_msearch或_explain之类的搜索API时，URL中不该该包含类型，此外，_type字段不该该用于查询、聚合或脚本。

响应中的类型

文档和搜索API将继续在响应中返回_type键，以免中断响应解析，然而，键被认为是不同意的，不该该再被引用，类型将在8.0中从响应中彻底删除。

注意，当使用废弃的类型化API时，索引的映射类型将做为正常返回，可是无类型API将在响应中返回虚拟类型_doc，例如，下面的无类型get调用老是返回_doc做为类型，即便映射有一个像my_type这样的自定义类型名：

PUT index/my_type/1
{
  "foo": "baz"
}

GET index/_doc/1
{
    "_index" : "index",
    "_type" : "_doc",
    "_id" : "1",
    "_version" : 1,
    "_seq_no" : 0,
    "_primary_term" : 1,
    "found": true,
    "_source" : {
        "foo" : "baz"
    }
}

索引模版

建议经过将include_type_name设置为false来从新添加索引模板，使其无类型，在底层，无类型模板在建立索引时将使用虚拟类型_doc。

若是将无类型模板用于类型化索引建立调用，或者将类型化模板用于无类型索引建立调用，则仍将应用模板，但索引建立调用将决定是否应该有类型。例如在下面的示例中，index-1-01将具备一个类型，尽管它匹配一个没有类型的模板，而index-2-01将具备无类型，尽管它匹配一个定义了类型的模板，index-1-01和index-2-01都将从匹配的模板中继承foo字段。

PUT _template/template1
{
  "index_patterns":[ "index-1-*" ],
  "mappings": {
    "properties": {
      "foo": {
        "type": "keyword"
      }
    }
  }
}

PUT _template/template2?include_type_name=true
{
  "index_patterns":[ "index-2-*" ],
  "mappings": {
    "type": {
      "properties": {
        "foo": {
          "type": "keyword"
        }
      }
    }
  }
}

PUT index-1-01?include_type_name=true
{
  "mappings": {
    "type": {
      "properties": {
        "bar": {
          "type": "long"
        }
      }
    }
  }
}

PUT index-2-01
{
  "mappings": {
    "properties": {
      "bar": {
        "type": "long"
      }
    }
  }
}

在隐式索引建立的状况下，由于文档在索引中被索引，而索引还不存在，因此老是使用模板，这一般不是一个问题，由于无类型索引调用要处理有类型的索引。

混合版本的集群

在由6.8和7.0节点组成的集群中，应该在索引建立之类的索引API中指定参数include_type_name，这是由于参数在6.8和7.0之间有不一样的默认值，因此相同的映射定义对两个节点版本都无效。

诸如bulk和update之类的无类型文档API仅在7.0版本时可用，不能用于6.8节点，对于执行文档查找的查询的无类型版本，如terms，也是如此。

相关文章
相关标签/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公众号
   欢迎关注本站公众号,获取更多信息
联系我们 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程