Mapping (mapping)

As explained by data in, data out, each document in index has a type. Each type has its own mapping or schema definition. Define filed in type mapping, define the data type in each filed, define how ES handles this filed,mapping is also used to configure the metadata associated with that type.

We will discuss mapping in detail in Types and mappings, and in this chapter we will be able to get you started enough.

Core simple field types

ES supports the following simple filed type:

string:	string
Whole Number:	byte ,  short ,  integer ,  long
Floating point:	float ,  double
Boolean:	boolean
Date:	date / p>

When you index a document that contains a new type--that is, the--es that is not mentioned in the table above uses the type of the filed from the data types in JSON based on dynamic mapping to try guessing:

JSON Type:	Field Type:
Boolean: true orfalse	"boolean"
Whole Number:123	"long"
Floating point:123.45	"double"
String, valid date:"2014-09-15"	"date"
String:"foo bar"	"string"

That is, if you index a number that is enclosed in double quotation marks, it becomes a string, not a long. However, if the field has been mapped to a mapping, Long,es will attempt to convert to long, and if not, it will report an exception.

Viewing the mapping

We can look at the mapping that ES already owns, whether the mapping is mapped to a type or multiple type, whether it is an index or multiple index. Use/_mapping as the end of the request. In the start of this chapter we have retrieved the mapping of tweets in GB:

/ GB / _mapping / Tweet

The return value shows the mapping (which is the Properties property) of the field dynamically generated by ES based on the index's document:

{
"GB":{
"Mappings":{
"tweet":{
"Properties":{
"Date":{
"Type":"Date",
"Format":"Dateoptionaltime"
},
"Name":{
"Type":"string"
},
"tweet":{
"Type":"string"
},
"user_id":{
"Type":"Long"
}
}
}
}
}
}

Incorrect mapping, such as mapping age to string rather than integer, results in confusing the query.

customizing field mappings

The most important property of field is type, and for a field that is not of type string, you rarely mapping other properties except type.

{
"Number_of_clicks" : {
"Type" : "integer"
}
}

String Type field, the default is the type of the full text, that is, before storing their value to go through the word breaker, and the full text of the search also go through the same word breaker to the word breaker.

The two most important mapping properties for a string type are index and analyzer.

index

This property controls how the string is stored. The value is one of three,

1:analyzed--first to the word, and then stored, that is, the field as full text.

2:not_analyzed--Store This field so that it can be searched, but to store it exactly, don't word it.

3:no--do not store this field. This field is also non-searchable.

The default value is analyzed. If you want to think of him as the exact value, you need the following settings:

{
"Tag" : {
"Type" :  "string",
"Index" :   "not_analyzed"
}
}

Other simple Type--long,double,date, etc.-also accept the index parameter, but the value is no and not_analyzed, because their value is not analyzed.

analyzer

For string field, using the analyzed property is a word breaker to be applied when you specify index and search, and the default ES uses standard, but you can modify the value of this property, such as: Whitespace,simple,english:

{
"tweet" : {
"Type" :  "string",
"Analyzer" : "中文版"
}
}

In custom analyzers We'll show you how to customize a analyzed.

Updating a mapping

When you create index for the first time, you can specify a mapping. Of course, you can also use/_mapping to add mapping (or a mapping of an already existing type) to a new type.

Once you add a mapping, it is best not to modify him, if a field has been mapping, it is possible this filed has stored the data, if this time to modify this filed mapping, The previous index data will result in an error and become non-searchable.

You can update the mapping for the newly added field, but it is best not to not_analyzed the existing field from analyzed.

To demonstrate all the ways to specify mapping, we first remove the GB index:

/ GB

Then create a new index, specifying the tweet field using the English word breaker:

PUT/GB
{
"Mappings":{
"tweet":{
"Properties":{
"tweet":{
"Type":    "string",
"Analyzer":"中文版"
},
"Date":{
"Type":   "Date"
},
"Name":{
"Type":   "string"
},
"user_id":{
"Type":   "Long"
}
}
}
}
}

Mark 1 indicates that index is created using the specified mapping.

Next, we add a field named tag to the tweet, and add the Not_analyzed property to the new field:

PUT/GB/_mapping/Tweet
{
"Properties":{
"Tag":{
"Type":    "string",
"Index":    "Not_analyzed"
}
}
}

Now, we don't need to list the existing field, because we can't modify them, our new field has been merged into the existing mapping.

Testing the mapping

You can test mapping with the Analyze API using field name. Compare the output of two requests:

/ GB / _analyze ? Field = Tweet
Black -

/ GB / _analyze ? Field = tag
Black -

This tweet field produced two term "black" and "cat", whereas Tagfield produced a single term "black-cat". In other words, our mapping has been working properly.

Original: http://www.elasticsearch.org/guide/en/elasticsearch/guide/current/mapping-intro.html