ES学习一 -- index

windows:

.\elasticsearch.bat

.\elasticsearch.bat -E path.data=data2 -E path.logs=log2

.\elasticsearch.bat -E path.data=data3 -E path.logs=log3

The additional nodes are assigned unique IDs. Because you’re running all three nodes locally, they automatically join the cluster with the first node.

---

index

0.Request

PUT //_doc/<_id>

POST //_doc/

PUT //_create/<_id>

POST //_create/<_id>

1.Automatically create data  streams and indices

action.auto_create_index

PUT _cluster/settings

{ "persistent": { "action.auto_create_index": "my-index-000001,index10,-index1*,+ind*" }}

Allow auto-creation of indices called my-index-000001 or index10, block the creation of indices that match the pattern index1*, and allow creation of any other indices that match the ind* pattern. Patterns are matched in the order specified.

允许创建my-index-000001 或 index10。不允许创建index1*，允许创建+ind*。减号不允许，加号允许

action.auto_create_index

PUT _cluster/settings{ "persistent": { "action.auto_create_index": "true" }}

Allow automatic creation of any index. This is the default.

2.Create document IDs automatically

POST my-index-000001/_doc/{ "@timestamp": "2099-11-15T13:12:00", "message": "GET /search HTTP/1.1 200 1070000", "user": { "id": "kimchy" }}

When using the POST //_doc/ request format, the op_type is automatically set to create and the index operation generates a unique ID for the document.

3.routing

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 my-index-000001/_doc?routing=kimchy{ "@timestamp": "2099-11-15T13:12:00", "message": "GET /search HTTP/1.1 200 1070000", "user": { "id": "kimchy" }}

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

4.Timeout

The primary shard assigned to perform the index operation might not be available when the index operation is executed. Some reasons for this might be that the primary shard is currently recovering from a gateway or undergoing relocation. By default, the index operation will wait on the primary shard to become available for up to 1 minute before failing and responding with an error. The timeout parameter can be used to explicitly specify how long it waits. Here is an example of setting it to 5 minutes:

PUT my-index-000001/_doc/1?timeout=5m{ "@timestamp": "2099-11-15T13:12:00", "message": "GET /search HTTP/1.1 200 1070000", "user": { "id": "kimchy" }}

---

GET

0.Request

GET /_doc/<_id>

HEAD /_doc/<_id>

GET /_source/<_id>

HEAD /_source/<_id>

1.Description

GET my-index-000001/_doc/0?XXX  后边的

1.1Realtime

By default, the get API is realtime, and is not affected by the refresh rate of the index (when data will become visible for search). In case where stored fields are requested (see stored_fields parameter) and the document has been updated but is not yet refreshed, the get API will have to parse and analyze the source to extract the stored fields. In order to disable realtime GET, the realtime parameter can be set to false.

1.2Source filtering

By default, the get operation returns the contents of the _source field unless you have used the stored_fields parameter or if the _source field is disabled. You can turn off _source retrieval by using the _source parameter:

GET my-index-000001/_doc/0?_source=false

GET my-index-000001/_doc/0?_source_includes=*.id&_source_excludes=entities

GET my-index-000001/_doc/0?_source=*.id

1.3Routing

If routing is used during indexing, the routing value also needs to be specified to retrieve a document. For example:

GET my-index-000001/_doc/2?routing=user1