PUT twitter/tweet/1
{
"user" : "kimchy",
"post_date" : "2009-11-15T14:12:12",
"message" : "trying out Elasticsearch"
}
The result is
{
"_shards" : {
"total" : 2,
"failed" : 0,
"successful" : 2
},
"_index" : "twitter",
"_type" : "tweet",
"_id" : "1",
"_version" : 1,
"created" : true,
"result" : created
}
The _shards node represents the replica information
total: the total number of replicas (including data nodes)
successful represents the total number of successful
failures. Failed is an array including failed nodes.
If index definition is not created, an index definition will be created by default. If you want to close it, set action.auto_create_index to false in the setting. Similarly, if you want to turn off the automatic creation of column relationship settings, you can set index.mapper.dynamic to false.
The above is an example of using id, if you want the id to be automatically generated.
POST twitter/tweet/
{
"user" : "kimchy",
"post_date" : "2009-11-15T14:12:12",
"message" : "trying out Elasticsearch"
}
return
{
"_shards" : {
"total" : 2,
"failed" : 0,
"successful" : 2
},
"_index" : "twitter",
"_type" : "tweet",
"_id" : "6a8ca01c-7896-48e9-81cc-9f70661fcb32",
"_version" : 1,
"created" : true,
"result": "created"
}
It was found that he automatically generated an id.
The default data will be hashed to a data node according to the id. (If you want to control this hash value yourself, you can add the parameter ?routing=kimchy)
You can set a parent node for a document. After that, the child node data will be automatically routed to a data node with the parent node.
When data is written, you can define at least several data nodes to write before returning (unless it times out). The default is the master node, but it can be set dynamically
index.write.wait_for_active_shardsto change.
Or add the parameter wait_for_active_shards to the request to change (the correct value is all or a natural number).
If you want to define the expiration time, you can add a parameter to the access request: timeout=5m (5 minutes)
to get the interface
GET twitter/tweet/0return
{
"_index" : "twitter",
"_type" : "tweet",
"_id" : "0",
"_version" : 1,
"found": true,
"_source" : {
"user" : "kimchy",
"date" : "2009-11-15T14:12:12",
"likes": 0,
"message" : "trying out Elasticsearch"
}
}
The above is to get the data whose type is twitter and the id is 0 under the twitter index
. It can also be used to judge whether it exists or not.
HEAD twitter/tweet/0
If you want the returned data to not include _source, add _source=false to the request parameter
if you want to filter the data in _source
GET twitter/tweet/0?_source_include=*.id&_source_exclude=entities. if only included
GET twitter/tweet/0?_source=*.id,retweeted
use
/{index}/{type}/{id}/_source
Document information such as:
GET twitter/tweet/1/_source
It is possible to control which data node executes the request. The default is random access. Can be set to _primary, _local and custom.
delete interface
delete data with id 1
DELETE 'http://localhost:9200/twitter/tweet/1'
Of course, the routing parameter can also be added to indicate which data node the request falls on.
Remove by search
POST twitter/twitter/_delete_by_query
{
"query": {
"match": {
"message": "some message"
}
}
}
This conditional statement is written in the same way as a query statement.
If you want to search for data in the entire index and delete the data
POST twitter/_delete_by_query
If you want to collapse multiple indexes
POST twitter,blog/tweet,post/_delete_by_query
By default, the above delete will only delete 1000 records. You can also customize the number of records to delete
POST twitter/_delete_by_query?scroll_size=5000
The same parameter not only supports pretty, but also supports refresh, wait_for_completion, wait_for_active_shards, and timeout parameter
refresh indicates that the content will be refreshed after the request is processed.
wait_for_completion=false will perform some checks, and then return a task (which can be controlled in the task interface).
wait_for_active_shards indicates how many surviving replicas must be executed before execution
timeout indicates the time each request waits for data nodes to be available
Return information
{
"took" : 639,
"deleted": 0,
"batches": 1,
"version_conflicts": 2,
"retries": 0,
"throttled_millis": 0,
"failures" : [ ]
}
took represents the time spent
deleted the number of successfully deleted articles
batches The total number returned by query deletion
Task interface understanding (https://www.elastic.co/guide/en/elasticsearch/reference/current/docs-delete-by-query.html ) The
update interface
first obtains the document, and then writes the data. Use the version to ensure that the data has not been modified in the middle. The
method is the same as the creation.
If you want to partially update the document, you can use the following methods
POST test/type1/1/_update
{
"doc" : {
"name" : "new_name"
}
}
The excuse of updating according to search
needs to be used carefully (https://www.elastic.co/guide/en/elasticsearch/reference/current/docs-update-by-query.html)
to obtain multiple pieces of data with multiple conditions
https:// www.elastic.co/guide/en/elasticsearch/reference/current/docs-multi-get.html A
complex interface (bulk api)
is an interface that can combine operations such as modification, deletion, and addition (https://www.elastic .co/guide/en/elasticsearch/reference/current/docs-bulk.html)
data rebuild (reindex api)
data rebuild just copies data from one index to another. (But the data definition still needs to be redefined) as follows: Copy all articles in twitter to new_twitter
POST _reindex
{
"source": {
"index": "twitter"
},
"dest": {
"index": "new_twitter"
}
}
return something like
{
"took" : 147,
"timed_out": false,
"created": 120,
"updated": 0,
"deleted": 0,
"batches": 1,
"version_conflicts": 0,
"noops": 0,
"retries": {
"bulk": 0,
"search": 0
},
"throttled_millis": 0,
"requests_per_second": -1.0,
"throttled_until_millis": 0,
"total": 120,
"failures" : [ ]
}
More granular requirements (https://www.elastic.co/guide/en/elasticsearch/reference/current/docs-reindex.html)