使用型別動態建立索引

Created: November-22, 2018

示例使用基本 HTTP，它可以輕鬆轉換為 cURL 和其他 HTTP 應用程式。它們還匹配 Sense 語法，該語法將在 Kibana 5.0 中重新命名為 Console。

注意：示例插入 <#> 以幫助引起對零件的注意。如果你複製它們應該被刪除！

DELETE /my_index <1>

PUT /my_index/my_type/abc123 <2>
{
  "field1" : 1234, <3>
  "field2" : 456,
  "object1" : {
    "field1" : 7.8 <4>
  }
}

如果它已經存在（由於前面的例子），刪除索引。
將文件索引到索引 my_index 中，型別為 my_type，ID 為 abc123（可以是數字，但它始終是一個字串）。
- 預設情況下，只需索引文件即可啟用動態索引建立。這對於開發環境來說非常好，但對於生產環境來說並不一定好。
此欄位是整數，因此第一次看到它必須對映。Elasticsearch 總是假定任何傳入型別的最寬型別，因此這將被對映為 long 而不是 integer 或 short（兩者都可以包含 1234 和 456）。
這個領域也是如此。它將被對映為 double 而不是 float，如你所願。

此動態建立的索引和型別大致匹配第一個示例中定義的對映。但是，理解 <3> 和 <4> 如何影響自動定義的對映至關重要。

你可以通過將另一種型別動態新增到同一索引來實現此目的：

PUT /my_index/my_other_type/abc123 <1>
{
  "field1": 91, <2>
  "field3": 4.567
}

該型別是與上述文件的唯一區別。ID 是一樣的，沒關係！它與其他 abc123 沒有任何關係，只是它碰巧在同一個索引中。
field1 已存在於索引中，因此它必須與其他型別中定義的欄位型別相同。提交一個字串或不是整數的值會失敗（例如，"field1": "this is some text" 或 "field1": 123.0）。

這將在同一索引 my_index 中動態建立 my_other_type 的對映。

注意：預先定義對映總是更快，而不是讓 Elasticsearch 在索引時動態執行它。

索引兩個文件的最終結果與第一個示例類似，但欄位型別會有所不同，因此會略有浪費：

GET /my_index/_mappings <1>
{
  "mappings": {
    "my_type": { <2>
      "properties": {
        "field1": {
          "type": "long"
        },
        "field2": {
          "type": "long" <3>
        },
        "object1": {
          "type": "object",
          "properties": {
            "field1" : {
              "type": "double" <4>
            }
          }
        }
      }
    }
  },
  "my_other_type": { <5>
    "properties": {
      "field1": {
        "type": "long"
      },
      "field3": {
        "type": "double"
      }
    }
  }
}

這使用 _mappings 端點從我們建立的索引中獲取對映。
我們在本例的第一步動態建立了 my_type。
field2 現在是 long 而不是 integer 因為我們沒有預先定義它。這可能證明在磁碟儲存中是浪費的。
object1.field1 現在是一個 double，其原因與#3 相同，與#3 具有相同的分支。
- 從技術上講，long 可以在很多情況下進行壓縮。但是，由於它是浮點數，因此無法壓縮 double。
我們還在本例的第二步中動態建立了 my_other_type。它的對映恰好相同，因為我們已經在使用 long 和 double。
- 請記住，field1 必須與 my_type 的定義匹配（它確實如此）。
- field3 是這種型別的獨特之處，所以它沒有這樣的限制。