从 Apache Solr 迁移到 OpenSearch

关键点概述

OpenSearch 是一个开源的分布式搜索引擎，适用于多种使用场景，包括电子商务搜索、企业搜索、网站搜索等。同时，OpenSearch 也是一个分析套件，可用于进行交互式日志分析和实时应用监控等。相较于 Apache Solr，许多组织选择将基于 Solr 的搜索解决方案迁移到 OpenSearch，以追求更低的拥有成本、可扩展性和更高的稳定性。本文将深入探讨从 Solr 迁移到 OpenSearch 的关键考虑因素和步骤。

OpenSearch 简介

OpenSearch 是一个开源的分布式搜索引擎，适用于电商搜索、企业搜索内容管理、文档搜索、知识管理等、网站搜索、应用搜索以及语义搜索等多个用例。同时，它也提供了一套分析工具，可用于交互式日志分析、实时应用监控、安全分析等。与 Apache Solr 类似，OpenSearch 也能对文档集进行搜索，并具备数据摄取与分析的能力。Amazon OpenSearch 服务 是一个完全托管的云服务，可以用来在 AWS 云中部署、扩展和监控 OpenSearch。

迁移动机

许多组织正在将其基于 Apache Solr 的搜索解决方案迁移到 OpenSearch，其主要驱动因素包括：

降低整体拥有成本更好的可扩展性和稳定性改进的摄取连接器如 Data Prepper、Fluent Bit 和 OpenSearch Ingestion消除对 Zookeeper 等外部集群管理器的需求增强报告功能借助 OpenSearch Dashboards 提供丰富的可视化效果

我们建议在迁移时对您的搜索解决方案进行全面重构，以优化其在 OpenSearch 下的表现。尽管 Solr 和 OpenSearch 都使用 Apache Lucene 作为核心索引和查询处理工具，但它们在特性上存在差异。通过规划并执行一个概念验证PoC，可以确保从 OpenSearch 中获得最佳效果。以下内容将深入探讨迁移过程中需要关注的四个关键组件及其具体迁移策略。

关键差异

虽然 Solr 和 OpenSearch Service 通过 Apache Lucene 提供基本的功能，但两者之间在术语和功能上存在一些关键差异：

术语SolrOpenSearch集合与索引集合索引分片与副本分片与副本名称相同分片与副本名称相同API 驱动交互可选的手动配置全部通过 API 进行交互

了解了基本概念后，接下来我们将详细探讨 Solr 到 OpenSearch 的迁移过程中的四个关键组件。

集合到索引

在 Solr 中，集合称为索引。在 OpenSearch 中，索引同样有分片和副本。尽管它们在概念上相似，但我们可以借助此次迁移的机会，采用更优化的分片策略。请遵循相关 分片策略最佳实践。

在迁移过程中，请重新审视数据模型。通过审查数据模型，您可能会发现效率优化的机会，从而显著改善搜索延迟和吞吐量。数据建模不良不仅会导致搜索性能问题，还会延伸到其他领域。例如，您可能会发现构建有效查询以实现特定功能时遇到困难。在这种情况下，解决方案通常需要修改数据模型。

差异：Solr 允许主分片和副本在同一节点上共存，而 OpenSearch 不会将主分片和副本放置在同一节点上。OpenSearch Service 的区域感知功能能够自动确保分片分布在不同的可用区，提高弹性。

OpenSearch 和 Solr 中的副本概念有所不同。在 OpenSearch 中，您通过 numberofshards 来定义主分片数量，从而决定数据的分区。然后使用 numberofreplicas 来设置副本数量，每个副本都是所有主分片的拷贝。举个例子，如果您将 numberofshards 设置为5，numberofreplicas 设置为1，则总共有10个分片5个主分片和5个副本。而在 Solr 中，设置 replicationFactor=1 仅会生成一份数据即主分片。

例如，下述请求在 Solr 中创建一个名为 test 的集合，包含一个分片和无副本：

http//localhost8983/solr/admin/collectionsaction=CREATEampmaxShardsPerNode=2ampname=testampnumShards=1ampreplicationFactor=1ampwt=json

在 OpenSearch 中，可以通过如下请求创建一个名为 test 的索引，包含五个分片和一个副本：

PUT test{ settings { numberofshards 5 numberofreplicas 1 }}

模式到映射

在 Solr 中，schemaxml 或 managedschema 包含了所有字段定义、动态字段和复制字段及字段类型文本分析器、分词器或过滤器。您可以使用模式 API 来管理模式，或者以无模式模式运行。

免费版加速器试用七天

OpenSearch 支持动态映射，与 Solr 的无模式模式相似。在 OpenSearch 中，不必事先创建索引就能摄取数据，通过对新索引名称索引数据，便会使用 OpenSearch 管理服务的默认设置例如：numberofshards 5 numberofreplicas 1创建索引，并根据索引数据进行动态映射。

我们强烈建议您选择预定义的 严格映射。OpenSearch 会根据字段中第一个值来设置模式。如果一个数值偶然成为了一个本应为字符串字段的首个值，OpenSearch 将错误地将该字段映射为数值如 integer。随后的字符串值索引请求将会因映射异常而失败。因此，直接设置映射会让您受益更多。

示例

在 Solr 的 schemaxml 中类似于以下字段定义的内容：

xmlltfield name=id type=string indexed=true stored=true required=true multiValued=false /gt ltfield name=name type=string indexed=true stored=true multiValued=true/gtltfield name=address type=textgeneral indexed=true stored=true/gtltfield name=usertoken type=string indexed=false stored=true/gtltfield name=age type=pint indexed=true stored=true/gtltfield name=lastmodified type=pdate indexed=true stored=true/gtltfield name=city type=textgeneral indexed=true stored=true/gt

在 OpenSearch 中，相应的映射创建可能类似于：

jsonPUT indexfromsolr{ settings { analysis { analyzer { textgeneral { type custom tokenizer standard filter [ lowercase asciifolding ] } } } } mappings { properties { name { type keyword copyto text } address { type text analyzer textgeneral } usertoken { type keyword index false } age { type integer } lastmodified { type date } city { type text analyzer textgeneral } text { type text analyzer textgeneral } } }}

在 OpenSearch 相较于 Solr 的主要注意事项包括：

id 始终作为唯一键，不可显式定义，因为其总是存在。显式启用 multivalued 并非必需，因为任何 OpenSearch 字段都可包含零个或多个值。映射和分析器在索引创建期间定义，可以后续添加新字段或更新某些映射参数，但不支持删除字段。可以使用 ReIndex API 来解决此问题。默认情况下，分析器用于索引和查询阶段。在某些不常见的情况下，您可在搜索时更改查询分析器在查询本身中，而这将覆盖映射和设置中定义的分析器。索引模板 是另一种初始化新索引的好方法，它具有预定义的映射和设置。例如，如果您持续索引日志数据或任何时间序列数据，可以定义一个索引模板，使所有索引具有相同数量的分片和副本。

通过分析您的数据来寻找优化搜索解决方案的机会。例如，如果发现 city 字段仅用于过滤而非搜索，可以考虑将其类型更改为 keyword 而非 text，以避免不必要的文本处理。也可以考虑在 usertoken 字段上禁用 docvalues，如果它仅用于显示。对于文本数据类型，默认情况下禁用 docvalues。

SolrConfig 到设置

在 Solr 中，solrconfigxml 保存集合配置。所有与索引位置、格式、缓存、编码工厂、断路器、提交和日志等相关的配置都在此文件中。

以下是 Solr 配置的一个示例：

xml BESTCOMPRESSION

{solrautoCommitmaxTime15000} false

{solrautoSoftCommitmaxTime1}

1000

{solrmaxbooleanClauses2048}

explicit json true text

在 OpenSearch 中，与 Solr 相比的主要差异有：

OpenSearch 与 Solr 都采用 BESTSPEED 作为默认编解码器使用 LZ4 压缩算法。两者都提供 BESTCOMPRESSION 作为替代方案，OpenSearch 还提供 zstd 和 zstdnodict。此外，关于不同压缩编解码器的 基准测试 可供参考。对于近实时搜索，需设置 refreshinterval。默认值为1秒，适用于大多数用例。我们建议将其增加到30或60秒，以提高索引速度和吞吐量，特别是在批量索引时。最大布尔子句 是一个静态设置，在节点级别通过 indicesqueryboolmaxclausecount 进行设置。无需显式请求处理器。所有搜索使用 search 或 msearch 端点。如果您习惯使用带有默认值的请求处理器，您可以使用 搜索模板。若您习惯使用 /sql 请求处理器，OpenSearch 也支持使用 SQL 语法进行查询，并提供 管道处理语言。拼写检查Didyoumean和 高亮 在查询时都得到支持，无需显式定义搜索组件。大多数 API 响应仅限于 JSON 格式，CAT API 是唯一例外。在使用 Solr 中的 Velocity 或 XSLT 时，必须在应用层进行管理。CAT API 以 JSON、YAML 或 CBOR 格式响应。对于 updateRequestProcessorChain，OpenSearch 提供了 摄取管道，允许在索引前进行数据丰富或转换，多个处理阶段可链接成管道以进行数据转化。处理程序包括 GrokProcessor、CSVParser、JSONProcessor 等，然而，建议在 OpenSearch 外部进行数据变换，理想的地点是 OpenSearch Ingestion，该服务提供适当的框架和多种现成的过滤器进行数据转化。OpenSearch 还引入了 搜索管道，类似于摄取管道，但专为搜索时操作而设计。搜索管道使您能够更容易地在 OpenSearch 中处理搜索查询和搜索结果。目前可用的 搜索处理程序 包括过滤查询、神经查询增强、归一化等，未来还会增加更多。下图展示了如何设置 refreshinterval 和 slowlog，以及其他可能的设置。慢日志 可以像下图那样更精确地通过查询和获取阶段分别设置阈值。

在迁移每个配置设置之前，评估是否可以根据当前搜索系统的经验和最佳实践进行调整。例如，前面的例子中，慢日志阈值设置为1秒，可能会对日志记录造成压力，因此可以重新考虑。此外，maxbooleanClauses 也可能是需要检查和降低的设置之一。

差异：某些设置在集群级别或节点级别完成，而不是在索引级别。这包括最大布尔子句、断路器设置、缓存设置等。

重写查询

重写查询的主题很广泛，值得单独写篇博客；但我们至少想展示一下 OpenSearch Dashboards 中可用的自动完成功能，这可以帮助用户简化查询编写。

类似于 Solr Admin UI，OpenSearch 也提供了一个名为 OpenSearch Dashboards 的用户界面。您可以使用 OpenSearch Dashboards 管理和扩展 OpenSearch 集群。此外，它提供可视化 OpenSearch 数据、探索数据、监控可观察性、运行查询等功能。OpenSearch Dashboards 的查询标签页与 Solr UI 的查询标签页等效，称为开发工具Dev Tools，这是一个开发环境，允许您设置 OpenSearch Dashboards 环境、运行查询、探索数据和调试问题。

现在，让我们构建一个查询以满足以下需求：

在索引中搜索 shirt OR shoe。创建一个聚合查询来查找唯一客户的数量。在 OpenSearch 中，聚合查询被称为 aggregation 查询，也称为 aggs 查询。

Solr 查询将类似于这样：

http//localhost8983/solr/solrsampledataecommerce/selectq=shirt OR shoeampfacet=trueampfacetfield=customeridampfacetlimit=1ampfacetmincount=1ampjsonfacet={ uniquecustomercountunique(customerid)}

下图演示了如何在 OpenSearch 查询 DSL 中重写上述 Solr 查询：

![OpenSearch 查询示例](https//d2908q01vomqb2cloudfrontnet/b6692ea