ElasticSearch如何添加，检索数据

Elasticsearch是一个分布式的文档(document)存储引擎。它可以实时存储并检索复杂数据结构——序列化的JSON文档。换言说，一旦文档被存储在Elasticsearch中，它就可以在集群的任一节点上被检索。

当然，我们不仅需要存储数据，还要快速的批量查询。虽然已经有很多NoSQL的解决方案允许我们以文档的形式存储对象，但它们依旧需要考虑如何查询这些数据，以及哪些字段需要被索引以便检索时更加快速。

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

文档元数据（Document MetaData）：

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

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

_index

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

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

后面会继续探讨如何创建并管理索引，但现在，我们将让Elasticsearch为我们创建索引。我们唯一需要做的仅仅是选择一个索引名。这个名字必须是全部小写，不能以下划线开头，不能包含逗号。让我们使用

website

做为索引名。

_type

在应用中，我们使用对象表示一些“事物”，例如一个用户、一篇博客、一个评论，或者一封邮件。每个对象都属于一个类(class)，这个类定义了属性或与对象关联的数据。

user

类的对象可能包含姓名、性别、年龄和Email地址。

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

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

_type

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

blog

做为类型名。

_id

id仅仅是一个字符串，它与

_index

和

_type

组合时，就可以在ELasticsearch中唯一标识一个文档。当创建一个文档，你可以自定义

_id

，也可以让Elasticsearch帮你自动生成。

ps：还有其它部分其它元数据，后续再介绍。

使用自己的ID

如果你的文档有自然的标识符（例如

user_account

字段或者其他值表示文档），你就可以提供自己的

_id

，使用这种形式的

index

 API：

PUT /{index}/{type}/{id}

｛"key": "value"...｝

如，PUT /website/blog/123

{
  "title": "My blog entry",
  "text":  "汉语你可以。。 ",
  "date":  "2015/07/16"
}

{

   "_index": "website",

   "_type": "blog",

   "_id": "123",

   "_version": 5,

   "created": false

}
Elasticsearch中每个文档都有版本号，每当文档变化（包括删除）都会使

_version

增加。后续我们将探讨如何使用

_version

号确保你程序的一部分不会覆盖掉另一部分所做的更改。

自增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":  "2015/07/16"
}

响应内容与刚才类似，只有

_id

字段变成了自动生成的值：

{
"_index":    "website",
"_type":     "blog",
"_id":       "AU6Vi9GsUzILmCnC2hkX",
"_version":  1,
"created":   true
}

更新整个文档

文档在Elasticsearch中是不可变的——我们不能修改他们。如果需要更新已存在的文档，我们可以使用《索引文档》提到的

index

 API 重建索引(reindex) 或者替换掉它。

PUT /website/blog/123
{
"title": "My first blog entry",
"text":  "I am starting to get the hang of this...",
"date":  "2014/01/02"
}

在响应中，我们可以看到Elasticsearch把

_version

增加了。

{
"_index" :   "website",
"_type" :    "blog",
"_id" :      "123",
"_version" : 2,
"created":   false <1>
}

<1> 

created

标识为

false

因为同索引、同类型下已经存在同ID的文档。
在内部，Elasticsearch已经标记旧文档为删除并添加了一个完整的新文档。旧版本文档不会立即消失，但你也不能去访问它。Elasticsearch会在你继续索引更多数据时清理被删除的文档。

在后面探讨

update

 API，这个API 似乎 允许你修改文档的局部，但事实上Elasticsearch遵循与之前所说完全相同的过程，这个过程如下：

从旧文档中检索JSON
修改它
删除旧文档
索引新文档
唯一的不同是

update

 API完成这一过程只需要一个客户端请求既可，不再需要

get

和

index

请求了。

删除文档

删除文档的语法模式与之前基本一致，只不过要使用

DELETE

方法：

DELETE /website/blog/1234

如果文档被找到，Elasticsearch将返回

200 OK

状态码和以下响应体。注意

_version

数字已经增加了。

{
"found" :    true,
"_index" :   "website",
"_type" :    "blog",
"_id" :      "1234",
"_version" : 3
}

如果文档未找到，我们将得到一个

404 Not Found

状态码，响应体是这样的：

{
"found" :    false,
"_index" :   "website",
"_type" :    "blog",
"_id" :      "1234",
"_version" : 4
}

尽管文档不存在——"found"的值是false——_version依旧增加了。这是内部记录的一部分，它确保在多节点间不同操作可以有正确的顺序。删除一个文档也不会立即从磁盘上移除，它只是被标记成已删除。Elasticsearch将会在你之后添加更多索引的时候才会在后台进行删除内容的清理。