elasticsearch映射<七>
映射及分析
当在索引中处理数据时，我们注意到一些奇怪的事。有些东西似乎被破坏了：
在索引中有12个tweets，只有一个包含日期2014-09-15，但是我们看看下面查询中的total hits。
GET /_search?q=2014 # 12 个结果
GET /_search?q=2014-09-15 # 还是 12 个结果 !
GET /_search?q=date:2014-09-15 # 1 一个结果
GET /_search?q=date:2014 # 0 个结果 !
为什么全日期的查询返回所有的tweets，而针对date字段进行年度查询却什么都不返回？ 为什么我们的结果因查询_all字段(译者注：默认所有字段中进行查询)或date字段而变得不同？
想必是因为我们的数据在_all字段的索引方式和在date字段的索引方式不同而导致。
让我们看看Elasticsearch在对gb索引中的tweet类型进行mapping(也称之为模式定义[注：此词有待重新定义(schema definition)])后是如何解读我们的文档结构：
GET /gb/_mapping/tweet
返回：
{
"gb": {
"mappings": {
"tweet": {
"properties": {
"date": {
"type": "date",
"format": "dateOptionalTime"
},
"name": {
"type": "string"
},
"tweet": {
"type": "string"
},
"user_id": {
"type": "long"
}
}
}
}
}
}
Elasticsearch为对字段类型进行猜测，动态生成了字段和类型的映射关系。返回的信息显示了date字段被识别为date类型。_all因为是默认字段所以没有在此显示，不过我们知道它是string类型。
date类型的字段和string类型的字段的索引方式是不同的，因此导致查询结果的不同，这并不会让我们觉得惊讶。
你会期望每一种核心数据类型(strings, numbers, booleans及dates)以不同的方式进行索引，而这点也是现实：在Elasticsearch中他们是被区别对待的。
但是更大的区别在于确切值(exact values)(比如string类型)及全文文本(full text)之间。
这两者的区别才真的很重要 - 这是区分搜索引擎和其他数据库的根本差异。
核心简单字段类型
Elasticsearch支持以下简单字段类型：
| 类型 | 表示的数据类型 |
|---|---|
| String | string |
| Whole number | byte, short, integer, long |
| Floating point | float, double |
| Boolean | boolean |
| Date | date |
当你索引一个包含新字段的文档——一个之前没有的字段——Elasticsearch将使用动态映射猜测字段类型，这类型来自于JSON的基本数据类型，使用以下规则：
| JSON type | Field type |
|---|---|
Boolean: true or false |
"boolean" |
Whole number: 123 |
"long" |
Floating point: 123.45 |
"double" |
String, valid date: "2014-09-15" |
"date" |
String: "foo bar" |
"string" |
映射
为了能够把日期字段处理成日期，把数字字段处理成数字，把字符串字段处理成全文本（Full-text）或精确的字符串值，Elasticsearch需要知道每个字段里面都包含了什么类型。这些类型和字段的信息存储（包含）在映射（mapping）中。
正如《数据吞吐》一节所说，索引中每个文档都有一个类型(type)。 每个类型拥有自己的映射(mapping)或者模式定义(schema definition)。一个映射定义了字段类型，每个字段的数据类型，以及字段被Elasticsearch处理的方式。映射还用于设置关联到类型上的元数据。
在《映射》章节我们将探讨映射的细节。这节我们只是带你入门。
核心简单字段类型
Elasticsearch支持以下简单字段类型：
| 类型 | 表示的数据类型 |
|---|---|
| String | string |
| Whole number | byte, short, integer, long |
| Floating point | float, double |
| Boolean | boolean |
| Date | date |
当你索引一个包含新字段的文档——一个之前没有的字段——Elasticsearch将使用动态映射猜测字段类型，这类型来自于JSON的基本数据类型，使用以下规则：
| JSON type | Field type |
|---|---|
Boolean: true or false |
"boolean" |
Whole number: 123 |
"long" |
Floating point: 123.45 |
"double" |
String, valid date: "2014-09-15" |
"date" |
String: "foo bar" |
"string" |
注意
这意味着，如果你索引一个带引号的数字——
"123"，它将被映射为"string"类型，而不是"long"类型。然而，如果字段已经被映射为"long"类型，Elasticsearch将尝试转换字符串为long，并在转换失败时会抛出异常。
查看映射
我们可以使用_mapping后缀来查看Elasticsearch中的映射。在本章开始我们已经找到索引gb类型tweet中的映射：
GET /gb/_mapping/tweet
这展示给了我们字段的映射（叫做属性(properties)），这些映射是Elasticsearch在创建索引时动态生成的：
{
"gb": {
"mappings": {
"tweet": {
"properties": {
"date": {
"type": "date",
"format": "strict_date_optional_time||epoch_millis"
},
"name": {
"type": "string"
},
"tweet": {
"type": "string"
},
"user_id": {
"type": "long"
}
}
}
}
}
}
小提示
错误的映射，例如把
age字段映射为string类型而不是integer类型，会造成查询结果混乱。要检查映射类型，而不是假设它是正确的！
自定义字段映射
虽然大多数情况下基本数据类型已经能够满足，但你也会经常需要自定义一些特殊类型（fields），特别是字符串字段类型。 自定义类型可以使你完成一下几点：
- 区分全文（full text）字符串字段和准确字符串字段（译者注：就是分词与不分词，全文的一般要分词，准确的就不需要分词，比如『中国』这个词。全文会分成『中』和『国』，但作为一个国家标识的时候我们是不需要分词的，所以它就应该是一个准确的字符串字段）。
- 使用特定语言的分析器（译者注：例如中文、英文、阿拉伯语，不同文字的断字、断词方式的差异）
- 优化部分匹配字段
- 指定自定义日期格式（译者注：这个比较好理解,例如英文的
Feb,12,2016和 中文的2016年2月12日） - 以及更多
映射中最重要的字段参数是type。除了string类型的字段，你可能很少需要映射其他的type：
{
"number_of_clicks": {
"type": "integer"
}
}
string类型的字段，默认的，考虑到包含全文本，它们的值在索引前要经过分析器分析，并且在全文搜索此字段前要把查询语句做分析处理。
对于string字段，两个最重要的映射参数是index和analyer。
index
index参数控制字符串以何种方式被索引。它包含以下三个值当中的一个：
| 值 | 解释 |
|---|---|
analyzed |
首先分析这个字符串，然后索引。换言之，以全文形式索引此字段。 |
not_analyzed |
索引这个字段，使之可以被搜索，但是索引内容和指定值一样。不分析此字段。 |
no |
不索引这个字段。这个字段不能为搜索到。 |
string类型字段默认值是analyzed。如果我们想映射字段为确切值，我们需要设置它为not_analyzed：
{
"tag": {
"type": "string",
"index": "not_analyzed"
}
}
其他简单类型（
long、double、date等等）也接受index参数，但相应的值只能是no和not_analyzed，它们的值不能被分析。
分析
对于analyzed类型的字符串字段，使用analyzer参数来指定哪一种分析器将在搜索和索引的时候使用。默认的，Elasticsearch使用standard分析器，但是你可以通过指定一个内建的分析器来更改它，例如whitespace、simple或english。
{
"tweet": {
"type": "string",
"analyzer": "english"-----指定分词器
}
}
在《自定义分析器》章节我们将告诉你如何定义和使用自定义的分析器。
更新映射
你可以在第一次创建索引的时候指定映射的类型。此外，你也可以晚些时候为新类型添加映射（或者为已有的类型更新映射）。
重要
你可以向已有映射中增加字段，但你不能修改它。如果一个字段在映射中已经存在，这可能意味着那个字段的数据已经被索引。如果你改变了字段映射，那已经被索引的数据将错误并且不能被正确的搜索到。
我们可以更新一个映射来增加一个新字段，但是不能把已有字段的类型那个从analyzed改到not_analyzed。
为了演示两个指定的映射方法，让我们首先删除索引gb：
DELETE /gb
然后创建一个新索引，指定tweet字段的分析器为english：
PUT /gb <1>
{
"mappings": {
"tweet" : {
"properties" : {
"tweet" : {
"type" : "string",
"analyzer": "english"
},
"date" : {
"type" : "date"
},
"name" : {
"type" : "string"
},
"user_id" : {
"type" : "long"
}
}
}
}
}
<1> 这将创建包含mappings的索引，映射在请求体中指定。
再后来，我们决定在tweet的映射中增加一个新的not_analyzed类型的文本字段，叫做tag，使用_mapping后缀:
PUT /gb/_mapping/tweet
{
"properties" : {
"tag" : {
"type" : "string",
"index": "not_analyzed"
}
}
}
注意到我们不再需要列出所有的已经存在的字段，因为我们没法修改他们。我们的新字段已经被合并至存在的那个映射中。
测试映射
你可以通过名字使用analyze API测试字符串字段的映射。对比这两个请求的输出：
GET /gb/_analyze?field=tweet&text=Black-cats <1>
GET /gb/_analyze?field=tag&text=Black-cats <2>
<1> <2> 我们想要分析的文本被放在请求体中。
tweet字段产生两个词，"black"和"cat",tag字段产生单独的一个词"Black-cats"。换言之，我们的映射工作正常。
我的例子：
PUT /gb { "mappings": { "tweet" : { "properties" : { "tweet" : { "type" : "string", "analyzer": "english" }, "date" : { "type" : "date" }, "name" : { "type" : "string" }, "user_id" : { "type" : "long" } } } } } PUT /gb/_mapping/tweet { "properties" : { "tag" : { "type" : "string", "index": "not_analyzed" } } } GET /gb/_analyze?field=tweet&text=Black-cats PUT /gb/test/1 { "tweet":"i like it", "date":"2016-06-03", "user_id":"333" } GET /gb/test/1
复合核心字段类型
除了之前提到的简单的标量类型，JSON还有null值，数组和对象，所有这些Elasticsearch都支持：
多值字段
我们想让tag字段包含多个字段，这非常有可能发生。我们可以索引一个标签数组来代替单一字符串：
{ "tag": [ "search", "nosql" ]}
对于数组不需要特殊的映射。任何一个字段可以包含零个、一个或多个值，同样对于全文字段将被分析并产生多个词。
言外之意，这意味着数组中所有值必须为同一类型。你不能把日期和字符窜混合。如果你创建一个新字段，这个字段索引了一个数组，Elasticsearch将使用第一个值的类型来确定这个新字段的类型。
当你从Elasticsearch中取回一个文档，任何一个数组的顺序和你索引它们的顺序一致。你取回的
_source字段的顺序同样与索引它们的顺序相同。然而，数组是做为多值字段被索引的，它们没有顺序。在搜索阶段你不能指定“第一个值”或者“最后一个值”。倒不如把数组当作一个值集合(bag of values)
空字段
当然数组可以是空的。这等价于有零个值。事实上，Lucene没法存放null值，所以一个null值的字段被认为是空字段。
这四个字段将被识别为空字段而不被索引：
"empty_string": "",
"null_value": null,
"empty_array": [],
"array_with_null_value": [ null ]
多层对象
我们需要讨论的最后一个自然JSON数据类型是对象(object)——在其它语言中叫做hash、hashmap、dictionary 或者 associative array.
内部对象(inner objects)经常用于在另一个对象中嵌入一个实体或对象。例如，做为在tweet文档中user_name和user_id的替代，我们可以这样写：
{
"tweet": "Elasticsearch is very flexible",
"user": {
"id": "@johnsmith",
"gender": "male",
"age": 26,
"name": {
"full": "John Smith",
"first": "John",
"last": "Smith"
}
}
}
内部对象的映射
Elasticsearch 会动态的检测新对象的字段，并且映射它们为 object 类型，将每个字段加到 properties字段下
{
"gb": {
"tweet": { <1>
"properties": {
"tweet": { "type": "string" },
"user": { <2>
"type": "object",
"properties": {
"id": { "type": "string" },
"gender": { "type": "string" },
"age": { "type": "long" },
"name": { <3>
"type": "object",
"properties": {
"full": { "type": "string" },
"first": { "type": "string" },
"last": { "type": "string" }
}
}
}
}
}
}
}
}
<1> 根对象.
<2><3> 内部对象.
对user和name字段的映射与tweet类型自己很相似。事实上，type映射只是object映射的一种特殊类型，我们将 object 称为根对象。它与其他对象一模一样，除非它有一些特殊的顶层字段，比如 _source,_all 等等。
内部对象是怎样被索引的
Lucene 并不了解内部对象。 一个 Lucene 文件包含一个键-值对应的扁平表单。 为了让 Elasticsearch 可以有效的索引内部对象，将文件转换为以下格式：
{
"tweet": [elasticsearch, flexible, very],
"user.id": [@johnsmith],
"user.gender": [male],
"user.age": [26],
"user.name.full": [john, smith],
"user.name.first": [john],
"user.name.last": [smith]
}
内部栏位可被归类至name，例如"first"。 为了区别两个拥有相同名字的栏位，我们可以使用完整路径，例如"user.name.first" 或甚至类型名称加上路径："tweet.user.name.first"。
注意： 在以上扁平化文件中，并没有栏位叫作
user也没有栏位叫作user.name。 Lucene 只索引阶层或简单的值，而不会索引复杂的资料结构。
对象-数组
内部对象数组
最后，一个包含内部对象的数组如何索引。 我们有个数组如下所示：
{
"followers": [
{ "age": 35, "name": "Mary White"},
{ "age": 26, "name": "Alex Jones"},
{ "age": 19, "name": "Lisa Smith"}
]
}
此文件会如我们以上所说的被扁平化，但其结果会像如此：
{
"followers.age": [19, 26, 35],
"followers.name": [alex, jones, lisa, smith, mary, white]
}
{age: 35}与{name: Mary White}之间的关联会消失，因每个多值的栏位会变成一个值集合，而非有序的阵列。 这让我们可以知道：
- 是否有26岁的追随者？
但我们无法取得准确的资料如：
- 是否有26岁的追随者且名字叫Alex Jones？
关联内部对象可解决此类问题，我们称之为嵌套对象，我们之後会在嵌套对象中提到它。
浙公网安备 33010602011771号