Elasticsearch 索引文档

内容主要通过翻译官方文档而来,版本7.10

  1. 索引文档操作(通过curl实现)

curl -X PUT "localhost:9200/twitter/_doc/1" -H 'Content-Type: application/json' -d'

{

    "user" : "kimchy",

    "post_date" : "2009-11-15T14:12:12",

    "message" : "trying out Elasticsearch"

}

'


-X 选项: 指定curl的请求操作,默认是GET,也可以是PUT POST DELETE

-H 选项: 传入请求头

-d 选项: data,数据内容选项


不存在索引时,会自动创建。当然可以进行设置(通过action.auto_create_index)。

PUT _cluster/settings

{

    "persistent": {

        "action.auto_create_index": "twitter,index10,-index1*,+ind*" 

    }

}

注: 名称为twitter,index10的索引会创建,不符合index1*格式,但符合ind*格式也会被创建。


PUT _cluster/settings

{

    "persistent": {

        "action.auto_create_index": "false" 

    }

}

注: 默认全部不自动创建。会提示错误。如例子: {"error":{"root_cause":[{"type":"index_not_found_exception","reason":"no such index [mytwitter]"


PUT _cluster/settings

{

    "persistent": {

        "action.auto_create_index": "true" 

    }

}

注: 默认全部自动创建


默认的MAPPING规则,一个索引下只允许有一个type.

例如试图创建第二个名为mydoc的type:

curl -X PUT "localhost:9200/twitter/mydoc/1" -H 'Content-Type: application/json' -d'

{

    "user" : "kimchy",

    "post_date" : "2009-11-15T14:12:12",

    "message" : "trying out Elasticsearch"

}

'

会产生报错:{"error":{"root_cause":[{"type":"illegal_argument_exception","reason":"Rejecting mapping update to [twitter] as the final mapping would have more 


than 1 type: [_doc, mydoc]"}],"type":"illegal_argument_exception","reason":"Rejecting mapping update to [twitter] as the final mapping would have more than 1 


type


2 文档索引操作也接受op_type选项(即不允许更改文档):

curl -X PUT "localhost:9200/twitter/_doc/1?op_type=create" -H 'Content-Type: application/json' -d'

{

    "user" : "kimchy",

    "post_date" : "2009-11-15T14:12:12",

    "message" : "trying out Elasticsearch"

}

'

如果索引文档twitter/_doc/1已经存在,创建就会失败。


与上面等价的写法:

curl -X PUT "localhost:9200/twitter/_create/1" -H 'Content-Type: application/json' -d'

{

    "user" : "kimchy",

    "post_date" : "2009-11-15T14:12:12",

    "message" : "trying out Elasticsearch"

}

'


文档ID的自动生成:

如果没有指定文档ID,系统会自动生成一个唯一ID(索引该文档理论肯定是新创建的,不会更新其他文档):

例:

curl -X POST "localhost:9200/twitter/_doc/" -H 'Content-Type: application/json' -d'

{

    "user" : "mjj",

    "post_date" : "2009-11-15T14:12:12",

    "message" : "test Elasticsearch"

}

'

返回结果(部分): {"_index":"twitter","_type":"_doc","_id":"olLK42oBqV8-hMggVV3X"


3 乐观的并发控制:

Optimistic concurrency controledit

Index operations can be made conditional and only be performed if the last modification to the document was assigned the sequence number and primary term 


specified by the if_seq_no and if_primary_term parameters. If a mismatch is detected, the operation will result in a VersionConflictException and a status 


code of 409. See Optimistic concurrency control for more details.

索引文档结束后,返回结果中会包含一个序号:_seq_no。索引文档前会获取下一个序号,作为自己的序号,结束后会再获取序号,进行比较。如果序号不一致,说明有其他程序索


引了文档。那么该次操作就返回409号错误。


4. Routing(文档存放于那个物理shard)

By default, shard placement ? or routing ? is controlled by using a hash of the document’s id value. For more explicit control, the value fed into the hash 


function used by the router can be directly specified on a per-operation basis using the routing parameter. For example:


POST twitter/_doc?routing=kimchy

{

    "user" : "kimchy",

    "post_date" : "2009-11-15T14:12:12",

    "message" : "trying out Elasticsearch"

}


In the example above, the "_doc" document is routed to a shard based on the routing parameter provided: "kimchy".


When setting up explicit mapping, the _routing field can be optionally used to direct the index operation to extract the routing value from the document 


itself. This does come at the (very minimal) cost of an additional document parsing pass. If the _routing mapping is defined and set to be required, the 


index operation will fail if no routing value is provided or extracted.

默认情况下,系统通过对文档id进行hash运算,确定存放于具体的shard。但我们也可以通过指定routing参数,使hash函数对所提过的参数值进行运算,确定shard。

而且,还可以在mapping中,通过设置_routing字段来指示用文档中的哪个值来进行hash运算。但是如果索引的文档中没有包含mapping设置中的字段,将会产生报错。


5 Wait For Active Shards

默认设置下,primary shard索引完文档就完成了操作。

但可以通过index.write.wait_for_active_shards调整,确保有多个shard已保存了变更,默认该值为1(primay shard也算1个shard)。

如果设置为2,表示primary shard完成索引后,还要复制一份变更到另一个replica shard才行,replica shard完成前就需要等待。

如果index.write.wait_for_active_shards设置成all,就是所有num of shards+1. 索引操作需要有新的节点加入才能完成。

number_of_replicas数表示所需的replican shards. 但active shards包含primary shard.

例子:

For example, suppose we have a cluster of three nodes, A, B, and C and we create an index index with the number of replicas set to 3 (resulting in 4 shard 


copies, one more copy than there are nodes). If we attempt an indexing operation, by default the operation will only ensure the primary copy of each shard is 


available before proceeding. This means that even if B and C went down, and A hosted the primary shard copies, the indexing operation would still proceed 


with only one copy of the data. If wait_for_active_shards is set on the request to 3 (and all 3 nodes are up), then the indexing operation will require 3 


active shard copies before proceeding, a requirement which should be met because there are 3 active nodes in the cluster, each one holding a copy of the 


shard. However, if we set wait_for_active_shards to all (or to 4, which is the same), the indexing operation will not proceed as we do not have all 4 copies 


of each shard active in the index. The operation will timeout unless a new node is brought up in the cluster to host the fourth copy of the shard.


猜你喜欢

转载自blog.51cto.com/291268154/2399212