Elasticsearch：constant keyword 資料型別

Constant keyword 是 keyword 欄位的特例，用于索引中所有檔案具有相同值的情況，比如，

PUT logs-debug
{
  "mappings": {
    "properties": {
      "@timestamp": {
        "type": "date"
      },
      "message": {
        "type": "text"
      },
      "level": {
        "type": "constant_keyword",
        "value": "debug"
      }
    }
  }
}

constant_keyword 支持與 keyword 欄位相同的查詢和聚合，但利用所有檔案每個索引具有相同值的事實來更有效地執行查詢，

允許提交沒有欄位值或值等于映射中配置的值的檔案， 以下兩個索引請求是等效的：

POST logs-debug/_doc
{
  "date": "2019-12-12",
  "message": "Starting up Elasticsearch",
  "level": "debug"
}

POST logs-debug/_doc
{
  "date": "2019-12-12",
  "message": "Starting up Elasticsearch"
}

如果我們進行如下的查詢：

GET logs-debug/_search
{
  "query": {
    "match": {
      "level": "debug"
    }
  }
}

上面查詢顯示的結果是：

{
  "took" : 1,
  "timed_out" : false,
  "_shards" : {
    "total" : 1,
    "successful" : 1,
    "skipped" : 0,
    "failed" : 0
  },
  "hits" : {
    "total" : {
      "value" : 2,
      "relation" : "eq"
    },
    "max_score" : 1.0,
    "hits" : [
      {
        "_index" : "logs-debug",
        "_type" : "_doc",
        "_id" : "5-kGLnsBpDPgC7Zlr6gp",
        "_score" : 1.0,
        "_source" : {
          "date" : "2019-12-12",
          "message" : "Starting up Elasticsearch",
          "level" : "debug"
        }
      },
      {
        "_index" : "logs-debug",
        "_type" : "_doc",
        "_id" : "6OkGLnsBpDPgC7Zlt6gM",
        "_score" : 1.0,
        "_source" : {
          "date" : "2019-12-12",
          "message" : "Starting up Elasticsearch"
        }
      }
    ]
  }
}

從上面，我們可以看到盡管第二個檔案里沒有明顯的欄位 level，但是它還是被搜索出來了，

如果我們在寫入檔案時填寫和 mapping 中定義不一樣的值時，它就會報錯，比如：

POST logs-debug/_doc
{
  "date": "2019-12-12",
  "message": "Starting up Elasticsearch",
  "level": "info"
}

在上面的 level 中，我們給它不同的值 info 而不是 debug，那么我們可以看到如下的錯誤資訊：

{
  "error" : {
    "root_cause" : [
      {
        "type" : "mapper_parsing_exception",
        "reason" : "failed to parse field [level] of type [constant_keyword] in document with id '6ekZLnsBpDPgC7ZlSKhU'. Preview of field's value: 'info'"
      }
    ],
    "type" : "mapper_parsing_exception",
    "reason" : "failed to parse field [level] of type [constant_keyword] in document with id '6ekZLnsBpDPgC7ZlSKhU'. Preview of field's value: 'info'",
    "caused_by" : {
      "type" : "illegal_argument_exception",
      "reason" : "[constant_keyword] field [level] only accepts values that are equal to the value defined in the mappings [debug], but got [info]"
    }
  },
  "status" : 400
}

如果沒有值在映射設定，該欄位將基于包含在所述第一索引檔案中的值自動進行配置，雖然這種行為可以方便，請注意，這意味著一個有毒檔案可能會導致拒絕所有其他檔案，如果它有一個錯誤的值，比如：

PUT logs-info
{
  "mappings": {
    "properties": {
      "@timestamp": {
        "type": "date"
      },
      "message": {
        "type": "text"
      },
      "level": {
        "type": "constant_keyword"
      }
    }
  }
}

在上面，我們定義了 level 的型別，但是我們沒有定義它的值，那么當我們使用如下的方法寫入兩個檔案時：

POST logs-info/_doc
{
  "date": "2019-12-12",
  "message": "Starting up Elasticsearch",
  "level": "info"
}

POST logs-info/_doc
{
  "date": "2019-12-12",
  "message": "Starting up Elasticsearch"
}

因為第一個檔案里定義的 level 的值為 info，那么之后所有的檔案將視 info 為索引 logs-info 欄位 level 的默認值，我們可以做如下的查詢：

GET logs-info/_search
{
  "query": {
    "match": {
      "level": "info"
    }
  }
}

我們可以同時查詢到上面的兩個檔案，

在沒有提供任何的值之前（或者通過映射或檔案），查詢的欄位將不會匹配任何檔案，這包括 exists 查詢，

一旦這個欄位的值被確定后，之后就不可以更改，

很多人想，這個欄位到底有啥用途呢？就像之前提到的針對 constant_keyword 欄位的查詢非常高效，這種情況適用于我們做如下的查詢：

GET logs-*/_search
{
  "query": {
    "match": {
      "level": "info"
    }
  }
}

在我們已經創建 logs-debug 及 logs-info 的索引的情況下，

constant_keyword 欄位被廣泛使用于 Elastic datastream 的命名方案中，