共计 5975 个字符，预计需要花费 15 分钟才能阅读完成。
本篇内容主要讲解“ElassticSearch 文档操作的方法有哪些”，感兴趣的朋友不妨来看看。本文介绍的方法操作简单快捷，实用性强。下面就让丸趣 TV 小编来带大家学习“ElassticSearch 文档操作的方法有哪些”吧!
### 第一章
###### 与 Elasticsearch 交互
节点客户端 (node client)
节点客户端以无数据节点(none data node) 身份加入集群，换言之，它自己不存储任何数据，但是它知道数据在集群中的具体位置，并且能够直接转发请求到对应的节点上。
传输客户端(Transport client)
这个更轻量的传输客户端能够发送请求到远程集群。它自己不加入集群，只是简单转发请求给集群中的节点。
基于 HTTP 协议，以 JSON 为数据交互格式的 RESTful API
其他所有程序语言都可以使用 RESTful API，通过 9200 端口的与 Elasticsearch 进行通信
###### 比较
Relational DB – Databases – Tables – Rows – Columns
Elasticsearch – Indices – Types – Documents – Fields
### 第二章 ###
#### 概念:###
索引 (index)——一个存储关联数据的地方。实际上，索引只是一个用来指向一个或多个分片(shards) 的“逻辑命名空间(logical namespace)”
一个分片 (shard) 是一个最小级别“工作单元(worker unit)”, 它只是保存了索引中所有数据的一部分(分片就是一个 Lucene 实例，并且它本身就是一个完整的搜索引擎。我们的文档存储在分片中，并且在分片中被索引，但是我们的应用程序不会直接与它们通信，取而代之的是，直接与索引通信)
分片的最大容量完全取决于你的使用状况：硬件存储的大小、文档的大小和复杂度、如何索引和查询你的文档，以及你期望的响应时间(项目做压测是需要确定，主分片的数量在创建索引时已经确定，这个数量定义了能存储到索引里数据的最大数量；然而，主分片或者复制分片都可以处理读请求——搜索或文档检索，所以数据的冗余越多，我们能处理的搜索吞吐量就越大)
如果被重启的机器有旧分片的拷贝，它将会尝试再利用它们，它只会从主分片上复制在故障期间有数据变更的那一部分
### 第三章 ###
无论程序怎么写，意图是一样的：组织数据为我们的目标所服务。但数据并不只是由随机比特和字节组成，我们在数据节点间建立关联来表示现实世界中的实体或者“某些东西”。属于同一个人的名字和 Email 地址会有更多的意义
#### 什么是文档？
键值对的 JSON 对象，键(key) 是字段 (field) 或属性 (property) 的名字，值 (value) 可以是字符串、数字、布尔类型、另一个对象、值数组或者其他特殊类型，比如表示日期的字符串或者表示地理位置的对象
在 Elasticsearch 中，文档(document) 这个术语有着特殊含义。它特指最顶层结构或者根对象 (root object) 序列化成的 JSON 数据（以唯一 ID 标识并存储于 Elasticsearch 中）
一个文档不只有数据。它还包含了元数据(metadata)：_index,_type,_id
检索文档的一部分(包含原数据):
GET /website/blog/123?_source=title,text只想得到_source 字段而不要其他的元数据，你可以这样请求：GET /website/blog/123/_source
检查文档是否存在：
curl -i -XHEAD http://localhost:9200/website/blog/123(返回 200 OK 状态如果你的文档存在, 如果不存在返回 404 Not Found, 当然，这只表示你在查询的那一刻文档不存在，但并不表示几毫秒后依旧不存在。另一个进程在这期间可能创建新文档)
使用自定义的_id，我们必须告诉 Elasticsearch 应该在_index、_type、_id 三者都不同时才接受请求。
PUT /website/blog/123?op_type=create
PUT /website/blog/123/_create返回正常的元数据且响应状态码是 201 Created, 另一方面，如果包含相同的_index、_type 和_id 的文档已经存在，Elasticsearch 将返回 409 Conflict 响应状态码(报错是因为参数 create, 如果没有 create 参数，那么会更新文档只是返回的结果中 created 为 false，在内部，Elasticsearch 会标记旧文档为删除并添加了一个完整的新文档。旧版本文档不会立即消失，但你也不能去访问它。Elasticsearch 会在你继续索引更多数据时清理被删除的文档)
删除文档
DELETE /website/blog/123，如果文档被找到，Elasticsearch 将返回 200 OK 状态码和以下响应体。注意_version 数字已经增加了. 如果文档未找到，我们将得到一个 404 Not Found 状态码. 尽管文档不存在—— found 的值是 false——_version 依旧增加了。这是内部记录的一部分，它确保在多节点间不同操作可以有正确的顺序.
版本控制
悲观并发控制（Pessimistic concurrency control）这在关系型数据库中被广泛的使用，假设冲突的更改经常发生，为了解决冲突我们把访问区块化。典型的例子是在读一行数据前锁定这行，然后确保只有加锁的那个线程可以修改这行数据。乐观并发控制（Optimistic concurrency control）
被 Elasticsearch 使用，假设冲突不经常发生，也不区块化访问，然而，如果在读写过程中数据发生了变化，更新操作将失败。这时候由程序决定在失败后如何解决冲突。实际情况中，可以重新尝试更新，刷新数据（重新读取）或者直接反馈给用户。
我们利用_version 的这一优点确保数据不会因为修改冲突而丢失
eg:
Let s create a new blog post: 让我们创建一个新的博文
PUT /website/blog/1/_create
title : My first blog entry ,
text : Just trying this out...
}响应体告诉我们这是一个新建的文档，它的_version 是 1。现在假设我们要编辑这个文档：把数据加载到 web 表单中，修改，然后保存成新版本。
首先我们检索文档：
GET /website/blog/1现在，当我们通过重新索引文档保存修改时，我们这样指定了 version 参数：
PUT /website/blog/1?version=1 1
title : My first blog entry ,
text : Starting to get the hang of this...
}我们只希望文档的_version 是 1 时更新才生效
文档局部更新
POST /website/blog/1/_update
doc : { tags : [ testing ],
views : 0
}
}检索多个文档
mget 方式
更省时的批量操作
POST /_bulk
{ delete : { _index : website , _type : blog , _id : 123 }}
{ create : { _index : website , _type : blog , _id : 123 }}
{ title : My first blog post }
{ index : { _index : website , _type : blog }}
{ title : My second blog post }
{ update : { _index : website , _type : blog , _id : 123 , _retry_on_conflict : 3} }
{ doc : { title : My updated blog post} }多大才算太大？
整个批量请求需要被加载到接受我们请求节点的内存里，所以请求越大，给其它请求可用的内存就越小。有一个最佳的 bulk 请求大小。超过这个大小，性能不再提升而且可能降低。
最佳大小，当然并不是一个固定的数字。它完全取决于你的硬件、你文档的大小和复杂度以及索引和搜索的负载。幸运的是，这个最佳点 (sweetspot) 还是容易找到的：
试着批量索引标准的文档，随着大小的增长，当性能开始降低，说明你每个批次的大小太大了。开始的数量可以在 1000~5000 个文档之间，如果你的文档非常大，可以使用较小的批次。
通常着眼于你请求批次的物理大小是非常有用的。一千个 1kB 的文档和一千个 1MB 的文档大不相同。一个好的批次最好保持在 5 -15MB 大小间。
### 第四章 ###
路由
shard = hash(routing) % number_of_primary_shardsrouting 值是一个任意字符串，它默认是_id 但也可以自定义。这个 routing 字符串通过哈希函数生成一个数字，然后除以主切片的数量得到一个余数(remainder)，余数的范围永远是 0 到 number_of_primary_shards – 1，这个数字就是特定文档所在的分片（这也解释了为什么主分片的数量只能在创建索引时定义且不能修改：如果主分片的数量在未来改变了，所有先前的路由值就失效了，文档也就永远找不到了）
所有的文档 API（get、index、delete、bulk、update、mget）都接收一个 routing 参数，它用来自定义文档到分片的映射。自定义路由值可以确保所有相关文档——例如属于同一个人的文档——被保存在同一分片上
新建、索引和删除文档
请求节点
下面我们罗列在主分片和复制分片上成功新建、索引或删除一个文档必要的顺序步骤：
客户端给 Node 发送新建、索引或删除请求。
节点使用文档的_id 确定文档属于分片 0。它转发请求到 Node 3，分片 0 位于这个节点上。Node 3 在主分片上执行请求，如果成功，它转发请求到相应的位于 Node 1 和 Node 的复制节点上。当所有的复制节点报告成功，Node 报告成功到请求的节点，请求的节点再报告给客户端。
客户端接收到成功响应的时候，文档的修改已经被应用于主分片和所有的复制分片。你的修改生效了
复制默认的值是 sync
consistency 允许的值为 one（只有一个主分片），all（所有主分片和复制分片）或者默认的 quorum 或过半分片 int((primary + number_of_replicas) / 2 ) + 1。
当分片副本不足时会怎样？Elasticsearch 会等待更多的分片出现。默认等待一分钟,timeout 参数
下面我们罗列在主分片或复制分片上检索一个文档必要的顺序步骤：
客户端给 Node 1 发送 get 请求。
节点使用文档的_id 确定文档属于分片 0。分片 0 对应的复制分片在三个节点上都有。此时，它转发请求到 Node 2(根据路由法则计算出文档所在的分片地址)。
Node 2 返回 endangered 给 Node 1 然后返回给客户端。对于读请求，为了平衡负载，请求节点会为每个请求选择不同的分片——它会循环所有分片副本，可能的情况是，一个被索引的文档已经存在于主分片上却还没来得及同步到复制分片上。这时复制分片会报告文档未找到，主分片会成功返回文档。一旦索引请求成功返回给用户，文档则在主分片和复制分片都是可用的
下面我们罗列执行局部更新必要的顺序步骤：
客户端给 Node 1 发送更新请求。
它转发请求到主分片所在节点 Node 3。
Node 3 从主分片检索出文档，修改_source 字段的 JSON，然后在主分片上重建索引。如果有其他进程修改了文档，它以 retry_on_conflict 设置的次数重复步骤 3，都未成功则放弃。
如果 Node 3 成功更新文档，它同时转发文档的新版本到 Node 1 和 Node 2 上的复制节点以重建索引。当所有复制节点报告成功，Node 3 返回成功给请求节点，然后返回给客户端。update API 还接受《新建、索引和删除》章节提到的 routing、replication、consistency 和 timout 参数。多文档模式 mget 和 bulk API 与单独的文档类似。差别是请求节点知道每个文档所在的分片。它把多文档请求拆成每个分片的对文档请求，然后转发每个参与的节点。
一旦接收到每个节点的应答，然后整理这些响应组合为一个单独的响应，最后返回给客户端。
下面我们将罗列通过一个 mget 请求检索多个文档的顺序步骤：
客户端向 Node 1 发送 mget 请求。
Node 1 为每个分片构建一个多条数据检索请求，然后转发到这些请求所需的主分片或复制分片上。当所有回复被接收，Node 1 构建响应并返回给客户端。
routing 参数可以被 docs 中的每个文档设置。
下面我们将罗列使用一个 bulk 执行多个 create、index、delete 和 update 请求的顺序步骤：
客户端向 Node 1 发送 bulk 请求。
Node 1 为每个分片构建批量请求，然后转发到这些请求所需的主分片上。
主分片一个接一个的照顺序执行操作。当一个操作执行完，主分片转发新文档（或者删除部分）给对应的复制节点，然后执行下一个操作。复制节点为报告所有操作完成，节点报告给请求节点，请求节点整理响应并返回给客户端。
bulk API 还可以在最上层使用 replication 和 consistency 参数，routing 参数则在每个请求的元数据中使用。
### 第五章 ###
A search can be: 搜索 (search) 可以：
在类似于 gender 或者 age 这样的字段上使用结构化查询，join_date 这样的字段上使用排序，就像 SQL 的结构化查询一样。
全文检索，可以使用所有字段来匹配关键字，然后 an 照关联性 (relevance) 排序返回结果。
或者结合以上两条
概念解释映射 (Mapping) 数据在每个字段中的解释说明分析 (Analysis) 全文是如何处理的可以被搜索的领域特定语言查询(Query DSL)Elasticsearch 使用的灵活的、强大的查询语言
### 第六章 ###
映射 (mapping) 机制用于进行字段类型确认，将每个字段匹配为一种确定的数据类型 (string, number, booleans, date 等)。
分析(analysis) 机制用于进行全文文本 (Full Text) 的分词，以建立供搜索用的反向索引。
到此，相信大家对“ElassticSearch 文档操作的方法有哪些”有了更深的了解，不妨来实际操作一番吧！这里是丸趣 TV 网站，更多相关内容可以进入相关频道进行查询，关注我们，继续学习！
