Elasticsearch:mapping定制

Elasticsearch依据我们提供的数据,根据自己的估计,并自动生成相应的mapping。这在很多的时候是非常有用的。 它可以帮我们自动省很多的手动操作,而且在大多数的情况下,Elasticsearch帮我们自动生成的mapping也是有效的。一般来讲,如果我们想自己定义自己的mapping的话,如下的步骤将是可取的,也是推荐的方法:

  1. 把自己的一个数据输入到Elasticsearch中
  2. 得到上面输入数据的mapping,并在此基础上进行调整,从而得出适合自己数据的mapping

在下面我们以几个例子来展示几个我们需要调整的地方。

 

调整数据类型

我们首先在我们的Kibana中输入如下的一个命令:

PUT myindex/_doc/1
{
  "status_code": 404
}

上面创建一个叫做myindex的索引,它里面含有一个我们通常见到的HTTP请求的status_code。在这里我们的文档的值为404。我们通过如下的命令来显示这个myindex的mapping。请记住这个mapping是在第一次数据输入时,根据我们输入的数据猜出来的:

GET myindex/_mapping

上面的命令显示的结果是:

{
  "myindex" : {
    "mappings" : {
      "properties" : {
        "status_code" : {
          "type" : "long"
        }
      }
    }
  }
}

从上面的结果中,我们可以看出来type为long,意味着这将是一个64bit的数据长度。我们知道HTTP的status_code,通常就是小于1000的数据。这样一个64 bit的数据显然浪费存储空间。如果我们的数据是很少,这个可能并不算是什么,但是如果我们有海量的数据,那么这个存储空间的浪费将是很大的。为此,我们可以把这个数据类型修改为short类型的, 也就是16 bit:

PUT myindex1
{
  "mappings": {
    "properties": {
      "status_code": {
        "type": "short"
      }
    }
  }
}

在上面,我们创建的myindex1的mapping里定义status_code为short类型。

如果你之前看过我的另外一篇文章“开始使用Elasticsearch (2)”,我们在那里也调整一个geo_point的数据类型。比如:

PUT twitter/_doc/1
{
  "user": "zhangsan",
  "location": {
    "lat": "39.970718",
    "lon": "116.325747"
  }
}

我们看看Elasticsearch帮我们生产的数据类型:

GET twitter/_mapping
{
  "twitter" : {
    "mappings" : {
      "properties" : {
        "location" : {
          "properties" : {
            "lat" : {
              "type" : "text",
              "fields" : {
                "keyword" : {
                  "type" : "keyword",
                  "ignore_above" : 256
                }
              }
            },
            "lon" : {
              "type" : "text",
              "fields" : {
                "keyword" : {
                  "type" : "keyword",
                  "ignore_above" : 256
                }
              }
            }
          }
        },
        "user" : {
          "type" : "text",
          "fields" : {
            "keyword" : {
              "type" : "keyword",
              "ignore_above" : 256
            }
          }
        }
      }
    }
  }
}

显然,在上面我们可以看到lat及lon都被估算为text类型,而且是一个multi-field的数据类型,这显然不是我们所需要的。另外,我们的user类型,我们并不想它是一个text类型的。那么我们可以作如下的调整:

PUT twitter1
{
  "mappings": {
    "properties": {
      "location": {
        "type": "geo_point"
      },
      "user": {
        "type": "keyword"
      }
    }
  }
}

在上面的twitter1中,我们可以看出来调整后的location类型为geo_point的数据类型,而user也变成了我们所希望的keyword类型。

动态的mapping并不总是优化的

针对一个浮点数来说:

PUT my_index/_doc/1
{
  "price": 1.99
}

我们可以得到它的mapping:

GET my_index/_mapping
{
  "my_index" : {
    "mappings" : {
      "properties" : {
        "price" : {
          "type" : "float"
        }
      }
    }
  }
}

从上面我们可以看出来,price的数据类型是一个float类型。对于大多数的情况来说,这个应该没有问题。但是在实际的应用中,我们可以把这个float数据类型转换为scaled float数据类型。Scaled float由long数据类型来支持。long数据类型在Lucene里可以被更加有效地压缩,从而节省存储的空间。在使用scaled float数据类型时,你必须使用scaling_factore来配置它的精度:

PUT my_index1/_doc/1
{
  "mappings": {
    "properties": {
      "price": {
        "type": "scaled_float",
        "scaling_factor": 100
      }
    }
  }
}

在上面我们定义price类型为scaled_float数据类型,并定义scaling_factor为100。这样我们的数据,比如1.99刚好可以在乘以100变为199,从而成为一个整型数。

经过这样的改造后,我们可以试试重新在my_index1里输入一个文档:

PUT my_index1/_doc/1
{
  "price": 1.99
}

我们通过如下的方法来查询这个数据:

GET my_index1/_doc/1

返回的结果是:

{
  "_index" : "my_index1",
  "_type" : "_doc",
  "_id" : "1",
  "_version" : 2,
  "_seq_no" : 1,
  "_primary_term" : 1,
  "found" : true,
  "_source" : {
    "price" : 1.99
  }
}

从上面我们可以看出来,尽管我们修改了我们的数据类型,但是我们返回的数据还是对的。

展开阅读全文

没有更多推荐了,返回首页

应支付0元
点击重新获取
扫码支付

支付成功即可阅读