WEBUS2.0 In Action - 搜索操作指南 - (4)
上一篇:WEBUS2.0 In Action - 搜索操作指南(3)
6. 搜索多个索引
为了提升性能, 我们可以从多个索引同时进行搜索, Webus.Search.MultiSearcher提供了相关功能:
public MultiSearcher(ISearcher[] searchers) {...}
我们将多个ISearcher对象传入MultiSearcher, 就可以像操作一个ISearcher对象那样进行搜索了.
IIndexer idx1 = new IndexManager(); idx1.Open(@"c:\index1"); IIndexer idx2 = new IndexManager(); idx2.Open(@"c:\index2"); ISearcher se1 = new IndexSearcher(idx1); ISearcher se2 = new IndexSearcher(idx2); ISearcher se = new MultiSearcher(new ISearcher[] { se1, se2 }); var result = se.Search("Title=\"key\"");
由于MultiSearcher本身特性的限制, 如下方法和属性是不被支持的:
public int MinDocId public int MaxDocId public void Open(string indexPath) public void Open(Webus.IO.IDirectory dir) public Document SelectDoc(int docId) public Document SelectDoc(int docId, string[] fieldnames) public List<Document> SelectDoc(int[] docIds) public List<Document> SelectDoc(int[] docIds, string[] fieldnames)
值得注意的是, MultiSearcher会顺序调用所有的子搜索, 是顺序运行而非并发运行. 如果索引文件都在同一个物理磁盘上, 顺序运行的方式往往可以获得更好的性能. 不过如果我们有多块磁盘, 并且索引分别保存在不同的磁盘上, 那么我强烈推荐使用另外一种并发的搜索方式: Webus.Search.ParallelSearcher
public ParallelSearcher(ISearcher[] searchers) {...}
调用方式如下:
IIndexer idx1 = new IndexManager(); idx1.Open(@"c:\index1"); //索引index1在C盘, C盘是物理磁盘1# IIndexer idx2 = new IndexManager(); idx2.Open(@"d:\index2"); //索引index2在D盘, D盘是物理磁盘2# ISearcher se1 = new IndexSearcher(idx1); ISearcher se2 = new IndexSearcher(idx2); ISearcher se = new ParallelSearcher(new ISearcher[] { se1, se2 }); var result = se.Search("Title=\"key\"");
这个时候两块物理磁盘1#, 2#不会发生争用, 查询性能是能够得到明显提升的.
7. 缓存搜索结果
内存存取速度是硬盘的100倍以上. 正因为这个原因, 磁盘索引永远不可能比内存索引快. 因此我们需要为搜索结果添加缓存来改善我们的应用程序性能. 为此WEBUS2.0 SDK提供了Webus.Searcher.CacheSearcher来实现搜索缓存的功能.
public CacheSearcher(IQueriable indexer) {...} public ICacher<string, Webus.Search.Hits> QueryCacher { get; set; } public ICacher<int, Webus.Documents.Document> DocCacher { get; set; } public ICacher<string, Webus.Documents.Field> FieldCacher { get; set; }
在反复对10万数据级别的索引进行测试之后, 我们发现了如下三种缓存最能够提升性能:
Query Cache
对Search的结果进行缓存, 这些结果是最终结果. 这个缓存使用LRU算法进行调度, 同时由后台线程进行更新维护.
Doc Cache
通过分析索引中原始关键词的结果分布情况, 按照出现频率由高到低进行缓存. 这种缓存可以明显的改善数据加载性能, 其覆盖率与改善效果成正比. 这个缓存属于静态缓存, 数据一次性预加载到系统中.
Field Cache
通过预先加载可排序字段的值来提高排序性能. 这个缓存按照DocId由大到小进行加载. 也属于静态缓存, 数据一次性预加载到系统中. 值得注意的是, 这个缓存会尽量利用Doc Cache中已有的缓存数据来提高效率, 减少内存空间占用率.
不论是QueryCache, DocCache还是FieldCahce, 都是ICacher类型, WEBUS中提供了两个ICahcer的实现:
Webus.Search.Caches.LRUCacher - 近期最少使用缓存
Webus.Search.Caches.LRUExpiryCacher - 近期最少使用过期缓存
关于LRU算法, 网上有很多解释, 可以参照 http://baike.baidu.com/view/70151.htm
至于LRUExpiry算法, 其实是在LRU的基础上增加过期策略, 并利用后台线程实时释放过期的缓存项目, 从而减小内存占用. 属于一种增强型算法.
使用CacheSearcher的示例代码如下:
IIndexer idx = new IndexManager(); idx.Open(@"c:\index"); CacheSearcher se = new CacheSearcher(idx); se.QueryCacher = new LRUCacher(1000); //MaxSize=1000 se.DocCacher = new LRUCacher(1000); se.FieldCacher = new LRUCacher(1000); var result = se.Search("Title=\"key\"");
不论是LRUCacher还是LRUExpiryCacher, 我们可以通过指定缓存条目数(MaxSize)来限制内存占用. 需要注意的是这两种算法并非严格的遵循MaxSize的限制, 有时候也会可能超过这个限制, 但是马上会被后台维护线程发现并将需要淘汰的项目清除掉, 直至恢复到MaxSize之下.
至此, WEBUS2.0搜索部分就全部介绍完了. 在搜索操作指南 - (1) 到 (4)中, 我们分别介绍了如下主题:
- IQueriable内置的搜索功能
- Query对象的使用
- 对搜索结果进行评分, 排序和过滤
- 搜索多个索引 (顺序, 并发)
- 缓存搜索结果
希望能够有所帮助. WEBUS2.2.3.9已经发布, 赶快集成到你的程序中去吧! 下载地址
相关信息及WEBUS2.0 SDK下载:继续我的代码,分享我的快乐 - WEBUS2.0
访问我们的站点: www.gdtsearch.com