Andeya
Andeya
确实，我现在已经把悟空用到项目中了，不过做了很大的改动，其中就有core中对接数据库的改造，直接存储反向索引文档，节约内存，也节约初始化时间。
创建两个公共变量，一个反向索引列表的，一个文档评分字段的，在索引器、排序器初始化时，将指针赋给对应字段，大致是这个思路，当然原来的持久化存储那一套要全部去掉。
嗯，因为我把悟空写进了我这边的一个核心架构中，涉及一小部分业务方面的东西，不能独立使用，所以就没更上去
今天我根据作者的最新源码，改个较完美版本，提交上来吧
https://github.com/henrylee2cn/wukong 这个版本是在官方最新源码基础上改进的： 1. 持久化存储对象，从原始文档改为反向索引文档与文档评分字段，从而避免程序重启后，需要重新分词、索引的麻烦； 2. 将持久数据库分片数与索引器、排序器的分片数保持一致，即实现一一对应关系，从而保证从数据库可以完美恢复； 3. 依然存在的问题：悟空采用的这两中KV数据库，读写速率太慢，严重拖累高并发的特性。
@insionng 没有找到你提交的代码啊？
@insionng 急用啊，兄弟，哪里有你改的代码？那个存储分片的问题，我可以优化的。
其实我建议把docId换成string类型，至于大小排序，可以用户自己来控制，这样在DocId中可以带上一些简单属性，比如数据库、集合名、类别等信息
@huichen 作者你的这个项目我已经烂熟于心了，每行代码我记得清清楚楚，真心想把悟空完善起来，我是做大数据的，希望把它用到项目中。。。
在索引器中检索时，假如关键词的长度大于1，就只会在当前shard中查找与第2、3…关键词有交集的文档，然后再在engine的Search中进行汇总，这样子肯定是和全局数据求交集的结果不同。假如我没看错代码，应该是这个样子。 至于NumShards和PersistentStorageShards保持对应，是为了恢复数据不出错。当然，如果从两种的编号着手制定一种对应关系，也是可行的，会更好。