Riak Search 2.0是Riak KV 2.0引入的重大功能增强，它与旧版Riak Search几乎没有继承关系，是一次彻底的重写。旧版Riak Search基于Riak Core自研的倒排索引，查询能力和运维体验都比较有限，而新版直接采用Apache Solr作为底层检索引擎，通过Yokozuna项目将Solr嵌入到Riak节点中，让每个Riak节点同时承担存储节点与检索节点的角色。这种设计使得Riak第一次拥有了接近主流搜索引擎的查询表达能力，同时保持了去中心化、无单点故障的分布式架构特性。
Riak Search 2.0的架构设计与核心变化
要理解Riak Search 2.0的价值，首先要明白它和旧版的本质区别。旧版Riak Search将索引数据以Riak KV对象的形式存储，查询时依赖Riak的覆盖计划（coverage plan）遍历分区，性能和相关性排序都难以令人满意。新版则完全不同：每个Riak节点内部运行一个嵌入式的Solr实例，数据写入Riak KV后，Yokozuna组件会提取对象内容并同步写入本节点及副本节点对应的Solr Core中。
具体流程是这样的：客户端写入一个Riak对象后，Riak将该对象通过valve协调器复制到N个副本节点，每个持有副本的节点都会在本地的Solr中建立索引。这意味着索引副本数与KV副本数保持一致，任何一个节点宕机，索引数据仍然可以从其他副本节点查到。查询时，Riak会基于一致性哈希环计算覆盖计划，由部分节点代表整个集群执行Solr分布式查询，最后聚合结果返回客户端。
这种架构的最大好处是不需要单独维护一套搜索集群。相比Riak加Elasticsearch的双写方案，Riak Search 2.0消除了两个存储系统之间数据不一致的噩梦，写入路径只有一条，故障排查和容量规划都简单得多。当然代价也很明显：每个节点要同时承担KV存储与索引构建的开销，内存和磁盘的规划需要更谨慎。
索引创建与Schema配置实践
使用Riak Search 2.0的第一步是创建索引。与传统Solr standalone模式不同，Riak中的索引是通过HTTP API创建的，并且索引名称要与bucket类型绑定。一个索引可以被多个bucket使用，但一个bucket只能绑定一个索引。
# 创建一个自定义索引，指定Schema和分片数
curl -XPUT http://localhost:8098/search/index/employee_idx \
-H 'Content-Type: application/json' \
-d '{"schema": "employee_schema", "n_val": 3}'
# 将bucket绑定到索引
curl -XPUT http://localhost:8098/types/employee/buckets/profiles/props \
-H 'Content-Type: application/json' \
-d '{"props": {"search_index": "employee_idx"}}'
Schema配置是Riak Search 2.0中最需要花心思的部分。Riak自带一个_yz_default schema，采用动态字段匹配策略，几乎任何字段名都能被索引，适合快速原型验证。但生产环境强烈建议使用自定义schema，原因有二：一是动态schema会导致索引体积膨胀，大量无意义字段被建立索引浪费磁盘；二是字段类型不明确会引发查询歧义，比如把数字当字符串索引后范围查询就会失效。
自定义schema本质上就是标准的Solr schema.xml，只是需要额外添加几个Yokozuna保留字段，例如_yz_id、_yz_rk、_yz_rt等，它们分别存储唯一标识、对象键和bucket类型信息。Riak正是依赖这些内部字段将查询命中的Solr文档映射回Riak对象的。上传自定义schema的命令如下：
# 上传自定义schema curl -XPUT http://localhost:8098/search/schema/employee_schema \ -H 'Content-Type: application/xml' \ --data-binary @schema.xml
schema中字段的定义方式与标准Solr一致，例如定义一个支持中英文分词的文本字段、一个多值字段和一个日期字段，写法没有区别。需要注意的是Riak 2.0内置的Solr版本是4.7，一些新版Solr才有的 fieldType 和分词器不可用，升级Riak版本前要确认对应文档。
数据写入与查询语法详解
索引建好并绑定bucket之后，写入即可自动触发索引。Riak对象写入时，Yokozuna会根据对象的Content-Type选择解析方式：JSON对象会被解析后按字段展开索引，普通文本则整体作为内容索引，二进制对象则会尝试提取元数据。这意味着只要用JSON结构组织数据，就能获得字段级的检索能力，不需要额外开发索引逻辑。
# 写入一个会被自动索引的JSON对象
curl -XPUT http://localhost:8098/types/employee/buckets/profiles/keys/alice \
-H 'Content-Type: application/json' \
-d '{"name": "Alice Chen", "dept": "engineering", "tags": ["go", "riak"], "hire_date": "2020-03-15"}'
# 执行全文检索查询
curl "http://localhost:8098/search/query/employee_idx?wt=json&q=name:alice%20AND%20dept:engineering"
查询语法完全继承自Solr的标准查询解析器，支持布尔运算、短语匹配、通配符、模糊查询和范围查询。例如tags:riak AND hire_date:[2019-01-01 TO 2021-12-31]这样的组合查询可以直接使用。返回结果除了Solr命中文档外，还包含max_score、num_found等统计信息，客户端可以据此做分页和高亮。
有一个容易被忽视的细节：通过查询接口返回的文档字段来自Solr索引，而通过fetch接口拿到的是Riak原始对象。如果索引schema中没有存储（stored）某个字段，查询结果里就看不到它，但仍然可以用该字段过滤。设计schema时要区分哪些字段需要回显、哪些只用于过滤，这对索引体积和性能有直接影响。
一致性保障与运维调优建议
分布式系统中索引与源数据的同步永远是绕不开的话题。Riak Search 2.0采用最终一致性模型：写请求在KV层成功返回后，Solr索引的写入是异步完成的，极端情况下可能出现短暂的数据不一致窗口。为了修复这类偏差，Riak提供了AAE（Active Anti-Entropy）机制，它会周期性地比对KV数据和索引数据的哈希树，发现不一致时自动重建索引分区。
运维层面有几个实践经验值得参考。首先是资源隔离：嵌入式Solr默认占用较大的JVM堆内存，建议在riak.conf中通过search.solr.start_timeout和JVM参数调整其行为，并保证节点剩余内存足够容纳KV的缓存。其次是索引数量控制：每个索引对应一组Solr Core，索引过多会显著拉长Solr启动时间，一般建议单集群控制在几十个以内。
最后是查询性能调优。Riak的分布式查询由覆盖计划驱动，涉及分片数的配置。分片数（search_index的n_val和分片策略）决定了查询并行度，但分片过多会增加每查询的扇出开销。对于读多写少的检索场景，适当提高block容量、开启字段缓存预热，都能改善P99延迟。如果查询涉及大量聚合分析，则要清醒地认识到Solr 4.7的faceting能力有限，这类需求更适合交给专门的OLAP系统处理。
总体来看，Riak Search 2.0通过内嵌Solr实现了存储与检索的一体化，对已经使用Riak KV并且检索需求以关键字过滤、简单排序为主的团队来说是相当实用的方案。但如果业务依赖复杂的聚合分析、近实时性要求极高，或者需要最新的分析型查询能力，独立部署的专业检索引擎仍然是更合适的选择。
Riak SearchSolr分布式检索修改时间：2026-09-13 16:50:58