elasticsearch NodeBuilder vs TranportClient

Question

Probabilmente una domanda molto facile (e stupida) agli altri sviluppatori di elasticsearch, qual è la differenza tra questi due?

Mi collego a un server elasticsearch remoto da una webapp Java, finora ho utilizzato TransportClient ma mi chiedevo se è possibile utilizzare NodeBuilder oppure NodeBuilder deve essere utilizzato solo per i client incorporati?

Se uno dei due può essere utilizzato per connettersi a server ES remoti, quale dovrebbe essere migliore in termini di memoria e prestazioni?

Se qualcuno può indicarmi un NodeBuilder che si connette a un server ES remoto, l'esempio sarebbe ottimo perché non ho avuto nessuna scoperta fortunata.

Grazie.

Answer 1

NodeBuilder può anche essere utilizzato per connettersi a un cluster.

Node node = nodeBuilder().clusterName("yourcluster").client(true).node(); 
Client client = node.client(); 

Si unirà al cluster come un altro nodo e sarà a conoscenza dell'intera topologia. Utilizzando i nodi, è possibile utilizzare il multicast per scoprire altri nodi in esecuzione.

mia opinione è che io preferisco usare TransportClient rispetto NodeClient perché gli altri nodi del cluster non riceveranno informazioni inutili quando il TransportClient si ferma. Quando un NodeClient si arresta, ogni nodo deve sapere che anche se non devono gestirlo in quanto non contiene alcun dato. Inoltre, ho visto in modalità di debug che NodeClient avvia più Threads di TransportCLient. Quindi penso che TransportClient abbia un minore ingombro di memoria.

A proposito, se si utilizza Spring, è possibile utilizzare le fabbriche spring-elasticsearch per quello. In caso contrario, si può sempre dare un'occhiata al codice sorgente per vedere come gestisco NodeClient vs TransportClient.

Spero che questo aiuti.

MODIFICA 2016-03-09: NodeClient non deve essere utilizzato. Se ce n'è bisogno, le persone dovrebbero creare un nodo client (avviare un nodo elasticsearch con node.data: false e node.master: false) e utilizzare un TransportClient per collegarsi ad esso localmente.

Answer 2

Se ho capito la documentazione correttamente, è utile usare nodo client, almeno se si dispone di cocci:

Il vantaggio di utilizzare il client [Node] è il fatto che le operazioni siano automaticamente indirizzati alla il nodo (i) le operazioni devono essere eseguite su , senza eseguire un "doppio salto". Ad esempio, l'operazione index verrà automaticamente eseguita sul frammento che terminerà con lo esistente in.

vs

E [cliente Trasporti] non al cluster, ma semplicemente ottiene una o più iniziali indirizzi di trasporto e comunica con loro in giro robin su ogni azione (anche se la maggior parte delle azioni saranno probabilmente operazioni "due hop" ).

Come Interpreto questo, utilizzando un nodo (preferibilmente con il cliente impostato a true), che si unisce al cluster e quindi utilizzare il client su quel nodo, si inviare richieste direttamente al nodo corretto del cluster.

Utilizzando TransportClient, si connette a qualsiasi nodo, che verrà quindi reindirizzare (o, eventualmente, inoltrare la richiesta, non è sicuro) la richiesta al nodo corretto ("due hop")

Utilizzando nodo client dovrebbe essere più efficiente in termini di traffico di rete e carico sui nodi.

Answer 3

Inoltre, le persone dovrebbero sapere che il client Node si unisce al full mesh cluster e diventa anche un proxy in modo che altri client possano connettersi ad esso e anche essere in grado di siti di plug-in server, qualcosa da considerare quando si blocca il cluster.

Il client di nodo può essere utilizzato per eseguire la raccolta di dispersione in modo da poter alleviare l'elaborazione dai nodi di dati.

Non sono sicuro che anche il client di trasporto si disponga.