部落节点和跨群集搜索：Elasticsearch中联合搜索的未来

部落节点和跨群集搜索：Elasticsearch中联合搜索的未来

作者： Luca Cavanna • Simon Willnauer

原文地址：https://www.elastic.co/blog/tribe-nodes-and-cross-cluster-search-the-future-of-federated-search-in-elasticsearch

最近在做跨集群搜索，有做过类似需求经验的或在做的 欢迎讨论

Elasticsearch有一个强大的_search API，允许它搜索本地集群上的所有索引。我们最近发布了Elasticsearch 5.3.0，其中包括一个称为跨群集搜索的新功能，该功能允许用户不仅跨本地索引，而且跨群集撰写搜索。这意味着可以搜索属于其他远程群集的数据。从历史上看，当需要跨越多个集群的搜索时，使用了“部落节点”，但它的工作方式却非常不同。在这篇博客文章中，我们将介绍为什么我们实现跨群集搜索，它是如何工作的，并与Tribe节点进行比较，以及为什么我们确信这是使用Elasticsearch进行联合搜索的未来正确方向的一步。

把事情简单化

当我们坐下来尝试重新设计下一代的部落节点时，我们重新评估了它试图解决的问题。目标是使联合搜索成为可能，没有Tribe节点提供的所有限制，也没有为其添加特定的API，因此维护这种特性也将变得更容易。我们意识到部落节点除联合搜索之外的一些功能是商品。部落节点支持许多Elasticsearch API，例如，允许通过部落节点检索集群状态或节点统计信息，部落节点将返回从所有远程集群收集的信息并合并到单个视图中。合并不同来源的信息并不复杂，而且通过向不同的集群发送多个请求，在客户端很容易执行。在服务器端必须解决的难题是联合搜索。它涉及分布式分散和聚集在属于多个集群的节点上执行以及需要内部知识的结果合并和缩减。这就是为什么我们决定把重点放在通过在现有的_search API中增加对跨群集搜索的支持，从而以可持续和稳健的方式解决这个特定的问题。

Search API Detour

_search API允许Elasticsearch针对多个索引执行搜索，查询，聚合，建议等等，每个索引都由一个或多个分片组成。当客户端向Elasticsearch集群发送搜索请求时，接收请求的节点充当整个请求执行的协调节点。它标识搜索必须执行的索引，碎片和节点。执行时，所有持有被查询分片的数据节点并行接收请求，然后每个节点在本地执行查询阶段，并将结果发送回协调节点。协调节点等待所有分片进行响应，以便将结果降低到需要从分片中提取的前N个匹配。

跨群集搜索如何工作

由于Elasticsearch 5.3.0，可以通过名称空间下的集群更新设置API来注册远程集群search.remote。每个群集由群集别名和用于发现属于远程群集的其他节点的种子节点列表标识，如下所示：

PUT _cluster / settings   { “persistent” ：{ “search” ：{ “remote” ：{ “cluster_one” ：{ “seeds” ：[ “remote_node_one：9300” ] }，“cluster_two” ：{ “seeds” ：[ “remote_node_two ：9300“ ] } } } } }                                                                                                 

一旦注册了一个或多个远程群集，可以使用远程配置的群集的_search API对其索引执行搜索请求。与所谓的本地索引相比，远程索引必须用相应的配置的簇别名（例如冒号cluster_two:index_test）分隔。

只要搜索请求扩展到远程群集上的索引，协调节点就会通过为每个群集发送一个_search_shards请求来解析远程群集上这些索引的分片。一旦获取了分片和远程数据节点，就像上面解释的本地集群上的任何其他搜索一样，使用完全相同的代码路径执行搜索，这极大地提高了可测试性和鲁棒性。

从搜索执行的角度来看，只要协调节点能够到达属于远程集群的某些节点，属于远程集群的本地索引和索引之间就没有区别。最后，作为属于远程集群的搜索响应的一部分返回的匹配的索引名称的前缀是其集群别名。

在注册远程集群时，Elasticsearch通过配置中的种子节点默认发现每个配置的远程集群最多3个节点。与本地群集中的任何节点连接到任何其他节点的节点相比，跨群集搜索节点仅以单向方式连接。这些是协调节点将作为跨群集搜索请求的一部分进行通信的节点。可以控制在注册远程集群时发现多少个节点，以及将属于远程集群的节点标记为网关，以便精确控制哪些节点将接收来自外部世界的连接。如果节点持有必须作为跨群集搜索请求的一部分访问的数据，则该节点将不会从远程协调节点接收到直接连接，

另外，可以通过设置来控制哪些节点可以充当协调节点作为跨群集搜索请求的一部分search.remote.connect。这对控制集群中的哪些节点可以向远程集群发送请求很有用。如果不允许连接到远程集群的节点收到涉及远程集群的搜索请求，则会返回错误。

那么部落节点呢？

针对多个集群进行搜索对于Elasticsearch来说并不是什么新东西。实际上，用户至今一直在使用Tribe Node。

部落节点是一个单独的节点，其主要工作是嗅探远程集群的集群状态，并将它们合并在一起。为了做到这一点，它加入了所有的远程集群，使它成为一个非特殊的节点，它不属于自己的集群，而是加入了多个集群。

当一个Tribe节点收到一个搜索请求时，它立即知道将它转发给哪个节点，因为它保存了所有已注册的远程集群的集群状态，实际上它是所有集群中的一个节点。这意味着跨部门搜索所需的附加“找出远程分片所在的位置以及它属于哪个节点”的步骤对于部落节点不是必需的。请注意，跨群集搜索不需要额外的节点，因为任何节点都可以充当搜索请求的协调节点，而不管请求是否跨越多个群集。这也意味着没有其他节点加入远程集群，因此不必将集群状态更新发送给那些可能会在使用Tribe节点时减慢远程集群的速度。

此外，在合并来自远程集群的集群状态时，虽然属于多个集群，但部落节点不能保持具有相同名称的索引在其自己的集群状态中。这是跨群集搜索寻址的一个很大的限制，并且能够动态注册，更新和删除远程群集，这需要在使用Tribe节点时重新启动节点。

此外，作为部落节点这样的特殊节点，随着时间的推移，很难保持代码明智，因为它是Elasticsearch节点的主要假设的例外，即一个节点必须属于一个并且只有一个集群。

进一步的搜索改进

Elasticsearch的检索功能是非常出色的，即使在显着的群集大小的情况下，用户也可以搜索尽可能多的碎片。但是等等，不一定是这样 - 至少在目前的情况下。Elasticsearch带有一个软限制的限制action.search.shard_count.limit，即拒绝超过1000个分片的搜索请求。我们为什么要限制这个？那么，这里的原因是显而易见的，因为在上面的搜索绕道部分提到的实施细节。我们分散所有碎片，并保持所有碎片结果密集的数据结构，直到所有碎片回应。假设您正在运行大型聚合，协调节点必须在初始阶段的整个持续时间内为每个搜索请求保留一个不重要的内存量。

现在，我们正在强调搜索跨越多个碎片的跨簇搜索，因此具有如此软限制的碎片毕竟不能提供良好的用户体验。为了消除查询大量碎片的影响，协调节点现在将批量的512个结果中的聚合减少到单个聚合对象，同时等待更多的结果到达。即将到来的改进是最终完全消除软限制的第一步。即将到来的5.4.0版本也将允许批量减少前N个文件。有了这两个主要的内存消费者的控制，我们现在默认action.search.shard_count.limit设置为无限制。这允许用户仍然限制和保护他们在分片数量上的搜索，同时为其他用户提供良好的用户体验。

结论

跨群集搜索是执行联合搜索的新方法，将来将取代部落节点。它与部落节点相比的工作方式非常不同，并且不受部落节点带来的大部分缺陷的限制。我们邀请您通过下载Elasticsearch 5.3.x（或者在Elastic Cloud上部署）来试用，并给我们提供反馈。