Solr服务器的核心：它究竟存储着什么？
当你登录Solr的管理界面，面对那些令人眼花缭乱的统计数字和列表，或是在命令行中调用curl查询索引状态时，心中是否曾掠过一丝疑惑：这个强大搜索平台的核心深处，究竟安放着什么？Solr服务器看似一个整体，却远非单纯的文件仓库；它内部所存储的内容，是经过精密组织与转化后的数据精华——一个为了光速检索而精心构筑的智慧结构。
原始文档的栖息地：数据的基石
Solr的起点，是你交给它的原始信息，这些文档并非以其原生形态（如Word、PDF）直接存储，而是经历了一次关键的“结构化”蜕变：
文档与字段的转化 当你通过HTTP POST请求将一份JSON文档发送给Solr时：
{
"id": "book_001",
"title": "深入理解Solr",
"author": "技术达人",
"publish_year": 2023,
"content": "本书详细探讨了Solr的索引机制、查询处理...",
"category": ["搜索技术", "后端开发"]
} 这份文档就被解析、拆解，每个键（id,title,author等）成为一个独立的字段（Field），其对应的值则被填充进去，Solr的存储单元，本质上就是由这些字段及其值构成的记录集合。
模式定义的核心地位schema.xml或托管模式（Managed Schema）是Solr存储的蓝图，它严格定义了：
字段名称 如title,author。
字段类型 如string,text_general,pint (整数),pdate (日期)，类型决定了如何解析、分析和索引数据（text_general字段会被分词器分解成更小的词元）。
字段属性
indexed是否生成倒排索引？可搜索字段必须为true。
stored原始值是否原样保存在磁盘上？需要返回原始内容（如文档预览）的字段必须为true。
docValues是否为该字段生成基于列式存储的docValues？这对高效的排序、分面、分组、函数查询至关重要。
multiValued该字段是否允许存储多个值（如category 字段）？
唯一键 指定哪个字段（通常是id）作为文档的唯一标识符，确保文档的精确更新和删除。
存储的意义 当字段属性stored=”true” 时，该字段的原始输入值会被压缩后原封不动地写入磁盘上的特定文件（如.fdt 和.fdx 文件），这就是为什么执行查询后，Solr能够向你返回文档中stored=true字段的原始内容，想象一个巨大的图书馆，每一本书的原始完整内容都被妥善保存，但为了快速查找，图书馆同时维护着无数张卡片索引。
倒排索引：光速搜索的引擎室
这是Solr强大搜索能力的核心奥秘所在，如果原始存储文档是图书馆的藏书本身，那么倒排索引就是那套无比详尽、按词条组织的卡片目录系统。
核心概念 倒排索引颠覆了“文档->包含的词”的正向思维，它建立的是“词->包含该词的文档列表”的逆向映射。
构建过程
1.分词与分析： 对于标记为indexed=true 的文本字段（如title,content），Solr会调用配置好的分析链（Tokenizer + Filters）。“深入理解Solr” 可能被分词器拆分成["深入", "理解", "solr"]，再经过小写过滤器变成["深入", "理解", "solr"]。
2.形成词项： 分析链输出的最终结果称为词项（Term）。“solr” 就是一个词项。
3.创建倒排列表： 对于每个词项，Solr记录：
文档ID列表 包含该词项的所有文档的唯一ID。
词频 该词项在每个文档中出现的次数（TF - Term Frequency），用于相关性评分。
位置信息 该词项在每个文档中出现的位置（用于短语查询、高亮等）。
其他信息 如偏移量（用于高亮）、payload（携带额外信息）等。
物理存储 倒排索引主要存储在：
*.tip词项索引文件（Term Index），可以理解为指向倒排列表入口的快速查找表，常驻内存以加速访问。
*.tim词项字典文件（Term Dictionary），存储了实际的词项以及指向倒排列表的指针。
*.doc倒排列表文件（Postings List），存储文档ID列表、词频等信息。
*.pos位置信息文件（Positions），存储词项在文档中出现的位置。
*.pay载荷信息文件（Payloads），存储与词项位置关联的额外二进制数据。
搜索如何发生 当用户搜索“Solr 原理”时：
1. 查询解析器将查询分解成词项solr 和原理。
2. 通过*.tip 和*.tim 快速找到solr 和原理 对应的倒排列表在*.doc 文件中的位置。
3. 读出包含solr 的文档ID列表（DocSet A）和包含原理 的文档ID列表（DocSet B）。
4. 根据查询逻辑（默认AND）求交集（DocSet A ∩ DocSet B），得到同时包含两个词项的候选文档ID列表。
5. 利用*.pos 文件检查这些文档中solr 和原理 的位置是否满足短语查询的要求（如果查询是短语）。
6. 计算每个候选文档的相关性得分（利用TF、IDF、字段权重、长度归一化等）。
7. 按得分排序，返回Top N结果。
8. 对于需要返回原始内容的字段（stored=true），从.fdt/.fdx 文件中读取对应文档ID的字段值。
DocValues：结构化操作的加速器
虽然倒排索引为文本搜索提供了无与伦比的速度，但它对于需要遍历所有文档的字段（如按价格排序、按品牌分面统计）效率较低。DocValues 应运而生：
列式存储 与按行存储原始文档 (stored) 或为搜索优化的倒排索引不同，DocValues 是按字段（列）组织的，它将一个字段的所有值集中存储在一起。
生成机制 在索引文档时，如果字段设置了docValues=true，Solr会额外为该字段构建DocValues 结构，常见类型包括：
NumericDocValues 用于数值字段（整数、浮点数、日期）。
SortedNumericDocValues 用于多值数值字段。
SortedSetDocValues 用于多值字符串字段（通常用于分面）。
BinaryDocValues 用于存储原始字节（如编码后的地理位置）。
物理存储 通常以.dvd (数据) 和.dvm (元数据) 文件形式存在。
核心优势
高效排序 按字段排序时，只需顺序读取该字段的DocValues 数据，速度极快。
快速分面 计算字段不同值及其出现次数（分面）时，遍历列式数据比使用倒排索引高效得多。
高效分组 按字段值分组聚合结果。
函数查询 在评分公式中引用字段值（如product(popularity, 0.1)）。
与存储的关系DocValues 存储的是字段的值（可能经过编码或排序），但通常不存储完整的原始输入（如长文本），它服务于聚合和排序等操作，而非返回完整的原始字段内容。
分布式世界：SolrCloud的存储版图
当Solr以SolrCloud模式运行时，其存储机制被赋予了分布式特性，实现水平扩展和高可用：
Collection与Shard 一个大的索引（称为Collection）被水平分割成多个逻辑分片（Shard），每个分片包含整个索引数据的一个子集，查询会自动路由到所有分片并汇总结果。
Replica 每个分片有多个副本（Replica），它们存储完全相同的分片数据，副本分布在不同的物理节点上，提供高可用性（一个节点宕机，其他副本可服务）和负载均衡（查询可分发到不同副本）。
ZooKeeper 作为协调者，存储和管理SolrCloud的关键元数据：
集群状态 所有Collections、Shards、Replicas的定义、状态（active, down等）和位置（在哪个节点上）。
配置集schema.xml,solrconfig.xml 等配置文件上传到ZooKeeper，统一下发到所有相关节点。
选举协调 帮助每个分片选举出一个Leader副本来处理写请求。
节点存储 每个Solr节点（物理机或容器）上运行的Solr实例（JVM进程），负责管理分配给它的一个或多个Replica，每个Replica在其本地文件系统中拥有自己独立且完整的一套索引文件：
* 该Replica所属分片的数据（倒排索引、stored字段、docValues等）。
* 事务日志（见下文）。
* 该Replica自身的配置缓存。
守护者：事务日志（tlog）
它是数据安全的最后一道坚固防线，确保写入的持久性和一致性：
写入缓冲机制 当文档通过HTTP请求到达Solr节点时，并不会立即修改磁盘上的索引文件，为了最大化吞吐量，文档首先被写入一个内存缓冲区。
日志先行 在文档被写入内存缓冲区之前，（或包含足够信息以重建操作的数据）会立即追加写入到事务日志文件（通常是tlog. 文件），这个操作是顺序追加写入，速度很快。
持久化保证 只有在文档成功写入事务日志后，Solr才会向客户端确认写入成功，这保证了即使服务器突然断电或崩溃，已经确认成功的写入操作也不会丢失，因为日志在磁盘上。
恢复与重放 当Solr实例（或整个节点）重启时，它会检查事务日志，如果发现上次关闭时有未提交到主索引的内存缓冲区数据（或者主索引需要恢复），Solr会读取事务日志文件，并将其中记录的更新操作重新执行（重放），将数据恢复到崩溃前的状态，确保数据完整性。
软提交与硬提交
软提交 (softCommit) 将内存缓冲区中的更改使其对搜索可见（刷新Searcher），这很快，但不保证更改已持久化到主索引文件（依赖于事务日志），通常用于需要近实时搜索的场景。
硬提交 (hardCommit) 将内存缓冲区中的更改强制写入磁盘上的主索引文件，并截断（或滚动） 当前的事务日志（新的写入会开始使用新的事务日志文件），这保证了数据的持久性，但开销更大。autoCommit 设置控制硬提交的策略。
配置与元数据：系统的灵魂
驱动Solr存储和行为的规则与信息同样存储在服务器上：
配置文件 (solrconfig.xml,schema.xml 等)
* 定义索引和查询处理的行为（缓存大小、请求处理器、监听器、分词器链、索引管理策略、提交策略、复制设置等）。
* 在非Cloud模式下，通常存储在实例的conf/ 目录下。
* 在SolrCloud模式下，上传到ZooKeeper集中管理，由ZooKeeper分发到各节点。
核心元数据 (core.properties) 每个Solr Core（一个独立的索引实例）都有一个core.properties 文件，定义了Core的名称、所属的Collection/Shard、数据目录位置、配置集名称等基本信息。
索引元数据 索引本身包含元数据，如版本号、生成时间、字段统计信息（最大最小值等，用于优化查询）、段信息等，通常存储在segments_ 文件中。
Solr存储的智慧图谱
Solr服务器远非一个简单的文件柜，它内部存储的是一个高度结构化、深度优化、相互关联的数据生态系统：
1、结构化文档： 按模式定义的字段及其stored 值，是原始信息的存档库。
2、倒排索引： 从stored 文档中提取、分析、转化而成的词项到文档的映射网络，是毫秒级文本搜索的涡轮引擎，其文件（.tim,.doc,.pos等）是搜索速度的直接来源。
3、DocValues： 按字段组织的列式结构（.dvd,.dvm），是排序、分面、分组等结构化操作的专用高速通道。
4、分布式架构： 在SolrCloud中，数据被分片（Shard）并复制（Replica），每个副本拥有完整分片数据的独立存储集，ZooKeeper则存储着整个分布式集群的地图与规则（集群状态、配置）。
5、事务日志 (tlog)： 所有写入操作的预写日志，是数据持久性和崩溃恢复的生命线。
6、配置与元数据： 驱动整个系统运行和定义数据形态的规则与信息（solrconfig.xml,schema.xml,core.properties, 索引元数据）。
理解Solr存储的内容，就是理解其强大搜索能力的底层逻辑，它并非简单地保存你的数据，而是将其转化为一个为瞬间检索而生的、精密且高效的结构化宇宙，每一次搜索请求的瞬间响应，背后都是这个复杂系统各司其职、紧密协作的成果——从原始文档的解析存储，到索引结构的快速定位，再到分布式节点的协同计算，当你再次面对Solr的管理界面，那些跳动的数字和列表将不再神秘，它们正是这个智慧存储引擎精准运作的实时脉搏，沉默而有力地支撑着每一次精准查询背后的技术奇迹。
文章摘自：https://idc.huochengrm.cn/js/12502.html
评论