我正在开发一个典型的企业/业务应用程序,包括订单,销售人员,联系人,参考数据等......系统中一次至少有100个或更多用户输入新数据我需要在整个应用程序中为几乎所有表提供搜索功能。
一种选择是进行表查询,例如“select * from salespersons,其中name包含'searchtest'”或类似的东西。但我想知道我是否可以使用Lucene(.net)代替。
主要的是搜索需要在几秒钟内反映出变化。因此,例如,如果用户输入订单,然后立即立即搜索,则需要在搜索列表中显示。 (即,我不能每小时或半小时,或每晚都有索引工作等)。
这是否会运作良好,还是有更好的选择?
答案 0 :(得分:4)
是的,您当然可以将Lucene用于此用例。我看到了一些缺点:
并且(大)上升:
此问题的答案可能有助于Lucene.Net Best Practices
答案 1 :(得分:2)
我已经实现了与你描述的几乎完全相同的东西。要索引的表格很大(使用lucene进行索引的时间> 5小时),并且要求搜索将在5分钟内反映数据库中的更改。我考虑了两种方法(我实施了第一种方法):
逐步索引表格。每行都有一个时间戳(最后修改)。每隔5分钟,一个cron作业将启动一个java进程,该进程读取自上次运行以来修改的行,创建它们的纯文本版本,然后更新lucene索引。增量索引 将表锁定大约1000个表行200-300 msces。显然这取决于您的系统,数据库架构等。但是我的经验是,实现它绝对是可行的。与lucene相比,搜索操作的速度比查询快几个数量级。
使用专用线程进行索引编制。每当DB中的某些内容发生变化时,实际运行SQL查询的代码应该(通过LinkedBlockinQueue)向更新lucene索引的线程发送一条消息。这样,主线程上的updateDB()方法在更新数据库后立即返回,并且不必等待lucene索引过程,而索引会尽快发生(通常在几个msecs之后)。这样做的一个缺点是lucene使用存储在磁盘中的锁。所以我假设有一个更新每一行索引的开销(虽然我没有运行任何基准测试)。解决方法是在索引线程上保留更新缓冲区并每隔几秒将它们刷新到磁盘(同样,性能取决于更新与索引搜索的比率)