Bleve代码详解
概述
Bleve是一个由Couchbase团队基于Go语言开发的索引/检索库，它支持常用的检索和索引功能，如索引、检索、过滤、排序、聚合、高亮等。Bleve包括常见的文本分析组件，且能够使用现有的K/V存储系统进行存储。Bleve具有以下主要特性：
1. 支持所有Go数据结构的索引，如JSON 、结构体、Slices、字符串等
2. 具有强大、智能的配置功能
3. 具有丰富的Field类型，如文本、数字、日期等
4. 具有丰富查询类型，如Term、短语、模糊/精确匹配、前缀、逻辑与（Conjunction）、逻辑或（Disjunction）、布尔（Boolean）、数字范围、日期范围等查询
5. 具有简单的查询语法，且能够实现复杂的查询
6. 具有丰富的接口，且能够实现功能扩展
7. 具有易用且高级API能够索引数据模型中的任何对象
8. 基于标准的TF-IDF加权评分算法
9. 支持查询匹配结果的高亮显示
10. 支持多种聚合功能(Facet)，如能够根据Term、数字范围、日期范围聚合等
11. 文本解析组件现已支持众多分析组件，支持将近二十种语言，如丹麦语、荷兰语、英国、法语、德语、泰语、土耳其语等
Bleve组件
从bleve的目录结构可以看出bleve的核心模块：
1. Analysis 分词模块
2. Document 文档模块，定义bleve内部的文档结构
3. Index 索引引擎，生成和持久化倒排索引bleve索引目前即支持KV存储也支持文件存储
4. Mapping 解析文档模块，文档按照schema的定义解析成内部使用的document
5. Registry 模块，bleve组件化注册中心
6. Search 模块，负责search的执行
一个文档的创建流程如下：
Doc -> mapping -> document ->Index -> analysis -> store
下面我们详细讲述每一个过程
Mapping
Mapping的入口：
前面也说了，bleve的组件化做的很好，这是一个接口，实例如下：
walkDocument会按照schema的定义（即docMapping）解析文档，结果保存在walkContext中。
下一段中“_all”field的处理，熟悉Elaticsearch的同学都应该知道这个的含义，这里不做过多解释，需要说明的是，bleve的_all的处理，并不是按照ES的方式，把各个field的value组成一个string再分词处理，而是直接merge各个field的分词结果。
Bleve中的schema结构如下：
这里需要特别解释的是bleve中对这个结构的解释跟ES的mapping的格式略有不同，我们看一下ES中schema的定义，如下图：
直观上看bleve的mapping的格式跟这个定义和温和，但是奇葩的是（bleve就是按照自己的逻辑解释的），bleve的mapping翻译过来是如下图的样子，这个很有意思。
从上图可以你可以对比看出其中的区别，这个在使用bleve的时候需要特别注意。
Bleve对doc的解析是基于反射处理的，被go的反射搞晕的同学可以认真阅读这部分代码，一定收益匪浅。
Document
文档经过mapping解析成bleve内部的document对象，如下图：
Bleve对文档中的field都抽象成一个Filed接口。
Bleve内部支持的数据类型包括：text，bool，number，geo，datetime。其中对于datetime，geo，number，bleve都会编码成int64的整数，然后再编码成[]byte。而对于bool类型，bleve转换成一个字节编码（‘T’，‘F’），这样所有的类型都编码成了[]byte。
大家都知道ES的mapping是定义了filed的基本类型，但是field的value可以是单值也可以是数组，bleve也支持这个特性。举个例子：
一个文档
doc: { "name":"doc",
"fields":[
{
"id":"2",
"vals":[
{"vval":"hello"}
]
},
{
"id":"3",
"vals":[
{"vval":"word"},
{"vval":"bleve"}
]
}
]
}
Mapping之后的结构：
&document.TextField{Name:name, Options:INDEXED, DV, Value: doc, ArrayPositions: []}
&document.TextField{Name:fields.id,Options: INDEXED, DV, Value: 2, ArrayPositions: [0]}
&document.TextField{Name:fields.id,Options: INDEXED, DV, Value: 3, ArrayPositions: [1]}
&document.TextField{Name:fields.vals.vval,Options: INDEXED, DV, Value: hello, ArrayPositions: [0 0]}
&document.TextField{Name:fields.vals.vval,Options: INDEXED, DV, Value: word, ArrayPositions: [1 0]}
&document.TextField{Name:fields.vals.vval,Options: INDEXED, DV, Value: bleve, ArrayPositions: [1 1]}
大家可以自行研究这里的arrayPositions的含义。
Index
Bleve目前支持两种索引引擎upsidedown和scorch（不知道为什么叫这两个名字），其中upsidedown底层是KV存储，scorch底层是文件存储。
无论是那种索引引擎，对外都提供了统一的访问接口
Upsidedown
相比于scorch，upsidedown比较简单（主要是底层的kv存储引擎复杂度被屏蔽了）。
我们这里主要看文档的写入，这是upsidedown的核心流程。
我们看看batch接口在upsidedown是如何实现的。
首先创建分词任务，放入分词队列异步处理分词，结果写入resultChan，后面会等待分词结束。
这里我们看bleve的写文档有一把读写锁，这个读写锁防止并发对同一个文档的修改，bleve没有document version，这个实现严重制约了bleve单实例的写性能（作者提出使用bleves的模式解决写性能问题，详细可以看作者的benchmark说明）。
分词的处理比较简单，代码大家可以自己查看，不难看懂，有三点要说明一下：
1. Upsidedown维护一个fieldcache，目的是维护field name到field ID的映射，规则很简单，顺序递增，先到先得（不是按照field name的字典顺序排序）。补充一点bleve在分词的时候会频繁访问这个fieldcache，测试你会发现对这个cache的访问会严重影响性能，频繁的读锁获取和释放对性能影响还是很大的。
2. Mapping定义的时候可以配置是否支持docvalue，但是在分词的时候（整个存储过程中）根本没有处理，直接忽略了。
3. Upsidedown 会为每一个文档生成一个BackIndexRow，这个可以认为是document的摘要，里面记录了wend的fields，以及每一个field的terms信息，对一个文档的更新，删除等操作都依赖这个结构，只要get这个结构，就可以知道存储的文档的所有信息（通过倒排索引没办法在指定docID的情况获得term信息）。Bleve的聚合（很简单的几个聚合功能，没办法跟ES相比）在upsidedown中也是visitor这个结构实现的。
Upsidedown的就是通过get BackIndexRow来确认一个文档是否存在。如果存在那么更新，否则新增。
这里会等待分词结果，下面会根据是否存在value区分是update还是delete操作。
这里会写入kv存储引擎。不同的数据在KV存储引擎中的编码格式如下：
Version: 保存bleve的版本，不可修改，目前是7，主要用于schema校验
key: {'v'}{0xff}
value: {version}{0xff}
Schema：schema按照field拆解后存储
key: {'f'}{field index}{0xff}. field index是按照field name字典序的方式递增获得
value: {field name}{0xff}
Term Dict : 存储倒排索引统计
key：{‘d’}{field index}{term}{docID}……
value: {term count}
Back index： 方便删除回滚
key: {'b'}{doc ID}{0xff}
value: {json term entries and store entries}
Store field：
key: {'s'}{doc ID}{0xff}{array pos index...}
value: {field type}{field value} 反序列化的时候需要
Internel： 存储一些内部临时使用的数据，比如schema
key：{'i'}{raw key}
value: {row value}
Term Freq: 存储position，freq信息
key：{'t'}{field index}{term}{0xff}{doc ID}
value: {freq}{norm}[{field index}{pos}{start}{end}{array pos len}{posindex ...}]
补充一点，upsidedown为了将来search方便，每次写入document的时候，都会统计term的数量，并merge已经存储的数量，写入存储引擎。这也导致写阻塞。
另外吐槽一点，upsidedown会在内存中维护总的文档数量，但是重启的时候它通过迭代的方式获得文档的数量，如果存储的数据量很大的话，这个过程会比较长，这一点大家需要注意。
Scorch
[后续补充]
Analysis
分词部分，bleve支持自定义分词器，注册之后就可以使用啦。Bleve提供的分词器不支持中文分词，网络上有人使用go封装了结巴中文分词，兼容bleve分词接口，可以直接拿来使用。
Bleve对number，geo，datetime也做了分词处理，它们首先都被处理成int64，然后调用numeric中的PrefixCode可以按照前缀编码，这样做的目的主要是方便范围查找。大家可以移步到document包中查看相关的逻辑。
Search
Bleve支持绝大部分ES的query，基本上所有的query都会处理成term query。
Bleve对query抽象了一个接口：
Search的入口是SearchInContext()。
1. 创建一个TopN的collector，collector会根据sort规则排序查询结果，并按照size，from保留文档集。
2. 创建searcher
3. 如果有聚合的话，创建聚合器
4. 查询文档并获得查询结果hits
5. 高亮处理
6. 根据请求中指定的fields返回实际的文档
至此我们基本清楚了bleve的执行流程和要点。
目前bleve的代码存在三个问题：
1. 代码注释不多，阅读起来比较费劲，尤其是scorch的代码，如果没有Lucene中segment相关的知识，基本上读不懂。
2. Bleve的读写性能很差，upsidedown在search的时候与scorch之间存在很大的差距（这也是为什么作者又搞了一个scorch的原因吧）
3. Bleve的代码中存在一些bug，这些bug在测试中很容易发现，说明其缺乏生产环境的大规模验证
