本篇内容主要讲解“ElassticSearch文档操作的方法有哪些”，感兴趣的朋友不妨来看看。本文介绍的方法操作简单快捷，实用性强。下面就让小编来带大家学习“ElassticSearch文档操作的方法有哪些”吧!
创新互联公司专注于企业全网营销推广、网站重做改版、天水网站定制设计、自适应品牌网站建设、H5网站设计、购物商城网站建设、集团公司官网建设、成都外贸网站建设、高端网站制作、响应式网页设计等建站业务，价格优惠性价比高，为天水等各大城市提供网站开发制作服务。
###第一章
######与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_shards
routing值是一个任意字符串，它默认是_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文档操作的方法有哪些”有了更深的了解，不妨来实际操作一番吧！这里是创新互联网站，更多相关内容可以进入相关频道进行查询，关注我们，继续学习！