ElassticSearch文檔操作的方法有哪些

本篇內(nèi)容主要講解“ElassticSearch文檔操作的方法有哪些”，感興趣的朋友不妨來看看。本文介紹的方法操作簡單快捷，實(shí)用性強(qiáng)。下面就讓小編來帶大家學(xué)習(xí)“ElassticSearch文檔操作的方法有哪些”吧!

創(chuàng)新互聯(lián)公司專注于企業(yè)全網(wǎng)營銷推廣、網(wǎng)站重做改版、天水網(wǎng)站定制設(shè)計(jì)、自適應(yīng)品牌網(wǎng)站建設(shè)、H5網(wǎng)站設(shè)計(jì)、購物商城網(wǎng)站建設(shè)、集團(tuán)公司官網(wǎng)建設(shè)、成都外貿(mào)網(wǎng)站建設(shè)、高端網(wǎng)站制作、響應(yīng)式網(wǎng)頁設(shè)計(jì)等建站業(yè)務(wù)，價(jià)格優(yōu)惠性價(jià)比高，為天水等各大城市提供網(wǎng)站開發(fā)制作服務(wù)。

###第一章
######與Elasticsearch交互

1. 節(jié)點(diǎn)客戶端(node client)
   節(jié)點(diǎn)客戶端以無數(shù)據(jù)節(jié)點(diǎn)(none data node)身份加入集群，換言之，它自己不存儲(chǔ)任何數(shù)據(jù)，但是它知道數(shù)據(jù)在集群中的具體位置，并且能夠直接轉(zhuǎn)發(fā)請(qǐng)求到對(duì)應(yīng)的節(jié)點(diǎn)上。

2. 傳輸客戶端(Transport client)
   這個(gè)更輕量的傳輸客戶端能夠發(fā)送請(qǐng)求到遠(yuǎn)程集群。它自己不加入集群，只是簡單轉(zhuǎn)發(fā)請(qǐng)求給集群中的節(jié)點(diǎn)。

3. 基于HTTP協(xié)議，以JSON為數(shù)據(jù)交互格式的RESTful API
   其他所有程序語言都可以使用RESTful API，通過9200端口的與Elasticsearch進(jìn)行通信

######比較
Relational DB -> Databases -> Tables -> Rows -> Columns
Elasticsearch -> Indices -> Types -> Documents -> Fields
###第二章###

####概念:###

1. 索引(index)——一個(gè)存儲(chǔ)關(guān)聯(lián)數(shù)據(jù)的地方。實(shí)際上，索引只是一個(gè)用來指向一個(gè)或多個(gè)分片(shards)的“邏輯命名空間(logical namespace)”

2. 一個(gè)分片(shard)是一個(gè)最小級(jí)別“工作單元(worker unit)”,它只是保存了索引中所有數(shù)據(jù)的一部分(分片就是一個(gè)Lucene實(shí)例，并且它本身就是一個(gè)完整的搜索引擎。我們的文檔存儲(chǔ)在分片中，并且在分片中被索引，但是我們的應(yīng)用程序不會(huì)直接與它們通信，取而代之的是，直接與索引通信)
   分片的最大容量完全取決于你的使用狀況：硬件存儲(chǔ)的大小、文檔的大小和復(fù)雜度、如何索引和查詢你的文檔，以及你期望的響應(yīng)時(shí)間(項(xiàng)目做壓測(cè)是需要確定，主分片的數(shù)量在創(chuàng)建索引時(shí)已經(jīng)確定，這個(gè)數(shù)量定義了能存儲(chǔ)到索引里數(shù)據(jù)的最大數(shù)量；然而，主分片或者復(fù)制分片都可以處理讀請(qǐng)求——搜索或文檔檢索，所以數(shù)據(jù)的冗余越多，我們能處理的搜索吞吐量就越大)
   如果被重啟的機(jī)器有舊分片的拷貝，它將會(huì)嘗試再利用它們，它只會(huì)從主分片上復(fù)制在故障期間有數(shù)據(jù)變更的那一部分

###第三章###
無論程序怎么寫，意圖是一樣的：組織數(shù)據(jù)為我們的目標(biāo)所服務(wù)。但數(shù)據(jù)并不只是由隨機(jī)比特和字節(jié)組成，我們?cè)跀?shù)據(jù)節(jié)點(diǎn)間建立關(guān)聯(lián)來表示現(xiàn)實(shí)世界中的實(shí)體或者“某些東西”。屬于同一個(gè)人的名字和Email地址會(huì)有更多的意義
####什么是文檔？
鍵值對(duì)的JSON對(duì)象，鍵(key)是字段(field)或?qū)傩?property)的名字，值(value)可以是字符串、數(shù)字、布爾類型、另一個(gè)對(duì)象、值數(shù)組或者其他特殊類型，比如表示日期的字符串或者表示地理位置的對(duì)象
在Elasticsearch中，文檔(document)這個(gè)術(shù)語有著特殊含義。它特指最頂層結(jié)構(gòu)或者根對(duì)象(root object)序列化成的JSON數(shù)據(jù)（以唯一ID標(biāo)識(shí)并存儲(chǔ)于Elasticsearch中）

• 一個(gè)文檔不只有數(shù)據(jù)。它還包含了元數(shù)據(jù)(metadata)：_index,_type,_id

• 檢索文檔的一部分(包含原數(shù)據(jù)):

GET /website/blog/123?_source=title,text

只想得到_source字段而不要其他的元數(shù)據(jù)，你可以這樣請(qǐng)求：GET /website/blog/123/_source

• 檢查文檔是否存在：

curl -i -XHEAD http://localhost:9200/website/blog/123

(返回200 OK狀態(tài)如果你的文檔存在,如果不存在返回404 Not Found,當(dāng)然，這只表示你在查詢的那一刻文檔不存在，但并不表示幾毫秒后依舊不存在。另一個(gè)進(jìn)程在這期間可能創(chuàng)建新文檔)

• 使用自定義的_id，我們必須告訴Elasticsearch應(yīng)該在_index、_type、_id三者都不同時(shí)才接受請(qǐng)求。

PUT /website/blog/123?op_type=create   
PUT /website/blog/123/_create

返回正常的元數(shù)據(jù)且響應(yīng)狀態(tài)碼是201 Created,另一方面，如果包含相同的_index、_type和_id的文檔已經(jīng)存在，Elasticsearch將返回409 Conflict響應(yīng)狀態(tài)碼(報(bào)錯(cuò)是因?yàn)閰?shù)create,如果沒有create參數(shù)，那么會(huì)更新文檔只是返回的結(jié)果中created為false，在內(nèi)部，Elasticsearch會(huì)標(biāo)記舊文檔為刪除并添加了一個(gè)完整的新文檔。舊版本文檔不會(huì)立即消失，但你也不能去訪問它。Elasticsearch會(huì)在你繼續(xù)索引更多數(shù)據(jù)時(shí)清理被刪除的文檔)

• 刪除文檔

DELETE /website/blog/123，

如果文檔被找到，Elasticsearch將返回200 OK狀態(tài)碼和以下響應(yīng)體。注意_version數(shù)字已經(jīng)增加了.如果文檔未找到，我們將得到一個(gè)404 Not Found狀態(tài)碼.盡管文檔不存在——"found"的值是false——_version依舊增加了。這是內(nèi)部記錄的一部分，它確保在多節(jié)點(diǎn)間不同操作可以有正確的順序.

• 版本控制
  悲觀并發(fā)控制（Pessimistic concurrency control） 這在關(guān)系型數(shù)據(jù)庫中被廣泛的使用，假設(shè)沖突的更改經(jīng)常發(fā)生，為了解決沖突我們把訪問區(qū)塊化。典型的例子是在讀一行數(shù)據(jù)前鎖定這行，然后確保只有加鎖的那個(gè)線程可以修改這行數(shù)據(jù)。 樂觀并發(fā)控制（Optimistic concurrency control）
  被Elasticsearch使用，假設(shè)沖突不經(jīng)常發(fā)生，也不區(qū)塊化訪問，然而，如果在讀寫過程中數(shù)據(jù)發(fā)生了變化，更新操作將失敗。這時(shí)候由程序決定在失敗后如何解決沖突。實(shí)際情況中，可以重新嘗試更新，刷新數(shù)據(jù)（重新讀取）或者直接反饋給用戶。
  我們利用_version的這一優(yōu)點(diǎn)確保數(shù)據(jù)不會(huì)因?yàn)樾薷臎_突而丟失
  eg:
  Let's create a new blog post: 讓我們創(chuàng)建一個(gè)新的博文

PUT /website/blog/1/_create
{
  "title": "My first blog entry",
  "text":  "Just trying this out..."
}

響應(yīng)體告訴我們這是一個(gè)新建的文檔，它的_version是1?，F(xiàn)在假設(shè)我們要編輯這個(gè)文檔：把數(shù)據(jù)加載到web表單中，修改，然后保存成新版本。
首先我們檢索文檔：

GET /website/blog/1

現(xiàn)在，當(dāng)我們通過重新索引文檔保存修改時(shí)，我們這樣指定了version參數(shù)：

PUT /website/blog/1?version=1 <1>
{
  "title": "My first blog entry",
  "text":  "Starting to get the hang of this..."
}

我們只希望文檔的_version是1時(shí)更新才生效

• 文檔局部更新

POST /website/blog/1/_update
{
   "doc" : {
      "tags" : [ "testing" ],
      "views": 0
   }
}

• 檢索多個(gè)文檔
  mget方式

• 更省時(shí)的批量操作

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"} }

多大才算太大？
整個(gè)批量請(qǐng)求需要被加載到接受我們請(qǐng)求節(jié)點(diǎn)的內(nèi)存里，所以請(qǐng)求越大，給其它請(qǐng)求可用的內(nèi)存就越小。有一個(gè)最佳的bulk請(qǐng)求大小。超過這個(gè)大小，性能不再提升而且可能降低。
最佳大小，當(dāng)然并不是一個(gè)固定的數(shù)字。它完全取決于你的硬件、你文檔的大小和復(fù)雜度以及索引和搜索的負(fù)載。幸運(yùn)的是，這個(gè)最佳點(diǎn)(sweetspot)還是容易找到的：
試著批量索引標(biāo)準(zhǔn)的文檔，隨著大小的增長，當(dāng)性能開始降低，說明你每個(gè)批次的大小太大了。開始的數(shù)量可以在1000~5000個(gè)文檔之間，如果你的文檔非常大，可以使用較小的批次。
通常著眼于你請(qǐng)求批次的物理大小是非常有用的。一千個(gè)1kB的文檔和一千個(gè)1MB的文檔大不相同。一個(gè)好的批次最好保持在5-15MB大小間。

###第四章###

• 路由

shard = hash(routing) % number_of_primary_shards

routing值是一個(gè)任意字符串，它默認(rèn)是_id但也可以自定義。這個(gè)routing字符串通過哈希函數(shù)生成一個(gè)數(shù)字，然后除以主切片的數(shù)量得到一個(gè)余數(shù)(remainder)，余數(shù)的范圍永遠(yuǎn)是0到number_of_primary_shards - 1，這個(gè)數(shù)字就是特定文檔所在的分片（這也解釋了為什么主分片的數(shù)量只能在創(chuàng)建索引時(shí)定義且不能修改：如果主分片的數(shù)量在未來改變了，所有先前的路由值就失效了，文檔也就永遠(yuǎn)找不到了）
所有的文檔API（get、index、delete、bulk、update、mget）都接收一個(gè)routing參數(shù)，它用來自定義文檔到分片的映射。自定義路由值可以確保所有相關(guān)文檔——例如屬于同一個(gè)人的文檔——被保存在同一分片上

• 新建、索引和刪除文檔
  請(qǐng)求節(jié)點(diǎn)

• 下面我們羅列在主分片和復(fù)制分片上成功新建、索引或刪除一個(gè)文檔必要的順序步驟：

1. 客戶端給Node發(fā)送新建、索引或刪除請(qǐng)求。

2. 節(jié)點(diǎn)使用文檔的_id確定文檔屬于分片0。它轉(zhuǎn)發(fā)請(qǐng)求到Node 3，分片0位于這個(gè)節(jié)點(diǎn)上。 Node 3在主分片上執(zhí)行請(qǐng)求，如果成功，它轉(zhuǎn)發(fā)請(qǐng)求到相應(yīng)的位于Node 1和Node的復(fù)制節(jié)點(diǎn)上。當(dāng)所有的復(fù)制節(jié)點(diǎn)報(bào)告成功，Node報(bào)告成功到請(qǐng)求的節(jié)點(diǎn)，請(qǐng)求的節(jié)點(diǎn)再報(bào)告給客戶端。

3. 客戶端接收到成功響應(yīng)的時(shí)候，文檔的修改已經(jīng)被應(yīng)用于主分片和所有的復(fù)制分片。你的修改生效了

• 復(fù)制默認(rèn)的值是sync

• consistency允許的值為one（只有一個(gè)主分片），all（所有主分片和復(fù)制分片）或者默認(rèn)的quorum或過半分片 int( (primary + number_of_replicas) / 2 ) + 1。

• 當(dāng)分片副本不足時(shí)會(huì)怎樣？Elasticsearch會(huì)等待更多的分片出現(xiàn)。默認(rèn)等待一分鐘,timeout參數(shù)

• 下面我們羅列在主分片或復(fù)制分片上檢索一個(gè)文檔必要的順序步驟：

1. 客戶端給Node 1發(fā)送get請(qǐng)求。

2. 節(jié)點(diǎn)使用文檔的_id確定文檔屬于分片0。分片0對(duì)應(yīng)的復(fù)制分片在三個(gè)節(jié)點(diǎn)上都有。此時(shí)，它轉(zhuǎn)發(fā)請(qǐng)求到Node 2(根據(jù)路由法則計(jì)算出文檔所在的分片地址)。

3. Node 2返回endangered給Node 1然后返回給客戶端。 對(duì)于讀請(qǐng)求，為了平衡負(fù)載，請(qǐng)求節(jié)點(diǎn)會(huì)為每個(gè)請(qǐng)求選擇不同的分片——它會(huì)循環(huán)所有分片副本，可能的情況是，一個(gè)被索引的文檔已經(jīng)存在于主分片上卻還沒來得及同步到復(fù)制分片上。這時(shí)復(fù)制分片會(huì)報(bào)告文檔未找到，主分片會(huì)成功返回文檔。一旦索引請(qǐng)求成功返回給用戶，文檔則在主分片和復(fù)制分片都是可用的

 

下面我們羅列執(zhí)行局部更新必要的順序步驟：

1. 客戶端給Node 1發(fā)送更新請(qǐng)求。

2. 它轉(zhuǎn)發(fā)請(qǐng)求到主分片所在節(jié)點(diǎn)Node 3。

3. Node 3從主分片檢索出文檔，修改_source字段的JSON，然后在主分片上重建索引。如果有其他進(jìn)程修改了文檔，它以retry_on_conflict設(shè)置的次數(shù)重復(fù)步驟3，都未成功則放棄。

4. 如果Node 3成功更新文檔，它同時(shí)轉(zhuǎn)發(fā)文檔的新版本到Node 1和Node 2上的復(fù)制節(jié)點(diǎn)以重建索引。當(dāng)所有復(fù)制節(jié)點(diǎn)報(bào)告成功，Node 3返回成功給請(qǐng)求節(jié)點(diǎn)，然后返回給客戶端。 update API還接受《新建、索引和刪除》章節(jié)提到的routing、replication、consistency和timout參數(shù)。 多文檔模式 mget和bulk API與單獨(dú)的文檔類似。差別是請(qǐng)求節(jié)點(diǎn)知道每個(gè)文檔所在的分片。它把多文檔請(qǐng)求拆成每個(gè)分片的對(duì)文檔請(qǐng)求，然后轉(zhuǎn)發(fā)每個(gè)參與的節(jié)點(diǎn)。
   一旦接收到每個(gè)節(jié)點(diǎn)的應(yīng)答，然后整理這些響應(yīng)組合為一個(gè)單獨(dú)的響應(yīng)，最后返回給客戶端。

 

下面我們將羅列通過一個(gè)mget請(qǐng)求檢索多個(gè)文檔的順序步驟：

1. 客戶端向Node 1發(fā)送mget請(qǐng)求。

2. Node 1為每個(gè)分片構(gòu)建一個(gè)多條數(shù)據(jù)檢索請(qǐng)求，然后轉(zhuǎn)發(fā)到這些請(qǐng)求所需的主分片或復(fù)制分片上。當(dāng)所有回復(fù)被接收，Node 1構(gòu)建響應(yīng)并返回給客戶端。
   routing 參數(shù)可以被docs中的每個(gè)文檔設(shè)置。

 

下面我們將羅列使用一個(gè)bulk執(zhí)行多個(gè)create、index、delete和update請(qǐng)求的順序步驟：

1. 客戶端向Node 1發(fā)送bulk請(qǐng)求。

2. Node 1為每個(gè)分片構(gòu)建批量請(qǐng)求，然后轉(zhuǎn)發(fā)到這些請(qǐng)求所需的主分片上。

3. 主分片一個(gè)接一個(gè)的照順序執(zhí)行操作。當(dāng)一個(gè)操作執(zhí)行完，主分片轉(zhuǎn)發(fā)新文檔（或者刪除部分）給對(duì)應(yīng)的復(fù)制節(jié)點(diǎn)，然后執(zhí)行下一個(gè)操作。復(fù)制節(jié)點(diǎn)為報(bào)告所有操作完成，節(jié)點(diǎn)報(bào)告給請(qǐng)求節(jié)點(diǎn)，請(qǐng)求節(jié)點(diǎn)整理響應(yīng)并返回給客戶端。
   bulk API還可以在最上層使用replication和consistency參數(shù)，routing參數(shù)則在每個(gè)請(qǐng)求的元數(shù)據(jù)中使用。

###第五章###
A search can be: 搜索(search)可以：

• 在類似于gender或者age這樣的字段上使用結(jié)構(gòu)化查詢，join_date這樣的字段上使用排序，就像SQL的結(jié)構(gòu)化查詢一樣。

• 全文檢索，可以使用所有字段來匹配關(guān)鍵字，然后an照關(guān)聯(lián)性(relevance)排序返回結(jié)果。

• 或者結(jié)合以上兩條

概念	解釋
映射(Mapping)	數(shù)據(jù)在每個(gè)字段中的解釋說明
分析(Analysis)	全文是如何處理的可以被搜索的
領(lǐng)域特定語言查詢(Query DSL)	Elasticsearch使用的靈活的、強(qiáng)大的查詢語言

###第六章###
映射(mapping)機(jī)制用于進(jìn)行字段類型確認(rèn)，將每個(gè)字段匹配為一種確定的數(shù)據(jù)類型(string, number, booleans, date等)。
分析(analysis)機(jī)制用于進(jìn)行全文文本(Full Text)的分詞，以建立供搜索用的反向索引。

到此，相信大家對(duì)“ElassticSearch文檔操作的方法有哪些”有了更深的了解，不妨來實(shí)際操作一番吧！這里是創(chuàng)新互聯(lián)網(wǎng)站，更多相關(guān)內(nèi)容可以進(jìn)入相關(guān)頻道進(jìn)行查詢，關(guān)注我們，繼續(xù)學(xué)習(xí)！

分享名稱：ElassticSearch文檔操作的方法有哪些
文章轉(zhuǎn)載：http://muchs.cn/article30/gesspo.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供全網(wǎng)營銷推廣、做網(wǎng)站、域名注冊(cè)、企業(yè)建站、響應(yīng)式網(wǎng)站、外貿(mào)網(wǎng)站建設(shè)

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請(qǐng)盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng)，如需處理請(qǐng)聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來源： 創(chuàng)新互聯(lián)