Caprice：Golang版的高性能实时全文检索引擎.pdfVIP

Caprice：Golang版的⾼性能实时全⽂检索引擎 承接前⽂ 如何构建实时全⽂检索引擎，这⾥主要回顾我们如何打造⾼性能的实时全⽂检索引擎。当然这个项⽬还在持续开发优化中。 Caprice是在开源的全⽂检索引擎bleve的基础上，对存储层进⾏深度改造，进⽽获得⾼性能。同时更为重要的是，这款检索引擎是⽀持实时检索 和⾮实时检索。 这⾥再简单介绍⼀下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底层有两个检索引擎：upsidedown和scorch。这两个引擎我曾在之前的⽂章中均有介绍。upsidown是以KV的⽅式存储倒排索 引，scorch是以segment的⽅式，以FST存储倒排索引。⽬前upsidown基本上不会再新增新的特性，只修复bug。 总体上来说，bleve存在如下缺点 ： 1. 写吞吐很差。upsidown的写吞吐⼤约是2000+ （document⼤⼩不同，测试数据不同）。scorch的写吞吐就更差了，只有100+。同时写的 吞吐不稳定，抖动很明显。 2. 对docvalues⽀持的很差，存在⼤量的多余数据，导致存储臃肿。 3. 对聚合⽀持很有限。 4. 磁盘压缩效率低下，占⽤磁盘空间⼤ 5. 不⽀持filter，仅⽀持query 6. 不⽀持document的version。 具体到底层存储，吐槽⼀下。 upsidedown ：对数字的倒排存储查询效率很低，原因在于为了⽀持数字的range query，bleve参考lucene早期版本的做法，采⽤前缀编码的 ⽅式处理了数字，⼤致的结果就是会产⽣⼀系列不同前缀的term，举例说明 ：⼀个数字123，它会分解成 1 （2），12 （1），123 （0），括号 中的数字就是前缀码，这样 1 （2）和1 （0）是不⼀样的。数字的range query的时候，会找到公共的前缀term，⽐如198 ～ 301， 那么只需要 term 198 （0），199 （0），2 （2），300 （1）， 301 （0）即可完成范围查找。但是如果是⼀个范围⽐较⼤的range query，中间的公共前 缀term包含的docID列表就会很⼤，对于upsidedown，所有的倒排索引都是以kv的⽅式存储的，这样这个前缀查询就会遍历⼤量的冗余的kv造 成查询性能下降。 upsidedown的另⼀个⼤问题就是写吞吐很不稳定，因为底层采⽤kv存储，很多的kv存储引擎都是LSM架构，导致compaction严重消耗CPU和 磁盘IO，导致写吞吐不稳定。另⼀⽅⾯upsidedown再设计term count的时候依赖kv提供的merge接⼝，这个接⼝基本上lock当下的写，这样导 致写的性能不能提升。 scorch ：scorch的整体设计思路是借鉴了lucene的设计，采⽤segment的⽅式保存倒排索引，但是bleve的索引的定位是实时检索，导致 scorch必须是每次写提交都要⽴即⽣成⼀个segment，尽管这个segment只包含⼀个⽂档，然后后台不断merge这些⼩的segment。scorch 的写逻辑，⽼实讲我没有特别看懂，⾄少代码逻辑很不清晰，最致命的是它的吞吐太低了，只有100+，并且会因为merge⽽出现卡顿（⼤约2秒 钟，程序设定），这严重不能接受。scorch中stored field，docvalue，term dict存储在⼀个⽂件中，整个写segment的逻辑复