索引一个文档

文档通过索引API被索引——存储并使其可搜索。但是最开始我们需要决定我们将文档存储在哪里。正如之前提到的，一篇文档通过_index, _type以及_id来确定它的唯一性。我们可以自己提供一个_id，或者也使用indexAPI 帮我们生成一个。

使用自己的ID

如果你的文档拥有天然的标示符（例如user_account字段或者文档中其他的标识值），这时你就可以提供你自己的_id，这样使用indexAPI：

  1. PUT /{index}/{type}/{id}
  2. {
  3.   "field": "value",
  4.   ...
  5. }

几个例子。如果我们的索引叫做"website"，我们的类型叫做 "blog"，然后我们选择"123"作为ID的编号。这时，请求就是这样的：

  1. PUT /website/blog/123
  2. {
  3.   "title": "My first blog entry",
  4.   "text":  "Just trying this out...",
  5.   "date":  "2014/01/01"
  6. }

Elasticsearch返回内容：

  1. {
  2.    "_index":    "website",
  3.    "_type":     "blog",
  4.    "_id":       "123",
  5.    "_version":  1,
  6.    "created":   true
  7. }

这个返回值意味着我们的索引请求已经被成功创建，其中还包含了_index, _type以及_id的元数据，以及一个新的元素_version。

在Elasticsearch中，每一个文档都有一个版本号码。每当文档产生变化时（包括删除），_version就会增大。在《版本控制》中，我们将会详细讲解如何使用_version的数字来确认你的程序不会随意替换掉不想覆盖的数据。

自增ID

如果我们的数据中没有天然的标示符，我们可以让Elasticsearch为我们自动生成一个。请求的结构发生了变化：我们把PUT——“把文档存储在这个地址中”变量变成了POST——“把文档存储在这个地址下”。

这样一来，请求中就只包含 _index和_type了：

  1. POST /website/blog/
  2. {
  3.   "title": "My second blog entry",
  4.   "text":  "Still trying this out...",
  5.   "date":  "2014/01/01"
  6. }

这次的反馈和之前基本一样，只有_id改成了系统生成的自增值:

  1. {
  2.    "_index":    "website",
  3.    "_type":     "blog",
  4.    "_id":       "wM0OSFhDQXGZAWDf0-drSA",
  5.    "_version":  1,
  6.    "created":   true
  7. }

自生成ID是由22个字母组成的，安全
universally unique identifiers 或者被称为UUIDs。