# tantivy_test

**Repository Path**: rust_full_text_search/tantivy_test

## Basic Information

- **Project Name**: tantivy_test
- **Description**: 尝试深度使用tantivy，来进行全文检索功能，可以借鉴quickwit/Toshi的思路来做分布式扩展
- **Primary Language**: Unknown
- **License**: Not specified
- **Default Branch**: master
- **Homepage**: None
- **GVP Project**: No

## Statistics

- **Stars**: 0
- **Forks**: 0
- **Created**: 2022-07-13
- **Last Updated**: 2022-07-19

## Categories & Tags

**Categories**: Uncategorized

**Tags**: None

## README

# tantivy_test

#### 介绍
这是一个对tantivy进行深度工程化使用的草稿，目前单机性能如下：


磁盘IO: 700 MBps 8000 tps

cpu：30个

启动命令：

cargo build --release -j 30 && rm -fr ./data && mkdir ./data && taskset -c 1-64  ./target/release/tantivy_test -r 50  -b  100 -n 50000 -a 10000000000 -p 500 -m 1000000000 -i 5  -o 20000 --trans_task 3 --index_task 3 --feed_size 1 --dir ./data


目前来看，能实时支持6Gbps流量的在线建索引存储。


说一些感受：

我基本上快速读了tantivy的框架代码和部分细节，总体而言抽象的还是不错的，尤其是对Directory的抽象，方便进行io存储方面的扩展。

分词算法也算比较丰富，simple、ngram等，多语言支持也丰富。也有比较丰富的查询模式，查询语法比较人性化易用。

个人觉得有待改进的方面：
1. 有Directory方面的抽象，方便进行io方面的扩充。但是没有基于Segment 分词方面的抽象，不利于分词处理扩展。

2. 没有不同index之间merge的能力，当然这个也可以比较方便的自己添加。

3. 有很多工程调优参数，尤其是在实际使用的时候。我用的时候，发现这些工程调优参数对最终性能影响很大，所以不得不去读了他的源码。

后续实用性能提升方面的一些建议：

1. IndexWriter的add_document最好建立大量异步任务来做，不要主线程阻塞

2. IndexWriter的一次add_document调用，Document的len建议值为100

3. IndexWriter commit频率一定要低

4. 不要频繁的建立大量Index，那样性能并不高，而且查询的时候也不方便，要通过上面1的方式来提升性能。

5. bytes类型数据不支持查询，如果需要，建议转换成txt再存，我就是把流量里面的payload转换成utf8再入成txt，提供全文检索能力。
   目前我用的是简单的utf8转换函数，后续可以SIMD utf8进行转换提速。