[不懂就问]ES读写连接小疑问

尝试着回答下，第一次回复问题，答的不好，勿怪：）
首先我想解释下ES里面的几个主要角色：Master-eligible node, Data node, Coordinate node, Ingest node, Machine learing node
默认情况下，通过_cat/nodes接口可以看到，如果不配置任何角色，会包含mdi，也就是说节点同时可以做master, data, ingest三种角色，另外每个节点都可以做协调节点的角色，机器学习角色会使用到x-pack里面的相关特性，暂且不说。角色的调整一般直接在yml里修改，详情可以参考官方文档关于这块的解说: https://www.elastic.co/guide/e ... .html
如果将其他角色设为false，那么此时的节点就是一个纯粹的协调节点，如果只是将某一个角色设为false，那只是这一种角色失效。
正因为每个节点都可以是协调节点，所以你在logstash的配置文件里可以写3个master节点，其实你也可以写其中的某几个数据节点，在数据量不大的时候，都没啥问题。这是为什么呢？新增数据节点，是否需要增加数据节点到logstash里面呢？或者说这个怎样配才合理呢？有什么差异呢？
 
这就需要来了解ES的写入和查询过程了。
其实不管是写入还是查询，请求都是首先经过协调节点，而不是Master节点。协调节点使用Netty这种高性能的NIO框架处理大量的读写请求，因为要保证读写请求处理的高性能，在协调节点上还会做一些数据的初始判断，一些校验工作，同时将请求转发到各个数据节点，当然转发请求之前也会向Master请求一些东西，比如集群是否Red等，另外如果此时要写入的索引不存在，也会看是否要创建对应索引，索引相关的管理工作都是Master负责的，所以如果Master出问题，请求是不会转发下去的。
 
数据写入时：协调节点会根据写入的数据以及集群的元数据信息，将一批一批的数据（BulkRequest）拆分到不同分片组合中，生成一个又一个新的（ShardBulkRequest）基于分片的请求，然后协调节点根据元数据信息知道某个分片是在哪个数据节点中，然后通过内部的RPC调用，将写入请求转发到对应的数据节点中，数据节点最后调用Lucene接口写入Lucene（当然这里面也涉及到很多细节点，比如translog, refresh, flush, segments, sort等等）。在写入过程中，可以看到协调节点要简单处理所有数据，分发请求任务等，主要消耗为CPU和网卡，数据节点主要消耗CPU、内存、磁盘IO，Master在这个过程中只是给协调节点提供一些集群的元数据信息，数据并不经过它。
 
数据查询时：协调节点会解析搜索请求，这里又分普通的DSL请求和包含Aggregation的统计聚合请求，协调节点在中间做的事情包含解析搜索请求，根据元数据信息将请求拆分到不同的数据节点中去，因为一次查询可能需要查很多的Shard信息，所以最后到数据节点的请求都是基于Shard的请求，数据节点也只负责执行Shard维度的搜索请求，获取Shard维度的搜索结果，然后返回给协调节点。协调节点拿到所有数据节点返回的数据后，会做最后的统计或者聚合或者排序，然后返回给客户端。如果最后是获取Doc文档值的请求，第一次协调节点只会从数据节点中查询到所有的DocId，然后做完统计聚合排序等之后，才会去数据节点中获取最后需要的Doc文档，也即Query_Then_Fetch。可以看到在这个过程中，如果查询条件比较复杂，协调节点可能做的事情就比较多，需要消耗比较多的CPU和Memory，当然数据节点也会消耗比较多的CPU和Memory，Master在这个过程中也只是提供一些集群元数据信息，查询数据也不会经过它。
 
总的来说，在集群角色管理这块，因为Master维护着整个集群的元数据信息（其实集群中的每个节点也都有缓存集群相关元数据，只是有更新时，Master会通知到所有节点去更新相关元数据），还有整个集群的索引相关的CURD操作，也是Master执行。Master相当于集群的大脑，非常重要，只要它出问题，整个集群就无法工作了，但是它本身的压力并不大，只是稳定性非常重要，所以一般会单独规划3个左右的机器充当Master角色，并且这些机器配置一般都比较低，因为要处理的东西并不多，然后将其他角色设为false，保证集群稳定。对于协调节点，一般情况下是让数据节点同时兼任协调节点角色。当然在某些业务场景下，也可以考虑独立出一些协调节点出来，将其他角色全部设为false，这样协调节点专注处理请求，对数据节点返回的数据做汇聚或排序等，这些节点需要较高的CPU和Memory，对磁盘IO没有要求，然后让数据节点专门做它该做的事，数据节点对CPU和Memory以及磁盘IO都有要求。
 
对于客户端的节点配置，其实是配置协调节点的列表，因为所有的请求都是经过协调节点来处理的，不过每个节点都可以是协调节点，所以无论怎么配，数据量小时，问题都不大。如果集群有设置单独的协调节点，客户端配所有的协调节点就可以了，如果没有配单独的协调节点，那就配一些数据节点即可，至于配多少个，后面增加了怎么办，这个就看情况。我觉得一般有足够多的就行了，因为此时在客户端配的节点实际上就充当了协调节点角色和另一种本身配置的角色，最好配的都是数据节点（在没有独立协调节点的时候），由于每次修改客户端配置，可能需要重新发布客户端，所以尽量少修改，一次性多配点就好了，中间增加少量的可以暂时先修改配置，不重启生效，后面合适时再生效。当然如果有了独立的协调节点，这个地方的配置就会简单些，不过随着量越来越大，独立的协调节点也是会增加的，也会面临同样的配置修改问题。
 
像楼主说的用Master配为客户端节点，自然是不妥的，因为这样Master节点就同时充当了协调节点角色。后面写入和查询的量上来后，如果Master节点配置低，数量少，就扛不住，这时Master就会不稳定，从而使集群不稳定（前面说了，由于Master角色的特殊性，要求非常稳定）。如果Master配置高，节点多，也会增加成本或者增加Master的不稳定因素，同时量到了一定程度，也需要增加Master节点的数量，因为他兼职的协调节点不够了，也会面临同样的配置修改问题。
 
最后总结下我的观点：不管怎样，随着量越来越大，客户端配置修改问题都会存在，只是如果有独立协调节点，自然是配独立协调节点，如果没有，最好配数据节点，配Master节点就不合适了。当然量少，没有任何性能瓶颈，就看心情玩了：）
 

对数据的操作，都是走datanode，
对元数据的操作，都是masternode

最好附上官方说明什么的，我去研究下。。
楼上说应该用DATANODE，我现在用的MASTERNODE，每天2个T的数据写入，完全没有任何问题。
 
起因是我同事用的DATANODE，昨天增加了2台DATANODE，他现在再改配置把增加的两台DATANODE IP增加进去，我说用MASTER IP就行了。他说用DATANODE好！！
 
总结就是MASTERNODE和DATANODE都可以用，所以到底有没有差异？？？？
 

你的数据写入请求会先丢到master里面，让它决定这条数据应该存在哪个datanode，然后这条数据再转发给那个node做存储、索引…
 
当然了，如果你的节点同时做master和data的时候也可能是直接masternode自己就存了。
 
所以写操作最好是把master（们）的ip写进去，data就不用了（反正也要交互一次master）

可以肯定是都可以，但是压力大的话最好用clientnode

最好加个协调节点：coordinate 节点。充当路由的角色。

Data node
A node that has node.data set to true (default). Data nodes hold data and perform data related operations such as CRUD, search, and aggregations.
 
Master Eligible Node

The master node is responsible for lightweight cluster-wide actions such as creating or deleting an index, tracking which nodes are part of the cluster, and deciding which shards to allocate to which nodes. It is important for cluster health to have a stable master node.
 
https://www.elastic.co/guide/e ... .html
 
 
 
 

集群中的任何节点都可以作为协调节点