Shulou(Shulou.com)06/03 Report--

ES's delete api is very easy to use.

Curl-XDELETE 'http://localhost:9200/index/type/doc_id'

Having learned the main flow of get api, let's explore the implementation principle of delete api. Prefer delete api over index api, mainly because it seems easier to delete, and the learning curve of choosing delete api should be relatively smooth.

The naming of Action related to ES is very uniform, such as get api, the name of the corresponding implementation class is TransportGetAction, and the name of the corresponding implementation class of delete api is the same: TransportDeleteAction.

But the core process of learning TransportDeleteAction is in its parent class: TransportReplicationAction. Personally, I think the name is not good enough to make people think that it will only perform the relevant functions on the copy.

Before understanding TransportReplicationAction, let's talk about the execution process of delete api, that is, the spoiler result, and then analyze the plot.

The process of deleting a document from ES is as follows: delete from the main shard, and then delete on all replica shards. So the core process is divided into three steps: S1: routing from the request node to the main shard node. S2: delete operation is performed on the main shard node. S3: perform a delete operation on all replica shards.

As mentioned above, in the TransportReplicationAction class, there are three subclasses:

Class name function ReroutePhase routes the request to the node where the primary shard is located PrimaryPhase executes the task on the main shard ReplicationPhase executes the task on all replica shards

This structure is generic, just like a template. This class has a comment that explains how the class runs:

/ * Base class for requests that should be executed on a primary copy followed by replica copies. * Subclasses can resolve the target shard and provide implementation for primary and replica operations. * * The action samples cluster state on the receiving node to reroute to node with primary copy and on the * primary node to validate request before primary operation followed by sampling state again for resolving * nodes with replica copies to perform replication. , /

There are the following key points to explain:

1. Requests based on this class are executed first in primary shard and then in replica shard. two。 The specific operations are implemented by subclasses, such as `TransportDeleteAction`. 3. Each node needs to validate the request parameters based on cluster state before performing the relevant operation. The corresponding method for this verification is `SecretveRequest`.

Based on this process, you can see that the delete operation is relatively heavyweight, and the more copies you have, the greater the cost of deletion.

Because the code of each node in ES is the same, the roles that each node can play are freely switched by default. This is mainly a tip when studying the transportService.sendRequest () method. Such as the code:

Void performOnReplica (final ShardRouting shard) {/ / if we don't have that node, it means that it might have failed and will be created again, in / / this case, we don't have to do the operation, and just let it failover final String nodeId = shard.currentNodeId ();... Final DiscoveryNode node = nodes.get (nodeId); transportService.sendRequest (node, transportReplicaAction,...) {...}}

Where is the logic of acceptance after transportService.sendRequest () here?

TransportService.registerRequestHandler (actionName, request, ThreadPool.Names.SAME, new OperationTransportHandler ()); transportService.registerRequestHandler (transportPrimaryAction, request, executor, new PrimaryOperationTransportHandler ()); / / we must never reject on because of thread pool capacity on replicas transportService.registerRequestHandler (transportReplicaAction, replicaRequest, executor, true, true, new ReplicaOperationTransportHandler ())

That is to say, the second parameter action of transportService.sendRequest () and the first parameter action of transportService.registerRequestHandler () correspond one to one.

If you encounter transportService.sendRequest (), you can find the corresponding Handler directly through the action parameter. For example, PrimaryOperationTransportHandler is used to receive requests sent in the ReroutePhase (). Run () method.

Going back to TransportDeleteAction to understand the logic of ES deletion, the whole class only needs to understand two methods:

# deletion logic shardOperationOnPrimary () executed in primary shard # deletion logic executeDeleteRequestOnReplica () executed in replica shard

This is the specific logic of deletion, and the content related to Engine will be further deepened later.

With regard to deletion, ES provides delete by id's idea. In the early days, ES supported batch deletion through query, but later felt that this feature was too dangerous, so delete by query was made into Plugin, which can only be used after users install the plug-ins themselves. About the idea of batch deletion of ES, you can refer to the source code of the delete by query plug-in. The general idea is to query out the doc id by condition through scroll query, and then delete it using client.bulk ().

Finally, because TransportReplicationAction is a more general pattern, other features of ES are also based on this pattern, such as TransportIndexAction.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.