Elasticsearch 創建索引

ElasticSearch Twitter 併發控制技術 IT星源 2017-06-08

Elasticsearch 創建索引

自動創建索引

如果 Elasticsearch 之前尚未創建索引操作，則會自動創建索引，還會自動為特定類型創建動態類型映射。映射本身非常靈活，是無模式的。新的字段和對象將自動添加到指定類型的映射中。可以通過將配置文件中 action.auto_create_index設置為false來禁用自動創建索引。通過將index.mapper.dynamic設置為false可以禁用自動映射創建。

映射是用來定義如何存儲、編制、索引文檔和字段的過程。例如，使用映射來定義：

哪些字符串字段應被視為全文字段。
哪些字段包含數字，日期或地理位置。
文檔中所有字段的值是否應該編入catch-all 字段（將所有其他字段的值連接成一個大字符串，使用空格作為分隔符，然後對其進行分析和索引，但不存儲）。
日期值的格式。
自定義規則來控制動態添加字段的映射。

可以在不指定id的情況下執行索引操作。在這種情況下，將自動生成ID。

例如命令

POST twitter/tweet/

{
"user" : "kimchy",
"post_date" : "2016-11-15T14:12:12",
"message" : "trying out Elasticsearch"
}

版本

每個索引文檔都有一個版本號。關聯的版本號會作為對索引API請求的響應的一部分返回。當指定版本參數時，索引API可以允許樂觀鎖併發控制。用於版本控制的一個很好的例子，是執行事務性的讀取並更新操作。例如：

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

注意：版本控制是完全實時的，不受實時搜索操作的影響。如果沒有提供版本，則執行該操作時不進行任何版本檢查。

默認情況下，使用內部版本控制，從1開始，每次更新、刪除都會增加。可選功能：可以使用外部值補充版本號（例如，在數據庫中保留版本號）。要啟用此功能，應將version_type設置為external。提供的值必須是長整數（long），大於或等於0，小於9.2e + 18。

當使用外部版本類型時，系統不再檢查匹配的版本號，而是將檢查請求的版本號是否大於當前存儲的文檔的版本。如果大於，則文檔將被索引並使用新的版本號。如果提供的值小於或等於存儲的文檔的版本號，則將發生版本衝突，索引操作將失敗。

一個好的效果是，只要使用源數據庫的版本號，就不需要執行更改等異步索引操作進行嚴格排序。即使用外部版本控制，可以簡化數據的更新索引情況。因為如果索引操作因為某些原因而無序，只要使用最新版本即可。

常用版本號類型

內部

僅當給定版本與存儲文檔的版本相同，才對文檔編制索引。

外部

僅當給定版本嚴格高於存儲文檔的版本，或者現在沒有文檔，則對文檔建檢索。給定版本號將被用作新版本號，並將與新文檔一起存儲。提供的版本必須是非負長整數。

路由

默認情況下，分片路由是通過使用文檔 ID 值的哈希來控制的。為了更明確的控制，可以使用routing參數，在每個操作上直接指定路由器使用的散列函數的值。例如：

POST twitter/tweet?routing=kimchy
{
"user" : "kimchy",
"post_date" : "2009-11-15T14:12:12",
"message" : "trying out Elasticsearch"
}

在上面的示例中，“tweet”文檔根據提供的路由參數路由到分片：“kimchy”。

索引操作通過其路由指向主分片，在包含此分片的實際節點上執行操作。在主分片完成操作之後，如果需要，將更新分發到相關的副本。

為了提高系統的寫入可用性，索引操作可以配置為等待一定數量的副本拷貝成功，再繼續操作。如果所需數量的副本不可用，則寫入操作必須等待並重試，直到必需的分片副本已成功或發生超時為止。默認情況下，寫入操作只等待主分片處於完成狀態（即wait_for_active_shards = 1）。通過設置index.write.wait_for_active_shards可以動態地在索引設置中覆蓋此默認值。要更改每個操作的這種行為，可以使用請求參數 wait_for_active_shards。參數的有效值包括：全部或任何正整數，從1 到索引中的每個分片的配置副本總數（即number_of_replicas + 1）。指定一個負值或大於分片數量的數字將會引發錯誤。

舉個例子，假設我們有三個節點A，B和C的集群。我們創建一個索引索引，副本數設置為3（實際是4個副本，比節點多一個副本）。如果我們嘗試索引操作，則默認情況下，操作將僅在確保每個分片的主副本可用。這意味著即使B和C 死機，A託管了主分片副本，索引操作仍完成。如果在請求上設置了wait_for_active_shards到3（並且所有3個節點都已經啟動），則索引操作在進行之前，需要3個活動分片副本，這是需要滿足的要求，因為集群中有3個活動節點，每個持有副本。但是，如果我們將wait_for_active_shards設置為所有（all 或4，這是相同的），索引操作將不會繼續進行，因為我們沒有處於活動狀態的 4個副本。除非在集群中引入新節點以託管分片的第4個副本，否則操作將超時。

要注意的是，這種設置大大降低了寫入操作沒有寫入必需數量副本的機會，但是並不能完全消除這種可能性，因為這種檢查是在寫操作開始之前發生的。一旦寫入操作正在進行中，仍然有可能在主分片成功，在任何數量的分片副本上覆制失敗。