Elasticsearch
指標と型の違い

備考

GET /cars/_search

GET /cars/bmw/_search

GET /cars/_search
{
  "query": {
    "bool": {
      "filter": [
        {
          "term" : {
            "_type": "bmw"
          }
        }
      ]
    }
  }
}

PUT /cars
{
  "manufacturer": { <1>
    "properties": {
      "make": { <2>
        "type": "string",
        "index": "not_analyzed"
      }
    }
  }
}

PUT /cars
{
  "manufacturer": { <1>
    "properties": {
      "make": { <2>
        "type": "keyword"
      }
    }
  }
}

型を持つ索引を明示的に作成する

例では、cURLやその他のHTTPアプリケーションに簡単に変換できる基本HTTPを使用しています。また、 Sense構文と一致し、Kibana 5.0のConsoleに名前が変更されます。

注：この例では、部品に注意を促すために<#>を挿入しています。それらをコピーすると削除する必要があります！

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

1. これは、create indexエンドポイントを使用してindexを作成しています。
2. これはtype作成しています。
3. 同じindex内のtype sの共有フィールドは、同じ定義を共有する必要があります。 ES 1.xは厳密にこの動作を強制しませんでしたが、暗黙の要件でした。 ES 2.x以上ではこの動作が厳密に強制されます。
4. typeの一意のフィールドは大丈夫です。

インデックス（またはインデックス）には型が含まれます。タイプはドキュメントを分離する便利なメカニズムですが、使用する各タイプのマッピングを動的/自動または明示的に定義する必要があります。インデックスに15種類のタイプを定義すると、15の一意のマッピングがあります。

このコンセプトの詳細とタイプを使用するかどうかについては、備考を参照してください。

タイプでインデックスを動的に作成する

例では、cURLやその他のHTTPアプリケーションに簡単に変換できる基本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>
  }
}

1. 既に存在する場合（前の例のため）、索引を削除します。
2. 文書を索引my_indexに、タイプmy_type ID abc123 （数値でも可能ですが、常に文字列です）に索引付けします。
   • デフォルトでは、動的索引の作成は、文書を索引付けするだけで有効になります。これは開発環境には最適ですが、本番環境では必ずしも良いとは限りません。
3. このフィールドは整数であるため、最初に表示されるときはマッピングする必要があります。 Elasticsearchは常にすべての着信タイプに対して最も広いタイプを想定しているため、 integerまたはshortではなくlongとしてマッピングされます（両方とも1234と456含む可能性があります）。
4. このフィールドでも同じことが当てはまります。あなたが望むかもしれないように、 floatではなくdoubleとしてマップされます。

この動的に作成されるインデックスとタイプは、最初の例で定義されたマッピングとほぼ一致します。ただし、 <3>および<4>が自動的に定義されたマッピングにどのように影響するかを理解することは重要です。

同じ索引にさらに別のタイプを動的に追加することで、これを実行できます。

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

1. タイプは上記の文書との唯一の違いです。 IDは同じで、大丈夫です！これは、他とは関係ありませんabc123同じインデックスであることを起こるということ以外に。
2. field1すでに索引に存在するため、他の型で定義されているフィールドと同じタイプのフィールドでなければなりません 。文字列か整数でない値を"field1": "this is some text"すると失敗します（例"field1": "this is some text"または"field1": 123.0 ）。

これは、動的のマッピング作成しmy_other_type同じインデックス、内my_index 。

注：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"
      }
    }
  }
}

1. これは_mappingsエンドポイントを使用して、作成したインデックスからマッピングを取得します。
2. この例の最初のステップでは、 my_typeを動的に作成しmy_typeた。
3. field2は、前もって定義していなかったので、 integerではなく、 longとなりました。これは 、ディスクストレージでは無駄であることがわかります。
4. object1.field1は＃3と同じ理由でdoubleになり、＃3と同じ結果になりました。
   • 技術的には、多くの場合、 long圧縮が可能です。ただし、 doubleは浮動小数点数であるため圧縮できません。
5. この例の2番目のステップでは、 my_other_typeも動的に作成しmy_other_typeた。私たちが既にlongとdoubleを使用していたので、そのマッピングは同じになりました。
   • ことを覚えておいてくださいfield1から定義と一致しなければなりません my_type （そしてそれがありません）。
   • field3はこのタイプに固有なので、そのような制限はありません。