从零开始搭建.NET Core版搜索引擎（十一）--项目实践及性能优化

ludewig

于 2021-10-09 21:08:02 发布

阅读量616

点赞数 1

分类专栏：数据处理 .NET 学习实践文章标签：搜索引擎 lucene.net .net core

本文链接：https://blog.csdn.net/lordwish/article/details/120679124

版权

学习实践同时被 3 个专栏收录

46 篇文章 10 订阅

订阅专栏

.NET

19 篇文章 7 订阅

订阅专栏

数据处理

11 篇文章 4 订阅

订阅专栏

实践是检验真理的唯一标准，只有在实际项目中用一用才能感受到Lucene.NET带来的性能变化。以手上的已有项目为例进行改造，看一看使用Lucene.NET后成果。

1.创建索引

硬件配置为AMD Ryzen5900处理器，16GB内存，SSD硬盘。应用采用默认配置，RAMBufferSizeMB默认为16MB，最大独立线程数MaxThreadStates默认为8，IndexWriter使用单实例方式，采用文件形式存储索引。
在这里插入图片描述

共57569条数据，创建索引耗时5787688毫米，约96分钟，即一个半小时左右，索引文件体积约20MB。由于没有横向对比对象，不好判断性能是否足够，个人认为速度还有很大的提升空间。

2.查询速度对比

与原有的分页查询方法对比，分别测试单关键字和多关键字的查询速度对比。

使用单个关键字查询时，结果正常返回。原有分页查询方法耗时约1200毫秒。使用索引查询方法耗时约500秒，仅有分页查询时间的二分之一。在返回结果上，由于分页查询方法本质上使用的是SQL的like查询，因此只有完整包含关键字的数据才能被查询到，而索引查询能够将完全匹配和部分匹配的数据都返回。

在这里插入图片描述

使用多个关键字查询时，结果差异较大。分页查询方法耗时约1000毫秒，索引查询方法耗时约100毫秒。同时索引查询方法按匹配度高低返回了所有结果，由于索引查询方法会对查询关键词进行分词，所以多关键字和单个关键字查询的速度差异不大，结果匹配度也相对较高；而分页查询方法的多关键字匹配逻辑存在不合理的情况，导致无法匹配到正确结果。

3.统计速度对比

以年份为维度对所有数据进行分类统计，分别测试普通SQL统计与维度索引统计的速度。

使用维度索引统计方法时，结果返回正常，耗时约30毫秒。可视化呈现结果如下：

在这里插入图片描述

使用普通SQL统计方法时，结果返回正常，耗时约41000毫秒。可视化呈现结果如下：

在这里插入图片描述

由于普通SQL统计方法是通过EntityFrameworkCore实现的，本质上是将统计逻辑用Linq语句表示，然后再转换成SQL语句执行，在转换和执行过程中会出现性能损耗。

而维度索引统计方法的数据是在创建索引时已经按需要统计的维度存储在索引文件里，可以认为是直接获取最终结果，速度当然会很快。

如果将普通SQL统计方法由实时统计改为查询已有统计结果，速度也应该会快很多。

4.性能优化

从上面几项的简单对比来看，在以大量数据为查询对象时，索引在模糊查询的精确度、速度上是要好于常规的SQL查询方法的，能更好的满足模糊搜索、全文检索的需求场景；此外索引检索在在特定条件下的实时统计也是明显好于SQL实时统计的。但从实际的使用结果来看，仍然可以从以下几个方面对索引的创建、查询速度进一步优化。

完善索引创建更新机制

由于本次测试是对已有项目进行改造，对于已有数据只能采用全部重建索引的方式。如果时初始化的项目，可以在创建、更新数据库实体的同时同步创建、更新索引，这样既能确保数据库实体与索引的同步，也能将创建索引的时间平均分配至每次单元操作中。在业务流程上也要尽量避免频繁的重建全部索引。

提升硬件配置

硬件性能的提升毫无疑问能提高创建索引的速度，更强的CPU、更大的内存、更快的磁盘会提高索引的读写速度。

修改基础配置

IndexWriterConfig中包含了索引读写器IndexWriter的相关配置，修改RAMBufferSizeMB能够利用更多内存，在应对大批量数据时也能减少IndexWriter的Flush操作；修改AutoCommit为False，关闭自动提交也能减少IndexWriter的操作；MergeFactor决定了当索引中segment数量达到多少时，就将这些segment合并成一个大的segment文件，加大MergeFactor的设定值也能减少IndexWriter的合并操作；设置最大独立线程数MaxThreadStates，能够更好的利用多线程的优势；设置setUseCompoundFile(false)，关闭复合文件格式会导致增加搜索和索引使用的文件句柄的数量，减少生成复合文件所消耗的时间，