ES学習ノートの--delete appiの実現プロセス

ESのdelete appiは使いやすいです.

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

前にget apiの主要な流れを学びました.ここでdelete apiの実現原理を探ってみます.優先的な選択delete apiはindex apiではなく、主に削除が容易であるように思えるので、delete api学習曲線の選択は比較的緩やかであるべきである.
ES関連機能アクションの名前は統一されています.例えばget api、対応する実装クラスの名前はTransportGetAction、delete api、対応する実装クラスの名前も同じです.
しかし、Transport Delectionを勉強して、その核心的な流れは父の類にあります.個人的にはこの名前はよくないと思いますが、コピーだけで機能が実行されるという意味です.TransportDeleteActionを知る前に、まずTransportReplicationActionの実行プロセスを説明します.

 ES            :             ，                。          :

s1:              。

s2:             。

s3:                。

上記のように、TransportReplicationActionクラスでは、3つのサブクラスが対応している.
クラスname
機能
ReroutePhase
要求をprimaryセグメントがあるノードにルーティングする.
Primary Phase
メインスライスでタスクを実行します.
Replication Phase
すべてのreplicaをスライスしてタスクを実行します.
この構造は一般的で、テンプレートのようです.このクラスにはコメントがあり、クラスの運行フローを説明しました.

/**
 * 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.
 */

説明すると次のようなポイントがあります.

1.           primary shard  ，   replica shard  。
2.             ，  `TransportDeleteAction`         。
3.                  cluster state         。           `resolveRequest`

この流れに基づいて、削除操作はまだヘビー級のもので、コピーが多いほど、削除のコストが大きいことが分かります.
ESは各ノードコードが同じであるため、デフォルトでは各ノードのロールが自由に切り替わります.ここでは主にdelete apiの方法を勉強する時の小さなコツです.たとえばコード:

        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, ... ){
                ...
            }
        }

ここTransportReplicationActionの後、受信ロジックはどこにありますか?

  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());

すなわち、transportService.sendRequest()の第二パラメータtransportService.sendRequest()とtransportService.sendRequest()の第一パラメータactionは、一対一に対応している.transportService.registerRequestHandler()に会ったら、直接actionパラメータを通して対応するHandlerを見つければいい.例えばtransportService.sendRequest()は、action方法で送信された要求を受信するためのものである.PrimaryOperationTransportHandlerに戻って、ES削除の論理を理解するには、クラス全体が2つの方法を理解するだけでよい.

#  primary shard       
shardOperationOnPrimary()

#  replica shard       
executeDeleteRequestOnReplica()

この中は削除の具体的なロジックです.Engine関連の内容は後からもっと深くなります.
削除に関して、ESはReroutePhase().run()の考え方を提供する.初期ESは、queryによる大量削除をサポートしていますが、後でこの機能が危険すぎると感じたら、TransportDeleteActionをPluginに作成し、ユーザー自身でプラグインをインストールしてから使用できます.ES一括削除の考え方については、delete by idプラグインのソースコードを参照することができますが、delete by queryを介して条件に従ってdoc idを検索し、delete by queryを使用して削除します.
最後に、scroll queryは比較的一般的なモードであるため、ESの他の機能もこのモードに基づくものである.例えば、client.bulk().