往期内容
先说下全文检索
全文检索很常见我理解的平时用到的很多感觉都是属于这类的只不过量有点小，量上来了需要用到一些方法对文本进行处理那就是倒排索引了。
- 例如：Coding的话最常用的String.indexof(str)或者一些集合的查找。
- 还有数据库查询常用的like等。
构建倒排索引大概需要的信息
- 索引（整个索引需要的文件信息
- 段（包含当前的一个索引分片标志，目的是用来拆分数据的；为什么要拆分数据因为需要检索的量大，还有如果要更新某个文档（索引的文件都是按照顺序写好的落盘后不能再次修改的，并且构建索引会非常的耗时，段可以进行小块更新相对来说效率更高）。可以理解为数据库的表结构
- 文档（可以理解为某个类型的里面的一个信息。例如数据库表里面的某条数据
- 域（可以理解为文档里面的信息分类，就像数据库表里面的字段），（域写入的时候可以加一些其他的内容Payload信息
- 词（词频、词偏移量);词是从域里面产生的一般对域的内容进行分词（传统的是依赖字典吧，但是现在AI处理这些会更好些，比如：纠词、同义词类的
- 查询解析（这里面也分好多东西 画了个简单的流程图
剩下要考虑的问题
- 1.数据存储、每个文件的关联
- 2.文档的删除更新（一般打标记，或者重新跑数据(demo做的时候就分配了个自增的文档号，用了个bitset标志存
- 3.段内容的合并，以及段怎么分（demo没搞这个直接一个整体
- 4.数据的压缩尽可能的节省磁盘，还得考虑加载的问题
- 5.数据查询得考虑数据结构算法类的需要查找匹配的数据
- 6.查询问题理解用户的查询意图以及他可能的出错（这个查询就感觉很难得的
- 7.打分问题，有些系统可能不需要打分(Meilisearch当时写demo的时候就没打分这个
搞了个简单的demo
- 0.没版本控制（就写了个号
- 1.索引文件的读写没加锁
- 2.索引结构式简化版本的
- 3.文件没有合并和划分
- 4.增量问题的话，知识在查询那里有个重置加载
- 5.Payload没处理
- 6.多文件操作没用事务（可采用临时文件的方式
- 7.查询加载用的读写锁
- 8.查询没搞语法简单交集(测试量小感觉很快，后面想添加个缓存)
- 9.打分准备用bm-25 基于查询出来的
- 10.词偏移量文件感觉还是很大
- 11.词频加载多线程（弃用了
- gitHub: github.com/Soap13/Soap…
- gitee: gitee.com/0X00000000/…
