首页 > 代码库 > Solr4.8.0源码分析(10)之Lucene的索引文件(3)
Solr4.8.0源码分析(10)之Lucene的索引文件(3)
Solr4.8.0源码分析(10)之Lucene的索引文件(3)
1. .si文件
.si文件存储了段的元数据，主要涉及SegmentInfoFormat.java和Segmentinfo.java这两个文件。由于本文介绍的Solr4.8.0，所以对应的是SegmentInfoFormat的子类Lucene46SegmentInfoFormat。
首先来看下.si文件的格式
头部(header) | 版本(SegVersion) | doc个数(SegSize) | 是否符合文档格式(IsCompoundFile) | Diagnostics | 文件 | Footer |
- 头部：同Segment_N的头部结构相同，包括包含了Magic,CodecName,Version三部分
- 版本：生成segment的编码版本
- 大小: segment索引的documents的个数
- IsCompoundFile：是否以复合文档格式存储，如果设置1则为复合文档格式
- Diagnostics：包含一些信息可以用于debug，比如Lucene版本，OS，java version，以及生成该segment生成的方式(merge，add，addindexs)等
- 文件：该段包含了哪些文件
- Footer: codec编码的结尾，包含了检验和以及检验算法ID
上文讲到Solr4.8.0使用的是Lucene46SegmentInfoFormat(说明4.6以后.si文件并未发生变化)，那么来看下Lucene46SegmentInfoFormat的内容，从下文代码中可以看出，Lucene46SegmentInfoFormat内容很简单，只包含了一个Lucene46SegmentInfoReader和Lucene46SegmentInfoWriter实例
1 public class Lucene46SegmentInfoFormat extends SegmentInfoFormat { 2 private final SegmentInfoReader reader = new Lucene46SegmentInfoReader(); 3 private final SegmentInfoWriter writer = new Lucene46SegmentInfoWriter(); 4 5 /** Sole constructor. */ 6 public Lucene46SegmentInfoFormat() { 7 } 8 9 @Override10 public SegmentInfoReader getSegmentInfoReader() {11 return reader;12 }13 14 @Override15 public SegmentInfoWriter getSegmentInfoWriter() {16 return writer;17 }18 19 /** File extension used to store {@link SegmentInfo}. */20 public final static String SI_EXTENSION = "si";21 static final String CODEC_NAME = "Lucene46SegmentInfo";22 static final int VERSION_START = 0;23 static final int VERSION_CHECKSUM = 1;24 static final int VERSION_CURRENT = VERSION_CHECKSUM;25 }
顾名思义，Lucene46SegmentInfoReader负责了对.si文件的读，Lucene46SegmentInfoWriter负责了对.si文件的写
1 public SegmentInfo read(Directory dir, String segment, IOContext context) throws IOException { 2 //获取segment的.si文件名 3 final String fileName = IndexFileNames.segmentFileName(segment, "", Lucene46SegmentInfoFormat.SI_EXTENSION); 4 //打开.si文件，获取文件信息，并检查检验和 5 final ChecksumIndexInput input = dir.openChecksumInput(fileName, context); 6 boolean success = false; 7 try { 8 //检查header，并返回编码版本 9 int codecVersion = CodecUtil.checkHeader(input, Lucene46SegmentInfoFormat.CODEC_NAME,10 Lucene46SegmentInfoFormat.VERSION_START,11 Lucene46SegmentInfoFormat.VERSION_CURRENT);12 //获取版本 13 final String version = input.readString();14 //获取documents个数15 final int docCount = input.readInt();16 if (docCount < 0) {17 throw new CorruptIndexException("invalid docCount: " + docCount + " (resource=" + input + ")");18 }19 //是否复合文档格式20 final boolean isCompoundFile = input.readByte() == SegmentInfo.YES;21 //获取segemnt额外的信息22 final Map<String,String> diagnostics = input.readStringStringMap();23 //获取segment包含的文件24 final Set<String> files = input.readStringSet();25 //获取Footer(检验和以及ID)26 if (codecVersion >= Lucene46SegmentInfoFormat.VERSION_CHECKSUM) {27 CodecUtil.checkFooter(input);28 } else {29 CodecUtil.checkEOF(input);30 }31 //将从.si获取到的segment信息写入SegmentInfo中32 final SegmentInfo si = new SegmentInfo(dir, version, segment, docCount, isCompoundFile, null, diagnostics);33 si.setFiles(files);34 35 success = true;36 37 return si;38 39 } finally {40 if (!success) {41 IOUtils.closeWhileHandlingException(input);42 } else {43 input.close();44 }45 }46 }
Lucene46SegmentInfoReader是读取.si文件并生成Segmentinfo，那么可想而知Lucene46SegmentInfoWriter是将Segmentinfo信息写入.si文件中
1 public void write(Directory dir, SegmentInfo si, FieldInfos fis, IOContext ioContext) throws IOException { 2 //将要生成的.si的文件名 3 final String fileName = IndexFileNames.segmentFileName(si.name, "", Lucene46SegmentInfoFormat.SI_EXTENSION); 4 //将.si文件加入文件列表中 5 si.addFile(fileName); 6 //生成.si文件 7 final IndexOutput output = dir.createOutput(fileName, ioContext); 8 9 boolean success = false;10 try {11 //写入文件头header12 CodecUtil.writeHeader(output, Lucene46SegmentInfoFormat.CODEC_NAME, Lucene46SegmentInfoFormat.VERSION_CURRENT);13 // Write the Lucene version that created this segment, since 3.114 //写入version15 output.writeString(si.getVersion());16 //写入documents个数17 output.writeInt(si.getDocCount());18 //写入是否复合文档个数19 output.writeByte((byte) (si.getUseCompoundFile() ? SegmentInfo.YES : SegmentInfo.NO));20 //写入segment 额外的信息21 output.writeStringStringMap(si.getDiagnostics());22 //写入segment包含的文件23 output.writeStringSet(si.files());24 //写入footer 检验和以及ID25 CodecUtil.writeFooter(output);26 success = true;27 } finally {28 if (!success) {29 IOUtils.closeWhileHandlingException(output);30 si.dir.deleteFile(fileName);31 } else {32 output.close();33 }34 }35 }
在Segmentinfo有个tostring()函数，当我们将solr的日志等级设置为debug时候，它会打印出.si的信息。比如它打印出"_a(3.1):c45/4"，可以从中看出以下几个信息：
1. _a 是segment名字
2. (3.1)表示Lucene版本，如果出现?表示未知
3. c 表示复合文档格式，C表示非复合文档格式
4. 45 表示segment具有45个documents
5. 4 表示删除的documents个数
2. .fnm文件(域元数据文件)
前面讲的都是以segment为单位的，现在起开始学习segment的细分结构。首先学习的是.fnm(域元数据文件)，它存储了segment内域的相关信息。
首先学习下.fnm的文件结构：
Header,FieldsCount, <FieldName,FieldNumber, FieldBits,DocValuesBits,DocValuesGen,Attributes> FieldsCount,Footer
- Header： 同前文
- FieldsCount：域的个数
- <FieldName,FieldNumber, FieldBits,DocValuesBits,DocValuesGen,Attributes> FieldsCount： 包含FieldsCount个域的信息
- FieldName：域名
- FieldNumber：域的编号，不同与先前版本的域的编码是按在文件中的顺序编码，现在版本的域的编码是明确的。
- FieldBits： 一系列标志位，表明对此域的索引方式
- 最低位：1表示此域被索引，0则不被索引。所谓被索引，也即放到倒排表中去。
- 仅仅被索引的域才能够被搜到。
- Field.Index.NO则表示不被索引。
- Field.Index.ANALYZED则表示不但被索引，而且被分词，比如索引"hello world"后，无论是搜"hello"，还是搜"world"都能够被搜到。
- Field.Index.NOT_ANALYZED表示虽然被索引，但是不分词，比如索引"hello world"后，仅当搜"hello world"时，能够搜到，搜"hello"和搜"world"都搜不到。
- 一个域出了能够被索引，还能够被存储，仅仅被存储的域是搜索不到的，但是能通过文档号查到，多用于不想被搜索到，但是在通过其它域能够搜索到的情况下，能够随着文档号返回给用户的域。
- Field.Store.Yes则表示存储此域，Field.Store.NO则表示不存储此域。
- 第二最低位：1表示保存词向量，0为不保存词向量。
- Field.TermVector.YES表示保存词向量。
- Field.TermVector.NO表示不保存词向量。
- 第三最低位：1表示在位置列表中保存偏移量信息。
- 第四最低位：没用
- 第五最低位：1表示不保存标准化因子
- Field.Index.ANALYZED_NO_NORMS
- Field.Index.NOT_ANALYZED_NO_NORMS
- 第六最低位：是否保存payload
- 第七最低位：1表示不保存词的频率以及位置信息
- 第八最低位：不保存位置信息
- 最低位：1表示此域被索引，0则不被索引。所谓被索引，也即放到倒排表中去。
- DocValuesBits：一个字节表示DocValues的类型，低4位表示DocValues类型，高4位表示标准类型
- DocValuesGen：DocValues的版本信息，如果该值为-1表示没有更新DocValues，大于0表示有更新
- Attributes： 同前文
- Footer：同前文
要了解域的元数据信息，还要了解以下几点：
- 位置(Position)和偏移量(Offset)的区别
- 位置是基于词Term的，偏移量是基于字母或汉字的。
- 索引域(Indexed)和存储域(Stored)的区别
- 一个域为什么会被存储(store)而不被索引(Index)呢？在一个文档中的所有信息中，有这样一部分信息，可能不想被索引从而可以搜索到，但是当这个文档由于其他的信息被搜索到时，可以同其他信息一同返回。
- 举个例子，读研究生时，您好不容易写了一篇论文交给您的导师，您的导师却要他所第一作者而您做第二作者，然而您导师不想别人在论文系统中搜索您的名字时找到这篇论文，于是在论文系统中，把第二作者这个Field的Indexed设为false，这样别人搜索您的名字，永远不知道您写过这篇论文，只有在别人搜索您导师的名字从而找到您的文章时，在一个角落表述着第二作者是您。
- payload的使用
- 我们知道，索引是以倒排表形式存储的，对于每一个词，都保存了包含这个词的一个链表，当然为了加快查询速度，此链表多用跳跃表进行存储。
- Payload信息就是存储在倒排表中的，同文档号一起存放，多用于存储与每篇文档相关的一些信息。当然这部分信息也可以存储域里(stored Field)，两者从功能上基本是一样的，然而当要存储的信息很多的时候，存放在倒排表里，利用跳跃表，有利于大大提高搜索速度。
- Payload的存储方式如下图：
- Payload主要有以下几种用法：
- 存储每个文档都有的信息：比如有的时候，我们想给每个文档赋一个我们自己的文档号，而不是用Lucene自己的文档号。于是我们可以声明一个特殊的域(Field)"_ID"和特殊的词(Term)"_ID"，使得每篇文档都包含词"_ID"，于是在词"_ID"的倒排表里面对于每篇文档又有一项，每一项都有一个payload，于是我们可以在payload里面保存我们自己的文档号。每当我们得到一个Lucene的文档号的时候，就能从跳跃表中查找到我们自己的文档号。
- 影响词的评分
- 在Similarity抽象类中有函数public float scorePayload(byte [] payload, int offset, int length) 可以根据payload的值影响评分。
同.si文件相同，.fnm同样有Lucene46FieldInfosFormat(包含Lucene46SegmentInfoReader，Lucene46FieldInfosWriter)，以及FieldInfo
看下Lucene46SegmentInfoReader读取.fnm文件部分代码，Lucene46FieldInfosWriter内容差不多就不再介绍。
1 public FieldInfos read(Directory directory, String segmentName, String segmentSuffix, IOContext context) throws IOException { 2 //获取文件名 3 final String fileName = IndexFileNames.segmentFileName(segmentName, segmentSuffix, Lucene46FieldInfosFormat.EXTENSION); 4 //读取.fnm文件并检查检验和 5 ChecksumIndexInput input = directory.openChecksumInput(fileName, context); 6 7 boolean success = false; 8 try { 9 //header信息10 int codecVersion = CodecUtil.checkHeader(input, Lucene46FieldInfosFormat.CODEC_NAME, 11 Lucene46FieldInfosFormat.FORMAT_START, 12 Lucene46FieldInfosFormat.FORMAT_CURRENT);13 //域数量14 final int size = input.readVInt(); //read in the size15 FieldInfo infos[] = new FieldInfo[size];16 17 for (int i = 0; i < size; i++) {18 //域名19 String name = input.readString();20 //域编码21 final int fieldNumber = input.readVInt();22 //获取FieldBits 域的所有方式23 byte bits = input.readByte();24 //是否索引 &0000000125 boolean isIndexed = (bits & Lucene46FieldInfosFormat.IS_INDEXED) != 0;26 //是否保存字段的向量 &0000001027 boolean storeTermVector = (bits & Lucene46FieldInfosFormat.STORE_TERMVECTOR) != 0;28 //是否保存标准化因子 &0001000029 boolean omitNorms = (bits & Lucene46FieldInfosFormat.OMIT_NORMS) != 0;30 //是否保存playload &0010000031 boolean storePayloads = (bits & Lucene46FieldInfosFormat.STORE_PAYLOADS) != 0;32 final IndexOptions indexOptions;33 if (!isIndexed) {34 indexOptions = null;35 //不保存字段的频率以及位置信息 &0100000036 } else if ((bits & Lucene46FieldInfosFormat.OMIT_TERM_FREQ_AND_POSITIONS) != 0) {37 //只有当域是可以被索引时，该值才能设1，38 indexOptions = IndexOptions.DOCS_ONLY;39 //不保存位置信息，&1000000040 } else if ((bits & Lucene46FieldInfosFormat.OMIT_POSITIONS) != 0) {41 //索引文档以及字段频率，禁止位置信息42 indexOptions = IndexOptions.DOCS_AND_FREQS;43 //是否在位置列表中保存偏移量信息44 } else if ((bits & Lucene46FieldInfosFormat.STORE_OFFSETS_IN_POSTINGS) != 0) {45 //索引文档，频率，位置以及偏移信息46 indexOptions = IndexOptions.DOCS_AND_FREQS_AND_POSITIONS_AND_OFFSETS;47 } else {48 //索引文档，频率以及位置信息。这是全文检索的默认情况，支持评分以及位置查询49 indexOptions = IndexOptions.DOCS_AND_FREQS_AND_POSITIONS;50 }51 52 // DV Types are packed in one byte53 //获取DocValuesBits54 byte val = input.readByte();55 //低4位表示DocValues类型 56 final DocValuesType docValuesType = getDocValuesType(input, (byte) (val & 0x0F));57 //高4位表示标准类型58 final DocValuesType normsType = getDocValuesType(input, (byte) ((val >>> 4) & 0x0F));59 //DocValues的版本代号60 final long dvGen = input.readLong();61 final Map<String,String> attributes = input.readStringStringMap();62 //将读取的域信息存在FiledInfo里面63 infos[i] = new FieldInfo(name, isIndexed, fieldNumber, storeTermVector, 64 omitNorms, storePayloads, indexOptions, docValuesType, normsType, Collections.unmodifiableMap(attributes));65 infos[i].setDocValuesGen(dvGen);66 }67 //添加Footer68 if (codecVersion >= Lucene46FieldInfosFormat.FORMAT_CHECKSUM) {69 CodecUtil.checkFooter(input);70 } else {71 CodecUtil.checkEOF(input);72 }73 FieldInfos fieldInfos = new FieldInfos(infos);//将所有的域信息存放到FieldInfos里面74 success = true;75 return fieldInfos;76 } finally {77 if (success) {78 input.close();79 } else {80 IOUtils.closeWhileHandlingException(input);81 }82 }83 }84 85 private static DocValuesType getDocValuesType(IndexInput input, byte b) throws IOException {86 if (b == 0) {87 return null;88 } else if (b == 1) {89 return DocValuesType.NUMERIC; //每一个document都是数字类型。90 } else if (b == 2) {91 return DocValuesType.BINARY; //每一个document都是byte[]类型。值可能大于32766bytes，根据codec不同最大值不同。92 } else if (b == 3) {93 return DocValuesType.SORTED; //该byte[]类型，存放按前缀后缀规则，所有值进行排序，只存放不同的那部分，值小于32766bytes94 } else if (b == 4) {95 return DocValuesType.SORTED_SET;//set<byte[]>类型96 } else {97 throw new CorruptIndexException("invalid docvalues byte: " + b + " (resource=" + input + ")");98 }99 }
尽管上述的代码比较简单，但是具体的对DocValue的概念仍然不是在熟悉，所以去找了下关于DocValue的一些信息
3. DocValue
说实话，公司的项目中并未用到DocValue这个东西，之前只知道有这个配置项在Schema.xml里面，并未引起关注，直到现在源码上看到这个东西才想去学习下。DocValue是Solr4.2加入的特性，那么为什么要DocValue？
3.1 Solr中的使用
Solr标准的索引方式是反向索引，它将所有在Document里找到的term放到一起组成一个链表，而每一个term后面又跟着一个term出现过的document的链表以及出现过的次数。在上面的图中显示其原理。这是查询非常迅速，当用户查询某一个term时，已经有准备好的term到document的映射表了。
但是当涉及到sorting(排序), faceting(面搜索), and highlighting(以及高亮)逆向索引就变得不是那么高效了。比如faceting查询，首先得找出每一个document中出现的每一个term，然后使得每一个docID进行排序然后放入faceting list里面。对于Solr来说，这些是在内存中进行的，当document以及term多的时候，就会变得比较慢。
因此在Lucene4.2里引入了DocValue，它是行导向的结构，在建索引的时候形成document到term的映射，它使得aceting, sorting, and grouping 查询更加快速。
要使用它得在schema.xml上设置：
<field name="manu_exact" type="string" indexed="false" stored="false" docValues="true" />
DocValue只对一些特定的类型有效，比如：
- StrField这种String类型
- 如果field类型是single-valued(也就是multi-valued是false)，Lucene就会使用SORTED类型
- 如果filed类型是multi-valued，Lucene就会使用SORTED_SET类型
- Trie* fields 类型
- 如果field类型是single-valued(也就是multi-valued是false)，Lucene就会使用NUMERIC类型
- 如果filed类型是multi-valued，Lucene就会使用SORTED_SET类型
DocValue具有以下优点以及缺点
- 近实时索引：在每一个索引段里面都会有一个docvalues数据结构，这个结构与索引同时建立，并且能够快速更新、生效；
- 基本的查询和过滤支持：你可以做基本的词、范围等基本查询，但是不参与评分，并且速度较慢，如果你对速度和评分排序有要求，你可以讲该字段设置为（indexed=”true”）
- 更好的压缩比: Docvalues fields 的压缩效果比 fieldcache好，但不强调做到极致。
- 节约内存：你可以定义一个fieldType的 docValuesFormat (docValuesFormat="Disk")，这样的只有一小部分数据加载到内存，其它部分保留在磁盘上。
- 对于静态存储的数据查询提升不明显
3.2 DocValue原理
Lucene有四个基础字段类型可以使用docvalues。目前Solr使用了其中三种:
- NUMERIC：每一个文档里面只有一个这样类型的单值字段。这就像在整个索引里有一个很大的long[]，数据基于实际使用的值经过压缩的。
例如，假设有3个这样的文档：
doc[0] = 1005
doc[1] = 1006
doc[2] = 1005
在这个例子中，每个文档仅需要一个bit。
- SORTED：每一个文档里面有一个这样类型的单值字段。这就像在整个索引里有一个很大的String[]， 但用的是不同的寻址方式。.每一个唯一的value被赋予一个数字代表其顺序。所以每个文档只是记录一个压缩后的整数，有字典来还原他们原来的词。
例如，假设有3个这样的文档：
doc[0] = “aardvark”
doc[1] = “beaver”
doc[2] = “aardvark”
值 “aardvark” 被映射成0，”beaver”映射成1, 建立两个数据结构如下：
doc[0] = 0
doc[1] = 1
doc[2] = 0
term[0] = “aardvark”
term[1] = “beaver”
- SORTED_SET: 每个文档里面有一个string类型的多值字段。这个和SORTED类型比较相似，每个文档有一个value的”set”。(按照递增存储)。 这里刻意的去除了重复的value，并且忽略了原有value的排序。
例如，假设有3个这样的文档：
doc[0] = “cat”, “aardvark”, “beaver”, “aardvark”
doc[1] =
doc[2] = “cat”
值 “aardvark” 被映射成0，”beaver”映射成1, “cat”映射成2，建立两个数据结构如下：
doc[0] = [0, 1, 2]
doc[1] = []
doc[2] = [2]
term[0] = “aardvark”
term[1] = “beaver”
term[2] = “cat”
- BINARY: 每个文档存在一个 byte[] array。这个编码及数据结构可以由用户自定义。
Solr4.8.0源码分析(10)之Lucene的索引文件(3)
声明：以上内容来自用户投稿及互联网公开渠道收集整理发布，本网站不拥有所有权，未作人工编辑处理，也不承担相关法律责任，若内容有误或涉及侵权可进行投诉： 投诉/举报 工作人员会在5个工作日内联系你，一经查实，本站将立刻删除涉嫌侵权内容。