元字段

2019-09-08 23:05发布

元字段

每个文档都有与之关联的元数据,例如_index、映射 _type_id元字段。创建映射类型时,可以自定义某些元字段的行为。

_ignored 字段

_ignored 字段索引并存储已被忽略的字段名称,ignore_malformed开启,字段错误会被忽略,而不报错

例如,以下查询匹配具有一个或多个被忽略的字段的所有文档:

GET _search
{
  "query": {
    "exists": {
      "field": "_ignored"
    }
  }
}

同样,以下查询查找@timestamp索引时忽略其字段的所有文档:

GET _search
{
  "query": {
    "term": {
      "_ignored": "@timestamp"
    }
  }
}

_id field

每个文档都有一个_id唯一标识它的文档,它被编入索引,以便可以使用GET API或 ids查询查找文档。

_id字段值可在特定查询使用(term, termsmatchquery_stringsimple_query_string)。

# Example documents
PUT my_index/_doc/1
{
  "text": "Document with ID 1"
}

PUT my_index/_doc/2&refresh=true
{
  "text": "Document with ID 2"
}

GET my_index/_search
{
  "query": {
    "terms": {
      "_id": [ "1", "2" ] 
    }
  }
}

_id字段的值也可以在聚合中进行访问或用于排序,但不鼓励这样做,因为它需要在内存中加载大量数据。如果需要对_id字段进行排序或聚合,建议复制_id字段的内容到一个已启用doc_values 的另一个字段中。

_id 限制为512字节,超过将被拒绝。

_index field

在跨多个索引执行查询时,有时需要添加仅与某些索引的文档关联的查询子句。该_index字段允许在索引上匹配文档。用于访问term,或terms查询,汇总,脚本和排序:

_index作为虚拟字段 - 它不会作为真实字段添加到Lucene索引中。这意味着,你可以使用_index字段查询termtermsterm 查询内的query,如matchquery_stringsimple_query_string查询),但它不支持prefixwildcardregexp,或fuzzy查询。

# Example documents
PUT index_1/_doc/1
{
  "text": "Document in index 1"
}

PUT index_2/_doc/2?refresh=true
{
  "text": "Document in index 2"
}

GET index_1,index_2/_search
{
  "query": {
    "terms": {
      "_index": ["index_1", "index_2"] 
    }
  },
  "aggs": {
    "indices": {
      "terms": {
        "field": "_index", 
        "size": 10
      }
    }
  },
  "sort": [
    {
      "_index": { 
        "order": "asc"
      }
    }
  ],
  "script_fields": {
    "index_name": {
      "script": {
        "lang": "painless",
        "source": "doc['_index']" 
      }
    }
  }
}

_meta field

映射类型可以具有与之关联的自定义元数据。Elasticsearch根本不使用它们,但可以用于存储特定于应用程序的元数据,例如文档所属的类:

PUT my_index
{
  "mappings": {
    "_meta": { 
      "class": "MyApp::User",
      "version": {
        "min": "1.0",
        "max": "1.3"
      }
    }
  }
}

_meta可以使用GET映射 API 检索此信息 。

_meta可以使用PUT映射 API 在现有类型上更新该字段 :

PUT my_index/_mapping
{
  "_meta": {
    "class": "MyApp2::User3",
    "version": {
      "min": "1.3",
      "max": "1.5"
    }
  }
}

_routingfield

使用以下公式将文档路由到索引中的特定分片:

shard_num = hash(_routing)%num_primary_shards

_routing默认值是文档_id

可以通过为routing 每个文档指定自定义值来实现自定义路由模式。例如:

PUT my_index/_doc/1?routing=user1&refresh=true     # 使用user1而不是ID
{
  "title": "This is a document"
}

GET my_index/_doc/1?routing=user1               #获取,删除或更新 文档时需要提供相同的routing值 。

_routing可以在查询中访问该字段的值:

GET my_index/_search
{
  "query": {
    "terms": {
      "_routing": [ "user1" ] 
    }
  }
}

自定义路由可以减少搜索量。将请求发送到与特定路由值(或多个值)匹配的分片,而不是索引中的所有分片,

GET my_index/_search?routing=user1,user2 
{
  "query": {
    "match": {
      "title": "document"
    }
  }
}

使用自定义路由时,在索引获取, 删除更新文档时提供路由值非常重要。

忘记路由值可能导致文档被索引到多个分片上。作为安全措施,_routing可以将该字段配置为所有CRUD操作都必须制定:

PUT my_index2
{
  "mappings": {
    "_routing": {
      "required": true    # 配置为必须制定自定义routing
    }
  }
}

PUT my_index2/_doc/1 
{
  "text": "No routing value provided"    # 未指定routing 报错routing_missing_exception
}

索引指定自定义_routing的文档时,相同_id不能保证索引在同一分片 。实际上,如果使用不同的_routing值索引,具有相同_id文档的文档可能最终会出现在不同的分片上。

应确保ID在索引中是唯一的。

路由到索引分区

可以配置索引,使得自定义路由值将转到分片的子集而不是单个分片。这有助于降低结束不平衡群集的风险,同时仍然可以减少搜索的影响。

这是通过index.routing_partition_size在索引创建时提供索引级别设置来完成的。随着分区大小的增加,数据分布越均匀,代价是每个请求必须搜索更多分片。

当此设置存在时,计算分片的公式变为:

shard_num = (hash(_routing) + hash(_id) % routing_partition_size) % num_primary_shards

也就是说,该_routing字段用于计算索引中的一组分片,然后 _id用于在该集合中选择分片。

要启用此功能,index.routing_partition_size应该具有大于1且小于index.number_of_shards的值。

启用后,分区索引将具有以下限制:

  • 无法在其中创建具有join字段关系的映射。
  • 索引中的所有映射都必须将_routing字段标记为必需。

_source field

_source字段包含在索引时传递的原始JSON文档正文。_source本身没有索引字段(因此不可搜索),但它被保存,以便它可以在执行fetch请求时返回 ,比如get or search

禁用_source字段

虽然非常方便,但源字段确实会在索引中产生存储开销。因此,可以按如下方式禁用它:

PUT tweets
{
  "mappings": {
    "_source": {
      "enabled": false
    }
  }
}

在禁用该_source字段之前考虑如下后果:

如果该_source字段不可用,则不支持许多功能:

  • updateupdate_by_queryreindexAPI的。
  • highlighting
  • 从一个Elasticsearch索引重新索引到另一个索引,以更改映射或分析,或将索引升级到新的主要版本。
  • 通过查看索引时使用的原始文档来调试查询或聚合的功能。
  • 将来可能会自动修复索引损坏的能力。
如果磁盘空间确实不足,应该考虑增加压缩级别而不是禁用_source。

指标用例(如监控CPU,内存等等数据)

指标使用的情况下,与其他基于时间或记录使用情况不同,因为有它仅包含数字,日期或关键字的许多小文件。没有更新,没有突出显示请求,数据快速老化,因此无需重新索引。搜索请求通常使用简单查询按日期或标记过滤数据集,结果将作为聚合返回。

在这种情况下,禁用该_source字段将节省空间并减少I / O.

Including / Excluding fields from _source

_source指定存储字段内容的功能,并非存储所有,有类似于禁用_source的缺点,如果要排除字段请考虑使用 源过滤

includesexcludes参数(其也接受通配符),可以如下使用:

PUT logs
{
  "mappings": {
    "_source": {
      "includes": [
        "*.count",
        "meta.*"
      ],
      "excludes": [
        "meta.description",
        "meta.other.*"
      ]
    }
  }
}

PUT logs/_doc/1
{
  "requests": {
    "count": 10,
    "foo": "bar"   # 这些字段将从存储的_source字段中删除。
  },
  "meta": {
    "name": "Some metric",
    "description": "Some metric description", 
    "other": {
      "foo": "one", 
      "baz": "two" 
    }
  }
}

GET logs/_search
{
  "query": {
    "match": {
      "meta.other.foo": "one"   # 我们仍然可以搜索此字段,即使它不在存储中_source。
    }
  }
}

_type field

在6.0.0中弃用。请参阅删除映射类型

索引的每个文档都与一个_type(参见 映射类型)和_id相关联。该_type场是为了使按类型名称快速搜索索引。

_type可以在查询,聚合,脚本和排序时访问该字段的值:

# Example documents

PUT my_index/_doc/1?refresh=true
{
  "text": "Document with type 'doc'"
}

GET my_index/_search
{
  "query": {
    "term": {
      "_type": "_doc"  
    }
  },
  "aggs": {
    "types": {
      "terms": {
        "field": "_type", 
        "size": 10
      }
    }
  },
  "sort": [
    {
      "_type": { 
        "order": "desc"
      }
    }
  ],
  "script_fields": {
    "type": {
      "script": {
        "lang": "painless",
        "source": "doc['_type']" 
      }
    }
  }
}

登录 后发表评论
0条评论
还没有人评论过~