SolrCloud 再平衡 API

介绍

在多租户搜索架构中，随着数据规模的增长，手动管理集合、排名/搜索配置变得非常重要和繁琐。该博客描述了我们在 BloomReach 实施的一种创新方法，该方法有助于为 SolrCloud 中的大规模多租户搜索基础设施提供有效的索引和动态配置管理系统。

问题

无法对 Solr 集合的索引和配置管理进行精细控制，这给跨地域的大规模多租户架构带来了复杂性。一些常见的场景，包括添加和删除节点、增加集合及其配置，使集群管理成为一项重大挑战。目前，Solr 不提供扩展框架来启用这些操作中的任何一个。尽管有一些基本的 Solr API 可以执行琐碎的核心操作，但它们不能满足 BloomReach 的扩展要求。

SolrCloud 中的创新数据管理

为了解决扩展和索引管理问题，我们设计并实现了 Rebalance API，如图 1 所示。该 API 允许在 SolrCloud 中进行稳健的索引和配置操作，同时使用各种扩展和分配策略保证零停机。它有两个维度：

七种扩展策略如下：

1. 自动分片 允许将整个集合重新分片到任意数量的目标分片。该过程包括在新分片之间一致地重新分配索引和配置，同时避免任何繁重的重新索引过程。它还提供以下口味：
   • Flip Alias Flag 控制集合的别名（如果它已经有别名）是否应该自动切换到新集合。
   • 基于大小的分片允许用户为集合指定所需的目标分片大小。因此，系统根据总索引大小定义最终的分片数量。
2. Redistribute 允许在未使用的节点之间分配核心/副本。通常，核心集中在几个节点中。 Redistribute 通过平衡所有节点上的副本来允许负载共享。
3. 替换 允许将所有核心从源节点迁移到目标节点。它在需要更换整个节点的情况下很有用。
4. Scale Up 为分片添加新的副本。扩展的默认分配策略是未使用的节点。除了索引复制之外，向上扩展还能够复制额外的自定义每个商家配置（作为对现有复制处理程序的扩展，它只同步索引文件）
5. Scale Down 从分片中删除给定数量的副本。
6. Remove Dead Nodes 是 Scale Down 的扩展，它允许从给定集合的死节点中删除副本/分片。在此过程中，逻辑从 Zookeeper 中取消注册副本。这反过来又节省了 Solr 和 Zookeeper 之间在不断尝试查找死节点上的副本时的大量来回通信。
7. 基于发现的重新分发 允许在将新节点引入集群时分发所有集合。目前，当节点添加到集群时，默认情况下不会发生任何操作。通过重新分配，我们引入了在所有节点上均匀地重新排列现有集合的能力。

图 1：重新平衡 API 概述

场景

让我们使用新的 Rebalance API 快速浏览一些已解决的用例。

场景 1：重新分片以满足延迟 SLA

集合通常会动态增长，导致要检索的文档数量增加（高达约 160M 文档）并减慢过程。为了满足我们的延迟 SLA，我们决定重新分片集合。对于给定的集合，增加分片的过程（例如从 9 个增加到 12 个）具有挑战性，因为没有可访问的方法来平均划分索引数据，同时控制新分片在所需节点上的放置。

最终结果： 如下图所示，默认情况下添加分片不会添加任何文档。此外，新分片所在的节点基于触发操作的机器。使用 Rebalance API，我们通过在新分片中分割成均匀的部分来自动分发文档。

图 2： 自动分片 到更多的分片

场景二：节点到节点的数据迁移

我们有两个节点，其中一个不可用或已死，我们想将副本/核心 迁移 到另一个活动节点。或者我们遇到一组节点上的副本数量不均匀，导致数据负载分布偏斜，我们需要跨节点 重新分配 。

API调用 ：

最终结果： 如下图所示，BEFORE 部分展示了三个节点上的副本/核心分布不均匀。在调用 REDISTRIBUTE 策略时，我们将副本/核心平均分配给所有节点。

图 3：跨节点 重新分配 副本/核心

场景三：动态水平缩放

动态水平缩放非常有用，例如，我们有两个核心用于一个集合，并希望根据流量需求和分配策略临时 扩大 或 缩小规模 。

API 调用： http://host:port/solr/admin/collections?action=REBALANCE&scaling_strategy=SCALE_UP&num_replicas=2&collection=collection_name

最终结果： 我们在下图中观察到，当添加新副本时，必须一次添加一个，无法控制节点分配。此外，只有索引文件被复制。根据新的 Rebalance API，除了根据分配策略选择节点的新副本上的索引文件外，还会复制所有自定义配置。

图 4：通过每个添加 2 个副本来 扩展 两个分片

下图比较了从运行测试中收集的状态，以计算使用各种方法拆分索引的平均时间。重要的是要注意，虽然第二种方法仅考虑索引分布，但 REBALANCE API（第三种和第四种）方法还包括自定义配置的复制。

正如我们在下表中注意到的，与前两种方法相比，BloomReach Rebalance API 在时间方面的表现要好得多。此外，我们通过提高 Rebalance API 的效率来并行化拆分和同步操作，如第四种方法所示（对于超过 150M 的集合，与重新索引相比，自动分片可节省 95%）。

我们使用 Sematext 的 SPM 来监控 BloomReach 的 SolrCloud 性能指标。

结论

简而言之，BloomReach 的新 Rebalance API 通过确保高可用性、零停机时间、无缝分片管理以及提供对索引和配置操作的更多控制来帮助扩展 SolrCloud。此外，这种更快、更强大的机制通过允许动态调整集合大小为自动恢复铺平了道路。

这还不是全部！我们以通用的方式实现了 Rebalance API，因此它可以开源。请继续关注更多详情！

这是 BloomReach 所做的关于 SolrCloud 中更智能的索引和数据管理的工作的帖子。

作者： Nitin Sharma – 搜索平台工程师和 Suruchi Shah – 工程实习生