Mapping 字段类型
前言
- 我们在用MySQL时,如果表结构定义不好,后期开发会不断踩坑。
- 用ES也是如此,虽然ES有mapping动态映射,但是它自动生成的不一定是我们期望的。学好ES的mapping很重要。在学习ES查询和聚合之前,应该先打好mapping的基础,学习顺序不能变。这和学习SQL一样,先学习数据类型有int,char,varchar等,然后再学习group by,having等。
核心字段类型
- ES支持的字段类型很多,但我们工作中常用的也就那些核心字段。
- 一开始学习ES时,掌握好常用的类型,不必要精通每一种,如果工作中遇到了需要用到特殊类型再去研究。
- 学习一门技术要先广度后深度,不能陷入”只见树木,不见森林“。
1 keyword
- keyword是关键词类型,ES把keyword类型的值当作词根存在倒排索引中,不进行分词。
- keyword适合存结构化数据,比如name,age,性别,手机号,status(数据状态),tags(标签),HttpCode(404,200,500)等。
- 字段常用来精确查询,过滤,排序,聚合时,应设为keyword,而不是数值型。
- 最长支持32766个UTF-8类型的字符,但放入倒排索引时,只截取前一段字符串,长度由ignore_above参数决定。
1.1 举例说明keyword
举例:数据状态字段 |
#如果一个字段经常用来放查询条件里过滤数据和聚合统计,
#最好设为keyword,而不是数值型
GET pigg/_search
{
"query": {
"term": {
"status": 2
}
}
}
1.2 ignore_above是什么?
首先随意往ES插一条数据:
put my_index/_doc/1
{
"name": "李星云"
}
查看ES自动生成的mapping,name是text类型,其下还有子类型keyword,且"ignore_above" : 256
GET /my_index/_mapping
name定义如下:
"properties" : {
"name" : {
"type" : "text",
"fields" : {
"keyword" : {
"type" : "keyword",
"ignore_above" : 256
}
}
}
}
对于keyword类型, 可设置ignore_above限定字符长度。超过 ignore_above 的字符会被存储,但不会被倒排索引。比如ignore_above=4,”abc“,”abcd“,”abcde“都能存进ES,但是不能根据”abcde“检索到数据。
【1】创建一个keyword类型的字段,ignore_above=4
PUT test_index
{
"mappings": {
"_doc": {
"properties": {
"message": {
"type": "keyword",
"ignore_above": 4
}
}
}
}
}
【2】向索引插入3条数据:
PUT /test_index/_doc/1
{
"message": "abc"
}
PUT /test_index/_doc/2
{
"message": "abcd"
}
PUT /test_index/_doc/3
{
"message": "abcde"
}
此时ES倒排索引是:
词项 | 文档ID |
---|---|
abc | 1 |
abcd | 2 |
【3】根据message进行terms聚合:
GET /test_index/_search
{
"size": 0,
"aggs": {
"term_message": {
"terms": {
"field": "message",
"size": 10
}
}
}
}
返回结果:
{
"took" : 2,
"timed_out" : false,
"_shards" : {
"total" : 5,
"successful" : 5,
"skipped" : 0,
"failed" : 0
},
"hits" : {
"total" : 3,
"max_score" : 1.0,
"hits" : [
{
"_index" : "test_index",
"_type" : "_doc",
"_id" : "2",
"_score" : 1.0,
"_source" : {
"message" : "abcd"
}
},
{
"_index" : "test_index",
"_type" : "_doc",
"_id" : "1",
"_score" : 1.0,
"_source" : {
"message" : "abc"
}
},
{
"_index" : "test_index",
"_type" : "_doc",
"_id" : "3",
"_score" : 1.0,
"_source" : {
"message" : "abcde"
}
}
]
},
"aggregations" : {
"term_message" : {
"doc_count_error_upper_bound" : 0,
"sum_other_doc_count" : 0,
"buckets" : [#注意这分组里没有”abcde“
{
"key" : "abc",
"doc_count" : 1
},
{
"key" : "abcd",
"doc_count" : 1
}
]
}
}
}
【4】根据”abcde“进行term精确查询,结果为空
GET /test_index/_search
{
"query": {
"term": {
"message": "abcde"
}
}
}
然后结果:
"hits" : {
"total" : 0,
"max_score" : null,
"hits" : [ ]
}
通过上面结果能知道”abcde“已经存入ES,也可以搜索出来,但是不存在词项”abcde“,不能根据”abcde“作为词项进行检索。
对于已存在的keyword字段,其ignore_above子属性可以修改,但只对新数据有效。
2 text
- text文本类型,如果要对字符串进行分词分析,可以设置为text。
- ES自带了很多分词器,如果是中文,可以给ES安装ik中文分词插件。
- 关于分词器属性的配置可以参考ES官网分析的章节。
2.1 举例说明text类型分词
在上面1.1.2节,新增了my_index索引,其中name是text类型。
分析在name上”I am a coder“这个短语是怎么被分词的。
GET /my_index/_analyze
{
"field": "name",
"text": "I am a coder"
}
结果如下图,这短语分成4个词项,其中大写”I“还转换为小写”i“。
字符串”I am a coder“,ES不会把这个完整的字符串保存起来,它保存的形式如下:
词 | 假设文档ID=1 |
---|---|
i | 1 |
am | 1 |
a | 1 |
coder | 1 |
所以根据”I am a coder“这完整字符串是查询不到数据的。
3 Boolean类型
判断 | ES接受的值 |
---|---|
真 | true, “true” |
假 | false, “false”,""(空字符串) |
具体代码案例参考Elasticsearch笔记(二十三) 详解mapping之boolean
4 日期类型
JSON没有date数据类型,所以ES里日期可有以下数据:
- 日期格式的字符串,如"2015-01-01"或"2015/01/01 12:10:30"
- 从开始纪元(1970-01-01 00:00:00 UTC)开始的毫秒数-长整型
- 从开始纪元(1970-01-01 00:00:00 UTC)开始的秒数-整型
上面的UTC(Universal Time Coordinated) 叫做世界统一时间,中国大陆和 UTC 的时差是 + 8 ,也就是 UTC+8。在ES内部,时间以毫秒数的UTC存储。
date的格式可以被指定的,如果没有特殊指定,默认格式是"strict_date_optional_time||epoch_millis"
这段话可以理解为格式为strict_date_optional_time或者epoch_millis
4.1 什么是epoch_millis?
epoch_millis就是从开始纪元(1970-01-01 00:00:00 UTC)开始的毫秒数-长整型。
4.2 什么是strict_date_optional_time?
strict_date_optional_time是date_optional_time的严格级别,这个严格指的是年份、月份、天必须分别以4位、2位、2位表示,不足两位的话第一位需用0补齐。
常见的格式有如下:
- yyyy
- yyyyMM
- yyyyMMdd
- yyyyMMddHHmmss
- yyyy-MM
- yyyy-MM-dd
- yyyy-MM-ddTHH:mm:ss
- yyyy-MM-ddTHH:mm:ss.SSS
- yyyy-MM-ddTHH:mm:ss.SSSZ
工作常见到是"yyyy-MM-dd HH:mm:ss",但是ES是不支持这格式的,需要在dd后面加个T,这个是固定格式。上面最后一个里大写的"Z"表示时区。
下面做测试:
#新增一个索引,设置birthday是date格式。
PUT /test_date_index
{
"mappings": {
"_doc":{
"properties":{
"birthday":{
"type": "date"
}
}
}
}
}
#插入yyyy-MM-dd HH:mm:ss格式
PUT /test_date_index/_doc/3
{
"birthday": "2020-03-01 16:29:41"
}
结果报错:
"caused_by": {
"type": "illegal_argument_exception",
"reason": "Invalid format: \"2020-03-01 16:29:41\" is malformed at \" 16:29:41\""
}
#插入 yyyy-MM-ddTHH:mm:ss格式,ES返回成功
PUT /test_date_index/_doc/4
{
"birthday": "2020-03-01T16:29:41"
}
4.3 你就是想用yyyy-MM-dd HH:mm:ss?
date类型,还支持一个参数format,它让我们可以自己定制化日期格式。
比如format配置了“格式A||格式B||格式C”,插入一个值后,会从左往右匹配,直到有一个格式匹配上。
#先删除索引
DELETE test_date_index
#重建索引
PUT /test_date_index
{
"mappings": {
"_doc":{
"properties":{
"birthday":{
"type": "date",
"format": "yyyy-MM-dd HH:mm:ss||yyyy-MM-dd||epoch_millis"
}
}
}
}
}
#2020/03/01 17:44:09的毫秒级时间戳
PUT /test_date_index/_doc/1
{
"birthday": 1583055849000
}
PUT /test_date_index/_doc/2
{
"birthday": "2020-03-01 16:29:41"
}
PUT /test_date_index/_doc/3
{
"birthday": "2020-02-29"
}
#上面3条语句都可以保存成功
5 数字:Numeric
为了提高性能和减少存储空间,选择一个满足存放你数据的类型就可以,没有必要选择过长的类型。比如各地人口数量,一般用integer存储足够了,没有必要使用long类型。
类型 | 说明 |
---|---|
byte | 8位,-128 ~ 127 |
short | 16位,-32768 ~ 32767 |
integer | 32位,-231 ~ 231-1 |
long | 64位,-263 ~ 263-1 |
float | 单精度、32位、符合IEEE 754标准的浮点数 |
double | 双精度、64位、符合IEEE 754标准的浮点数 |
half_float | 16位半精度IEEE 754浮点类型 |
scaled_float | 缩放类型的的浮点数 |
5.1 创建一个新的索引
PUT pigg_test_num
{
"mappings": {
"properties": {
"num_of_byte": {
"type": "byte"
},
"num_of_short": {
"type": "short"
},
"num_of_integer": {
"type": "integer"
},
"num_of_long": {
"type": "long"
},
"num_of_float": {
"type": "float"
},
"num_of_double": {
"type": "double"
}
}
}
}
5.2 插入正确的数据
PUT pigg_test_num/_doc/1
{
"num_of_byte": 127,
"num_of_short": 32767,
"num_of_integer": 2147483647,
"num_of_long": 9223372036854775807,
"num_of_float": 0.33333,
"num_of_double": 11111111111111.11111111111111111
}
查看文档的数据
GET pigg_test_num/_search
返回:
{
"hits":[
{
"_index":"pigg_test_num",
"_type":"_doc",
"_id":"1",
"_score":1,
"_source":{
"num_of_byte":127,
"num_of_short":32767,
"num_of_integer":2147483647,
"num_of_long":9223372036854776000,
"num_of_float":0.33333,
"num_of_double":11111111111111.111
}
}
]
}
5.3 插入越界的数据
short的最大值是32767
PUT pigg_test_num/_doc/2
{
"num_of_byte": 127,
"num_of_short": 32768
}
返回报错
"reason" : "Numeric value (32768) out of range of Java short..."
5.4 给整数赋值浮点数
给long类型赋值浮点数, 虽然能够存储成功,但是已经丢失了精度,所以工作中不能这么用
PUT pigg_test_num/_doc/1
{
"num_of_long": 9223372036854775807.0001
}
返回
"_source" : {
"num_of_long" : 9.223372036854776E18
}
5.5 给整数赋值浮点数的字符串
给long类型赋值浮点数, 虽然能够存储成功, 但是存的就是字符串,而不是数字.
PUT pigg_test_num/_doc/1
{
"num_of_long": "9223372036854775807.0001"
}
返回
"_source" : {
"num_of_long" : "9223372036854775807.0001"
}
下面验证存的是字符串而不是数字
#期望给long的值加上2
POST pigg_test_num/_update/1
{
"script": {
"source": "ctx._source.num_of_long += 2",
"lang": "painless"
}
}
# 返回值却是给字符串拼接加上字符"2"
"_source" : {
"num_of_long" : "9223372036854775807.00012"
}
总结: 综合上面错误的实验, 可以知道工作中还是得传正确格式和范围的数字.
6 二进制类型:binary
ES能接受以Base64编码的二进制值,binary字段是不会被分析存储和检索的。因为它的值就是一巨长的乱码,对它分析毫无意义, 它只是被原模原样的存储。
工作中可能用binary存储图像,但情况也不多,用ES存图像不是很好的选择。
Base64编码简单说下,如下图:对单词"Man",它Base64编码是TWFu。