Apache Solr

定义

Apache Solr是一个开源的搜索服务器，用Java开发，运行在Java运行时环境之中，最低要求Java 11^[1]。它的检索内核直接使用Apache Lucene，索引的建立、词项查询与相关性打分都由这一库完成，Solr在其上叠加了HTTP访问层、配置体系和管理界面^[2]。

按官方文档的定位，Solr面向非结构化、半结构化以及两者混合的数据，用于构建文档检索或分析类应用，对关系型、图、统计等场景只提供有限的辅助支持^[3]。软件以Apache License 2.0协议发布，使用者可以按商业或非商业需要修改与优化^[3]。

原理

Solr检索的基础是倒排索引：系统把文档字段经过分词与过滤后得到的词项，映射到包含这些词项的文档编号和位置，查询时由词项直接定位文档，而不必逐篇扫描原文^[4]。写入文档时，字段文本会依次经过分析器链，完成切词、大小写归一、停用词剔除和词干还原等处理，分析链可按语言和业务配置^[4]。

客户端通过HTTP 1.1或2.0请求提交查询，默认以JSON返回结构化的文档描述，也可输出XML、CSV或二进制格式；任何能发起HTTP请求的平台都能与Solr通信^[3]。查询由查询解析器处理，标准解析器支持布尔逻辑、短语、通配符和邻近查询，eDisMax等解析器则面向用户直接输入的简单关键词^[4]。

结果排序依赖相关性评分，Solr沿用Lucene的打分函数，默认使用BM25模型，综合考虑词项在文档中的出现频次、该词项在整个语料中的稀有程度以及文档长度，公式可写作 $score(D,Q)=\sum_{q_i \in Q} IDF(q_i)\cdot\frac{f(q_i,D)\cdot(k_1+1)}{f(q_i,D)+k_1\left(1-b+b\cdot\frac{|D|}{avgdl}\right)}$^[5]。参数$k_1$控制词频增益的饱和程度，$b$控制文档长度的归一化强度，开发者可以调整权重或用函数查询改变排序^[4]。

在集群层面，SolrCloud把索引切分为分片并维护多个副本，以提高吞吐和可靠性，其中一种集群形态依赖Apache ZooKeeper协调各节点的配置与状态^[3]。另一种形态不需要额外的基础设施，实例由管理员直接管理^[3]。

发展历程

Solr起源于2004年，由CNET Networks的Yonik Seeley作为内部项目开发，用途是为公司网站增加搜索功能。2006年1月，CNET Networks将源代码捐赠给Apache软件基金会，项目进入孵化阶段，2007年1月从孵化器毕业，成为Lucene下的独立顶级项目。

2008年9月发布的Solr 1.3加入了分布式检索能力和性能改进；2009年11月的1.4版则增强了索引、检索与分面功能，并支持PDF、Word、HTML等富文本文档处理。2010年3月，Lucene与Solr两个项目合并，此后由同一批提交者共同开发，版本号也从2011年起统一。

2012年10月发布的4.0版引入SolrCloud；2015年2月的5.0版首次以独立应用形式打包，结束了以war包部署的官方支持。2016年的6.0版增加跨集合的并行SQL查询，2017年的7.0版加入多种副本类型、自动伸缩和数学引擎，2019年的8.0版开始支持HTTP/2与带认证的管理界面。

2020年11月，彭博社将Solr Operator捐给Lucene/Solr项目；2021年2月Solr成为独立的Apache顶级项目，不再隶属Lucene。2022年5月发布的9.0版是脱离Lucene后的首个版本，要求Java 11，并引入KNN近邻检索等特性。其后9.x系列持续发布维护版本，官方文档记载9.7.0于2024年9月9日发布^[6]。

应用

Solr的常见用途是站内搜索与网站导航，官方称其为许多大型互联网站点的搜索和导航功能提供支持^[2]。全文检索之外，它提供分面搜索用于按类别聚合并统计结果，命中高亮用于展示匹配片段，地理空间检索用于按经纬度做范围查询和排序，这些能力常见于电商与内容类站点^[2]。

在数据处理方面，Solr具备富文本文档解析与数据库集成能力，并可通过流式表达式对整个语料或其子集做统计分析，用数学表达式支撑进阶分析与预测类任务^[3]。查询语法覆盖从单一关键词到跨多字段的复杂查询，结果折叠与聚类则被用于商品列表等场景^[3]。

工程实践中，Solr常被放在既有搜索需求、已具备ZooKeeper运维能力的机构中，用于结构化文档集合的检索和需要精细查询控制的场景^[7]。它可用官方镜像运行于容器中，并可借助Operator部署在Kubernetes上^[8]。

局限

Solr的分布式协调在传统上依赖ZooKeeper，生产集群需要额外的组件与相应的运维知识，集群扩容步骤也相对繁琐^[7]。有团队在迁移实践中记录了自动伸缩的若干问题，例如副本被分配到同一分片的不同节点导致单点压力过大，跨可用区的均衡需要自行编写脚本实现^[9]。

配置方式偏静态是另一项限制。集合的字段、分析器和默认处理器分别写在schema.xml与solrconfig.xml中，修改模板不会改变已存在索引的配置，需要直接对目标索引施加设置^[9]。较新的版本支持托管模式与免模式建索引，但显式定义字段仍是推荐做法^[10]。

在实时性上，Solr的索引可见依赖提交策略，写入后需要提交才能被检索到，与面向近实时日志分析的引擎相比并非其设计重心^[10]。学习与维护成本也偏高，有技术文章指出其学习曲线较陡、二次开发门槛高于同类产品^[11]。此外，机器学习相关能力相对有限，可视化往往需要借助外部工具^[10]。

参见

• Apache Lucene —— Solr的检索内核，负责索引建立、词项查询与相关性打分。

• Elasticsearch —— 同样基于Lucene构建的开源搜索与数据分析引擎，常与Solr比较选型。

• Apache ZooKeeper —— SolrCloud集群常用的分布式协调组件。

• 倒排索引 —— Solr实现快速全文检索所依赖的核心数据结构。

• BM25 —— Solr默认采用的相关性评分模型。

• 分面搜索 —— Solr提供的按类别聚合与统计检索结果的能力。