2

私はこのようなマッピングを作成しています

"institution" : {
  "properties" : {        
    "InstitutionCode" : {
      "type" : "string",
      "store" : "yes"
    },
    "InstitutionID" : {
      "type" : "integer",
      "store" : "yes"
    },
    "Name" : {
      "type" : "string",
      "store" : "yes"
    }
  }
}

ただし、機関の実際のインデックス作成操作を実行するときは、Aliasプロパティを追加しています（機関ごとに0個以上のエイリアス）

"institution" : {
  "properties" : {   
    "Aliases" : {
      "dynamic" : "true",
      "properties" : {
        "InstitutionAlias" : {
          "type" : "string"
        },
        "InstitutionAliasTypeID" : {
          "type" : "long"
        }
      }
    },     
    "InstitutionCode" : {
      "type" : "string",
      "store" : "yes"
    },
    "InstitutionID" : {
      "type" : "integer",
      "store" : "yes"
    },
    "Name" : {
      "type" : "string",
      "store" : "yes"
    }
  }
}

これは実際には単純化された例です。実際には、レコードの実際のインデックス作成中に、エイリアスだけでなく多くのフィールドを追加しているからです。

マッピング作成中にマッピングを完全に定義することはどれほど重要ですか？

追加のプロパティを持つ機関レコードのインデックス作成により、インデックス作成操作中にマッピングが自動的に調整されることにより、ペナルティが発生しますか？機関は時間の経過とともに追加のプロパティを取得することを期待しており、機関インデックスコードに加えてマッピング作成コードを維持する必要があるのではないかと思います。

4

1 に答える 1

3

動的マッピングのオーバーヘッドはかなり無視できると思います...それらを使用してもインデックス作成の速度を損なうことはありません。ただし、ElasticSearchがフィールドタイプを誤って自動検出するという予期しない状況が発生する可能性があります。

フィールドの最初の例は数値（「25」）であるため、一般的な例は整数の検出ですが、実際にはそのフィールドの残りのデータは文字列です。または、残りのデータが実際には浮動小数点数であるときに整数が表示されます。等

データが十分に標準化されていれば、それほど問題にはなりません。

または、動的テンプレートを使用して、正規表現パターンに基づいて新しいフィールドにマッピングを適用することもできます。

于 2013-01-18T14:54:50.533 に答える