Elasticsearch-入门到精通-6 document元数据

开篇：本篇的内容大多摘自ES 权威指南，及网络，个人的原话可能比较少。

什么是文档

程序中大多的实体或对象能够被序列化为包含键值对的JSON对象，键(key)是字段(field)或属性(property)的名字，值(value)可以是字符串、数字、布尔类型、另一个对象、值数组或者其他特殊类型，比如表示日期的字符串或者表示地理位置的对象。

{
	"name": "John Smith",
	"age": 42,
	"confirmed": true,
	"join_date": "2014-06-01",
	"home": {
		"lat": 51.5,
		"lon": 0.1
		},
	"accounts": [
		{
			"type": "facebook",
			"id": "johnsmith"
		},
		{
			"type": "twitter",
			"id": "johnsmith"
		}
	]
}

通常，我们可以认为对象(object)和文档(document)是等价相通的。不过，他们还是有所差别：对象(Object)是一个JSON结构体——类似于哈希、hashmap、字典或者关联数组；对象(Object)中还可能包含其他对象(Object)。 在Elasticsearch中，文档(document)这个术语有着特殊含义。它特指最顶层结构或者根对象(root object)序列化成的JSON数据（以唯一ID标识并存储于Elasticsearch中） 。

文档元数据

一个文档不只有数据。它还包含了元数据(metadata)——关于文档的信息。三个必须的元数据节点是：

节点	说明
_index	文档存储的地方
_type	文档代表的对象的类
_id	文档的唯一标识

_index

索引(index)类似于关系型数据库里的“数据库”——它是我们存储和索引关联数据的地方。

提示：
事实上，我们的数据被存储和索引在分片(shards)中，索引只是一个把一个或多个分片分组在一起的逻辑空间。
然而，这只是一些内部细节——我们的程序完全不用关心分片。
对于我们的程序而言，文档存储在索引(index)中。剩下的细节由Elasticsearch关心既可。

_type

在应用中，我们使用对象表示一些“事物”，例如一个用户、一篇博客、一个评论，或者一封邮件。每个对象都属于一个类(class)，这个类定义了属性或与对象关联的数据。 user 类的对象可能包含姓名、性别、年龄和Email地址。

在关系型数据库中，我们经常将相同类的对象存储在一个表里，因为它们有着相同的结构。
同理，在Elasticsearch中，我们使用相同类型(type)的文档表示相同的“事物”，因为他们的数
据结构也是相同的。

每个类型(type)都有自己的映射(mapping)或者结构定义，就像传统数据库表中的列一样。所
有类型下的文档被存储在同一个索引下，但是类型的映射(mapping)会告诉Elasticsearch不同
的文档如何被索引。 我们将会在《映射》 章节探讨如何定义和管理映射，但是现在我们将依
赖Elasticsearch去自动处理数据结构。

_type 的名字可以是大写或小写，不能包含下划线或逗号。我们将使用 blog 做为类型名。

_id

id仅仅是一个字符串，它与 _index 和 _type 组合时，就可以在Elasticsearch中唯一标识一个文档。当创建一个文档，你可以自定义 _id ，也可以让Elasticsearch帮你自动生成。

使用自己的ID
如果你的文档有自然的标识符（例如 user_account 字段或者其他值表示文档） ，你就可以提供自己的 _id ，使用这种形式的 index API：

PUT /{index}/{type}/{id}
{
	"field": "value",
	...
}

自增ID
如果我们的数据没有自然ID，我们可以让Elasticsearch自动为我们生成。请求结构发生了变化： PUT 方法—— “在这个URL中存储文档” 变成了 POST 方法—— “在这个类型下存储文档” 。（译者注：原来是把文档存储到某个ID对应的空间，现在是把这个文档添加到某个 _type 下） 。
URL现在只包含 _index 和 _type 两个字段：

POST /website/blog/
{
	"title": "My second blog entry",
	"text": "Still trying this out...",
	"date": "2014/01/01"
}

_source

1、我们在创建一个document的时候，使用的那个放在request body中的json串，默认情况下，在get的时候，会原封不动的给我们返回回来。
如下加入一条数据：

put /test_index/test_type/1
{
  "test_field1": "test field1",
  "test_field2": "test field2"
}

查询结果：

get /test_index/test_type/1

{
  "_index": "test_index",
  "_type": "test_type",
  "_id": "1",
  "_version": 2,
  "found": true,
  "_source": {
    "test_field1": "test field1",
    "test_field2": "test field2"
  }
}

2、查询操作时，可以定制返回的结果，指定_source中，返回哪些field，类似于sql语句中 select c1,c2,c3… from select 和from中间的那一段字段。还是如上

GET /test_index/test_type/1?_source=test_field2

{
	  "_index": "test_index",
	  "_type": "test_type",
	  "_id": "1",
	  "_version": 2,
	  "found": true,
	  "_source": {
	    "test_field2": "test field2"
	  }
}

_version

代表的是document的版本。在ES中，为document定义了版本信息，document数据每次变化，代表一次版本的变更。版本变更可以避免数据错误问题（并发问题，乐观锁），同时提供ES的搜索效率。
第一次创建Document时，_version版本号为1，默认情况下，后续每次对Document执行修改或删除操作都会对_version数据自增1。
删除Document也会_version自增1。
当使用PUT命令再次增加同id的Document，_version会继续之前的版本继续自增。

这里补充说明：delete操作在ES中都是“假删除”，会将该条数据标记为delete，版本号随之增长。什么时候物理删除呢？ES认为数据量大的时候会进行物理删除。（数据量多大算大？这个问题我也还在探索，明确了算法之后更新本文。）