Numeric · Elasticsearch 5.4 中文文档

# Numeric 原文链接 : [https://www.elastic.co/guide/en/elasticsearch/reference/current/number.html#number](https://www.elastic.co/guide/en/elasticsearch/reference/current/number.html#number) 译文链接 : [Numeric](/display/Elasticsearch/Numeric) 贡献者 : [彭秋源](/display/~pengqiuyuan)，[ApacheCN](/display/~apachecn)，[Apache中文网](/display/~apachechina) ## Numeric 数据类型支持以下数字类型： | 1 | | | 2 | | | 3 | | | 4 | | | 5 | | | 6 | | | 7 | | | 8 | | 以下是使用数字字段配置映射的示例： ``` PUT my_index { "mappings": { "my_type": { "properties": { "number_of_bytes": { "type": "integer" }, "time_in_seconds": { "type": "float" }, "price": { "type": "scaled_float", "scaling_factor": 100 } } } } } ``` 注意 The `double`, `float` and `half_float` types consider that `-0.0` and `+0.0` are different values. As a consequence, doing a `term` query on `-0.0` will not match `+0.0` and vice-versa. Same is true for range queries: if the upper bound is `-0.0` then `+0.0` will not match, and if the lower bound is `+0.0` then `-0.0` will not match. ### 我应该使用哪种类型？ As far as integer types (`byte`, `short`, `integer` and `long`) are concerned, you should pick the smallest type which is enough for your use-case. This will help indexing and searching be more efficient. Note however that given that storage is optimized based on the actual values that are stored, picking one type over another one will have no impact on storage requirements. For floating-point types, it is often more efficient to store floating-point data into an integer using a scaling factor, which is what the `scaled_float` type does under the hood. For instance, a `price`field could be stored in a `scaled_float` with a `scaling_factor` of `100`. All APIs would work as if the field was stored as a double, but under the hood elasticsearch would be working with the number of cents, `price*100`, which is an integer. This is mostly helpful to save disk space since integers are way easier to compress than floating points. `scaled_float` is also fine to use in order to trade accuracy for disk space. For instance imagine that you are tracking cpu utilization as a number between `0` and `1`. It usually does not matter much whether cpu utilization is `12.7%` or `13%`, so you could use a `scaled_float` with a `scaling_factor` of `100` in order to round cpu utilization to the closest percent in order to save space. If `scaled_float` is not a good fit, then you should pick the smallest type that is enough for the use-case among the floating-point types: `double`, `float` and `half_float`. Here is a table that compares these types in order to help make a decision. | 类型 | 最小值 | 最大值 | Significant bits / digits | | double | | | | | float | | | | | half_float | | | | ### 数字字段数字类型接受以下参数： | [`coerce`](https://www.elastic.co/guide/en/elasticsearch/reference/current/coerce.html "coerce") | 尝试将字符串转换为数字并截断整数的分数。接受 `true`（默认）和 `false`。 | | [`boost`](https://www.elastic.co/guide/en/elasticsearch/reference/current/mapping-boost.html "boost") | Mapping field-level query time boosting. Accepts a floating point number, defaults to `1.0`. | | [`doc_values`](https://www.elastic.co/guide/en/elasticsearch/reference/current/doc-values.html "doc_values") | Should the field be stored on disk in a column-stride fashion, so that it can later be used for sorting, aggregations, or scripting? Accepts `true` (default) or `false` | | [`ignore_malformed`](https://www.elastic.co/guide/en/elasticsearch/reference/current/ignore-malformed.html "ignore_malformed") | If `true`, malformed numbers are ignored. If `false` (default), malformed numbers throw an exception and reject the whole document. | | [`include_in_all`](https://www.elastic.co/guide/en/elasticsearch/reference/current/include-in-all.html "include_in_all") | Whether or not the field value should be included in the [`_all`](https://www.elastic.co/guide/en/elasticsearch/reference/current/mapping-all-field.html "_all field") field? Accepts `true` or `false`. Defaults to `false` if [`index`](https://www.elastic.co/guide/en/elasticsearch/reference/current/mapping-index.html "index") is set to `false`, or if a parent[`object`](https://www.elastic.co/guide/en/elasticsearch/reference/current/object.html "Object datatype") field sets `include_in_all` to `false`. Otherwise defaults to `true`. | | [`index`](https://www.elastic.co/guide/en/elasticsearch/reference/current/mapping-index.html "index") | Should the field be searchable? Accepts `true` (default) and `false` | | [`null_value`](https://www.elastic.co/guide/en/elasticsearch/reference/current/null-value.html "null_value") | Accepts a numeric value of the same `type` as the field which is substituted for any explicit `null` values. Defaults to `null`, which means the field is treated as missing. | | [`store`](https://www.elastic.co/guide/en/elasticsearch/reference/current/mapping-store.html "store") | Whether the field value should be stored and retrievable separately from the [`_source`](https://www.elastic.co/guide/en/elasticsearch/reference/current/mapping-source-field.html "_source field") field. Accepts `true` or `false` (default). | ### Parameters for `scaled_float` `scaled_float` accepts an additional parameter: | `scaling_factor` | The scaling factor to use when encoding values. Values will be multiplied by this factor at index time and rounded to the closest long value. For instance, a `scaled_float` with a `scaling_factor` of `10` would internally store `2.34` as `23`and all search-time operations (queries, aggregations, sorting) will behave as if the document had a value of `2.3`. High values of `scaling_factor` improve accuracy but also increase space requirements. This parameter is required. |