Elasticsearch 的一些常見疑問（持續更新中）

數據類型

keyword和text有什麼區別？

keyword用於索引結構化內容的字段，例如電子郵件地址，主機名，狀態碼，郵政編碼或標籤。
一般用於過濾（找到個人全部博客文章，其中 status爲published），排序，和聚合。keyword類型的字段只能按其準確值進行搜索。text是用於全文檢索的數據類型，存儲時會經過分詞器對數據進行分詞存儲，搜索時會對分詞後的多個短語進行搜索。text類型不適用用於排序和聚合。

日期類型

Elasticsearch提供了date類型來處理日期,可是因爲JSON是沒有日期類型的，因此在內部日期被轉換爲UTC而且存儲爲時間戳（帶毫秒）。
插入日期時若是插入的爲常規日期格式（yyyy-MM-dd或者yyyy-MM-dd'T'HH:mm:ss.SSSZ），es會自動識別日期格式，將字段類型設置爲Date。若是mapping中字段類型已經肯定爲Date，此時插入格式化日期字符串或者時間戳(字符串和Numeric類型)時都會被Es做爲日期類型存儲，只不過在數據顯示上和存儲時的格式一致（存時間戳返回就是時間戳，字符串返回就是字符串，可是推薦存標準化的UTC時間或時間戳，避免類型不一致）。

時區問題

A：Elasticsearch默認爲UTC時間，即零時區，查詢時若不指定時區，則默認以0時區查詢，和咱們所在的東八區差8小時。yyyy-MM-dd'T'HH:mm:ss.SSSZ，這裏的Z就表明UTC時區。
Es在進行日期查詢/聚合時能夠指定時區：

//日期範圍查詢
POST datatypetest/_search
{
  "query": {
    "range": {
      "date3": {
        "gte": "2018-07-05",
        "lte": "now",
        "time_zone": "Asia/Shanghai"//這就是東八區（北京時間/中國標準時間）
      }
    }
  }
}

//日期聚合
GET my_index/_search?size=0
{
  "aggs": {
    "by_day": {
      "date_histogram": {
        "field":     "date",
        "interval":  "day",
        "time_zone": "Asia/Shanghai"
      }
    }
  }
}

//Java獲取系統時區id
TimeZone.getDefault().getID()

//Es Java Api日期範圍查詢
QueryBuilders
                .rangeQuery("your date field")
                .gte("your date from")
                .lte("your date to")
                .timeZone(TimeZone.getDefault().getID());//此處只能設置時區id

//Es Java Api日期聚合查詢
AggregationBuilders
                .dateHistogram("your alias")
                .timeZone(DateTimeZone.getDefault());//獲取系統默認時區，此處timeZone對象是joda包中的DateTimeZone

在使用Kibana時，Kibana會默認獲取瀏覽器時區，在顯示數據時根據時區作日期的格式化。但使用DevTools寫DSL或者直接請求Es時默認返回的都是UTC時間，會發現時間少了8小時。

使用日期類型時推薦不修改日期格式時區，全部數據都用UTC時區，這樣時間統一纔不容易出問題。

object和nested類型的區別，各自的應用場景是什麼

object爲es的默認對象類型，嵌套的json對象存入es就會被默認設置爲object類型。es內部會將嵌套的json對象扁平化轉換存儲。
例如，一個普通的json

{ 
  "region": "US",
  "manager": { 
    "age":     30,
    "name": { 
      "first": "John",
      "last":  "Smith"
    }
  }
}

在es內部會被轉換爲扁平化的基礎json數據

{
  "region":             "US",
  "manager.age":        30,
  "manager.name.first": "John",
  "manager.name.last":  "Smith"
}

nested用於JSON對象的數組，它容許對象數組以可彼此獨立查詢的方式進行索引。因爲lucene沒有內部對象的概念，所以es須要把數據轉換爲簡單的扁平化結構。
一個對象數組嵌套：

{
  "group" : "fans",
  "user" : [ 
    {
      "first" : "John",
      "last" :  "Smith"
    },
    {
      "first" : "Alice",
      "last" :  "White"
    }
  ]
}

在es內部會被轉換爲：

{
  "group" :        "fans",
  "user.first" : [ "alice", "john" ],
  "user.last" :  [ "smith", "white" ]
}

user.first和user.last字段被轉換爲多值字段，數據之間的關聯性就會丟失，致使查詢結果有誤。
此時用nested類型就能夠解決此問題。

查詢

term和match匹配有什麼區別？

term爲精確匹配，查詢時不對關鍵詞進行分詞。而match用於全文檢索，首先會對檢索關鍵詞進行分詞，而後進行全文搜索。

must，filter，post_filter有什麼區別？

must爲查詢上下文（query context），查詢時會計算分值（文檔相關性）。filter爲過濾上下文，查詢時不計算分值。而post_filter爲後置過濾器，會對聚合的結果也進行過濾。執行順序爲：filter -> aggregations - post_filter。

query context & filter context區別？

must/should爲查詢上下文。filter或must_not在參數 bool的查詢中/filter在constant_score的查詢/filter aggretion這些場景中爲過濾上下文。查詢上下文會計算返回文檔的分值，而過濾上下文不計算分值，語義只是此文檔是否匹配，而不計算相關度。在過濾上下文時，es會自動對過濾器進行緩存從而提升查詢性能。