实践是检验真理的唯一标准,只有在实际项目中用一用才能感受到Lucene.NET带来的性能变化。以现有的档案管理系统为例进行改造,有效数据约5.7万条。
硬件配置为AMD Ryzen5900处理器,16GB内存,SSD硬盘。应用采用默认配置,RAMBufferSizeMB默认为16MB,最大独立线程数MaxThreadStates默认为8,IndexWriter使用单实例方式,采用文件形式存储索引。
共57569条数据,创建索引耗时5787688毫米,约96分钟,即一个半小时左右,索引文件体积约20MB。由于没有横向对比对象,不好判断性能是否足够,个人认为速度还有提升的空间。
与原有的分页查询方法对比,分别测试单关键字和多关键字的查询速度对比。
使用单个关键字查询时,结果正常返回。原有分页查询方法耗时约1200毫秒。使用索引查询方法耗时约500秒,仅有分页查询时间的二分之一。在返回结果上,由于分页查询方法本质上使用的是SQL的like查询,因此只有完整包含关键字的数据才能被查询到,而索引查询能够将完全匹配和部分匹配的数据都返回。
使用多个关键字查询时,结果差异较大。分页查询方法耗时约1000毫秒,索引查询方法耗时约100毫秒。同时索引查询方法按匹配度高低返回了所有结果,由于索引查询方法会对查询关键词进行分词,所以多关键字和单个关键字查询的速度差异不大,结果匹配度也相对较高;而分页查询方法的多关键字匹配逻辑存在不合理的情况,导致无法匹配到正确结果。
以年份为维度对所有数据进行分类统计,分别测试普通SQL统计与维度索引统计的速度。
使用维度索引统计方法时,结果返回正常,耗时约30毫秒。可视化呈现结果如下:
使用普通SQL统计方法时,结果返回正常,耗时约41000毫秒。可视化呈现结果如下:
由于普通SQL统计方法是通过EntityFrameworkCore实现的,本质上是将统计逻辑用Linq语句表示,然后再转换成SQL语句执行,在转换和执行过程中会出现性能损耗。
而维度索引统计方法的数据是在创建索引时已经按需要统计的维度存储在索引文件里,可以认为是直接获取最终结果,速度当然会很快。
如果将普通SQL统计方法由实时统计改为查询已有统计结果,速度也应该会快很多。
从上面几项的简单对比来看,在以大量数据为查询对象时,索引在模糊查询的精确度、速度上是要好于常规的SQL查询方法的,能更好的满足模糊搜索、全文检索的需求场景;此外索引检索在在特定条件下的实时统计也是明显好于SQL实时统计的。但从实际的使用结果来看,仍然可以从以下几个方面对索引的创建、查询速度进一步优化。