文章目錄

• • 1. Index API
  • 2. automatic index creation ( 自動創建索引 )
  • 3. Operation type ( 操作類型 )
  • 4. automatic ID generation ( 自動 ID 生成 )
  • 5. 樂觀鎖使用
  • 6. Routing ( 路由信息 )
  • 7. Distributed ( 分布式 )
  • 8. wait for active shards ( 等待活動分片 )
  • 9. Refresh ( 刷新 )
  • 10. Noop Updates
  • 11. Timeout ( 超時 )
  • 11. Versioning ( 版本控制 )
  • • 1. Version types ( 版本類型 )

1. Index API

索引 API 在特定索引中 add ( 添加 ) 或 update ( 更新 ) a typed JSON document ( 類型化的 JSON 文檔 )，使其可搜索。以下示例將 JSON 文檔插入到 “twitter” 索引中，ID 為1 ：

curl -XPUT 'localhost:9200/tweet/_doc/1?pretty' -H 'Content-Type: application/json' -d' {"user" : "kimchy","post_date" : "2009-11-15T14:12:12","message" : "trying out Elasticsearch" } '

上邊的索引操作結果為：

{"_shards" : {"total" : 2,"failed" : 0,"successful" : 2},"_index" : "twitter","_type" : "_doc","_id" : "1","_version" : 1,"created" : true,"result" : created }

_shards header 提供有關索引操作的復制過程的信息。

total - 指示應對多少 shard copies ( 分片副本 )（ primary ( 主 )分片和 replica ( 副本 ) 分片）執行索引操作。
successful - 表示索引操作成功的分片副本的數量。
failed - 在索引操作在副本碎片上失敗的情況下包含與復制相關的錯誤的數組。
在 successful 至少為 1 的情況下索引操作成功。

注意事項

當索引操作 successful 返回時，并不一定所有的replica shard都啟動了（默認情況下，只需要primary shard是必須的，但可以更改此行為）。在這種情況下， total 將等于基于 number_of_replicas 設置的總分片(也就是理論上的shard數量)，并且 successful 將等于已啟動的分片數（主副本和已經啟動的副本）。如果沒有失敗， failed 將是 0 。

2. automatic index creation ( 自動創建索引 )

如果索引操作尚未創建，則索引操作自動創建索引（check out 用于手動創建索引的 create index API），并且如果尚未創建，則自動為特定類型創建 dynamic type mapping( 動態類型映射 )（check out put mapping API 用于手動創建類型映射）。

mapping ( 映射 ) 本身非常靈活，并且是 schema-free ( 無模式的 )。New fields ( 新字段 ) 和 objects ( 對象 )將自動添加到指定類型的映射定義。查看映射部分以獲取有關映射定義的更多信息。

可以通過在所有節點的配置文件中將 action.auto_create_index 設置為 false 來禁用 自動創建索引。可以通過將index mapping.dynamic 設置為 false 來禁用當前索引自動映射創建。

自動索引創建可以包括 a pattern based white/black list ( 基于模式的 白/黑 列表 )，例如，設置

action.auto_create_index to +aaa,-bbb,+ccc,- （ + 表示 允許，- 表示不允許）。

PUT _cluster/settings {"persistent": {"action.auto_create_index": "twitter,index10,-index1*,+ind*" } }PUT _cluster/settings {"persistent": {"action.auto_create_index": "false" } }PUT _cluster/settings {"persistent": {"action.auto_create_index": "true" } }

3. Operation type ( 操作類型 )

除了允許 “put-if-absent” 行為,index操作還接受可用于強制創建操作的 op_type，使用 create 時，如果索引中已存在該標識的文檔，索引操作將失敗。

下面是使用 op_type 參數的示例：

curl -XPUT 'localhost:9200/twitter/_doc/1?op_type=create&pretty' -H 'Content-Type: application/json' -d' {"user" : "kimchy","post_date" : "2009-11-15T14:12:12","message" : "trying out Elasticsearch" } '

指定 create 的另一個選項是使用以下 uri ：

curl -XPUT 'localhost:9200/twitter/_doc/1/_create?pretty' -H 'Content-Type: application/json' -d' {"user" : "kimchy","post_date" : "2009-11-15T14:12:12","message" : "trying out Elasticsearch" } '

4. automatic ID generation ( 自動 ID 生成 )

可以在不指定 ID 的情況下執行索引操作。在這種情況下，將自動生成 id 。此外，op_type 將自動設置為 create 。這里是一個例子（注意 POST 使用，而不是 PUT）：

curl -XPOST 'localhost:9200/twitter/_doc/?pretty' -H 'Content-Type: application/json' -d' {"user" : "kimchy","post_date" : "2009-11-15T14:12:12","message" : "trying out Elasticsearch" } '

上述索引操作的結果是：

{"_shards" : {"total" : 2,"failed" : 0,"successful" : 2},"_index" : "twitter","_type" : "_doc","_id" : "6a8ca01c-7896-48e9-81cc-9f70661fcb32","_version" : 1,"created" : true,"result": "created" }

5. 樂觀鎖使用

索引操作可以是有條件來控制的，可以控制僅在文檔的最后一次因為修改分配的_seq_no和_primary_term 參數和請求時傳進來的if_seq_no和if_primary_term參數相等的情況下才能執行操作。如果檢測到不匹配，則該操作將導致VersionConflictException和狀態碼409。有關更多詳細信息，請參見樂觀并發控制。

PUT products/_doc/1567?if_seq_no=362&if_primary_term=2 {"product" : "r2d2","details" : "A resourceful astromech droid","tags": ["droid"] }

6. Routing ( 路由信息 )

默認情況下，請求分發到那個分片(routing 路由 ) ——通過使用文檔的 id 值的哈希值來控制。對于更明確的控制，饋送到由路由使用的散列函數的值可以使用路由參數基于每個操作直接指定。例如：

curl -XPOST 'localhost:9200/twitter/_doc?routing=kimchy&pretty' -H 'Content-Type: application/json' -d' {"user" : "kimchy","post_date" : "2009-11-15T14:12:12","message" : "trying out Elasticsearch" } '

在上面的示例中，“tweet” 文檔根據提供的 routing parameter ( 路由參數 ) kimchy發送到 shard ( 分片 ) .

如果顯示的設置mapping的話，也可以指定使用doc的某個一個字段來作為routing,如果過設置了_routing mapping 請求的時候沒有rounting value或者無法從文檔中提取routing value，則請求會報錯

7. Distributed ( 分布式 )

索引操作基于其路由定向到 primary shard ( 主分片 ) （參見上面的路由部分），并在包含此分片的實際節點上執行。在主分片完成操作后，如果需要，將更新分發到適用的副本。

8. wait for active shards ( 等待活動分片 )

為了提高寫入系統的 resiliency ( 彈性 )，索引操作可以配置為在繼續操作之前等待一定數量的活動分片副本。如果所需的活動分片副本數不可用，則寫操作必須等待并重試，直到必需的分片副本已啟動或發生超時為止。默認情況下，寫操作只等待主分片處于活動狀態，然后再繼續（wait_for_active_shards=1）。可以通過設置 index.write.wait_for_active_shards 來動態地在索引設置中覆蓋此默認值。要更改每個操作的此行為，可以使用 wait_for_active_shards 請求參數。

有效值是所有或任何正整數，直到索引中每個分片的配置副本的總數（即 number_of_replicas+1）。指定負值或者大于分片副本數的數字將拋出錯誤。

例如，假設我們有一個三個節點A，B和C的集群，我們創建一個索引，索引副本數設置為 3 （導致 4 個 shard 副本，比節點多一個副本）。如果我們嘗試索引操作，默認情況下，操作將僅確保每個分片的主副本在繼續之前可用。這意味著，即使 B 和 C 下降，并且 A 托管主分片副本，索引操作仍然將繼續只有一個數據副本。如果對請求設置 wait_for_active_shards 設置為 3 （并且所有3個節點都已啟動），則索引操作將在繼續之前需要 3 個活動分片副本，這是應該滿足的要求，因為在集群有3個活動節點，每個節點有一個碎片的副本。但是，如果我們將 wait_for_active_shards 設置為 all （或者 4， 這是相同的），索引操作將不會繼續，因為索引中的每個碎片的所有的 4 個副本沒有處于活動狀態。該操作將超時，除非在集群中啟動新節點以托管分片的第四個副本。

重要的是要注意，這個設置極大地減少了寫操作不寫入所需數量的分片副本的機會，但是它不能完全消除可能性，因為這種檢查在寫操作開始之前發生。一旦寫操作正在進行，復制仍然可能在任意數量的 shard 副本上失敗，但在主數據庫上仍然成功。寫操作響應的 _shard 部分顯示復制成功/失敗的分片副本的數量。

{"_shards" : {"total" : 2,"failed" : 0,"successful" : 2} }

9. Refresh ( 刷新 )

控制此請求所做的更改對搜索可見。請參閱 刷新 。

10. Noop Updates

當使用索引 API 更新文檔時，即使文檔沒有更改，也始終創建新版本的文檔。如果不想這樣，請在使用_update API的時候將 detect_noop 設置為 true 。此選項在index API 上不可用，因為index api doesn’t fetch the old source ( 不提取舊源 )，并且無法將其與 new source ( 新源 ) 進行比較。

沒有一個強制和快速的規則來判定 noop 更新是不是應該使用。它是許多因素的組合，例如發送noops 的更新的頻率，以及每秒有多少次請求。

11. Timeout ( 超時 )

執行索引操作時分配的 primary shard ( 主分片 ) 可能不可用。這種情況的一些原因可能是主分片當前正在從 gateway ( 網關 ) 恢復或正在進行重定位。默認情況下，索引操作將在主分片上等待最多 1 分鐘，然后失敗并響應錯誤。 timeout 參數可以用于顯式指定等待時間。以下是將其設置為 5 分鐘的示例：

curl -XPUT 'localhost:9200/twitter/_doc/1?timeout=5m&pretty' -H 'Content-Type: application/json' -d' {"user" : "kimchy","post_date" : "2009-11-15T14:12:12","message" : "trying out Elasticsearch" } '

11. Versioning ( 版本控制 )

目前version是一個update的標識，可以是外部的或者是內部的，但是已經不建議用來作為并發控制了，而是建議使用if_seq_no和if_primary_term參數來進行并發控制
每個索引的文檔都有一個版本號。默認情況下，使用內部版本控制，該版本從1開始，并隨著每次更新（包括刪除）而遞增。可以選擇將版本號設置為外部值（例如，如果維護在數據庫中）。要啟用此功能，應將version_type設置為external。提供的值必須是大于或等于0且小于9.2e + 18左右的數字長值。

使用外部版本類型時，系統檢查以查看傳遞給索引請求的版本號是否大于當前存儲文檔的版本。如果為true，將為文檔建立索引并使用新的版本號。如果提供的值小于或等于存儲的文檔的版本號，則將發生版本沖突，并且索引操作將失敗

PUT twitter/_doc/1?version=2&version_type=external {"message" : "elasticsearch now has versioning support, double cool!" }

注意：

version是完全實時的，并且不受搜索操作的 near real time( 近實時 ) 方面的影響。如果沒有提供版本，則在沒有任何版本檢查的情況下執行操作。

對于上面的操作，由于提供的版本2高于當前文檔版本1，因此以上操作將成功。如果文檔已更新且其版本設置為2或更高，則索引命令將失敗并導致沖突（409 HTTP狀態碼）。

使用external version一個很好的作用是，只要使用源數據庫中的版本號(目標是要將源數據中的version導入到es當中)，就不需要維護由于對源數據庫進行更改而執行的異步索引操作的嚴格順序。如果使用外部版本控制，即使使用數據庫中的數據更新Elasticsearch索引的簡單情況也得以簡化，因為如果索引操作由于任何原因而亂序出現，則僅使用最新版本。

1. Version types ( 版本類型 )

在上邊解釋的 internal ( 內部 ) 和 external ( 外部 ) 版本類型旁邊，Elasticsearch 還支持特定用例的其他類型。這里是不同版本類型及其語義的概述。

** 1. internal**

僅在給定版本與存儲的文檔的版本相同時索引文檔。

** 2. external 或 external_gt **

如果給定版本嚴格高于存儲的文檔的版本或如果沒有現有文檔，則僅索引文檔。給定版本將用作新版本，并與新文檔一起存儲。提供的版本必須是 non-negative long number ( 非負長數字 ) 。

** 3. external_gte **

如果給定版本 等于 或者 高于 存儲的文檔的版本，則僅索引文檔。如果沒有現有文檔，操作也將成功。給定版本將用作新版本，并與新文檔一起存儲。提供的版本必須是 non-negative long number ( 非負長數字 )。

注意：

external_gte 版本類型適用于特殊用例，應謹慎使用。如果使用不正確，可能會導致數據丟失。還有一個選項，force ，它也被棄用，因為它可能導致主分片和副本分片。

總結

以上是生活随笔為你收集整理的03.elasticsearch_index操作的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。