Lucene POJO 索引的一些问题

Question

近期在开放一个基于数据库（基于POJO的）的搜索引擎，现在想优化这个功能的层次架构，遇到一些疑惑。

第一个问题是关于索引的更新，想到两种方案：

1. 在service层中直接调用已封装好的 IndexClient.update(pojo)，但是发现这样一来，业务层和搜索功能的代码耦合度太高了。（选用）
2. 定时去更新所有索引。时间段定得短，索引没问题，但是数据量一大就会占用太多资源；时间定得长，索引就不及时。

想请教下各位有没有好的建议，能较及时的更新索引，又能将业务层和搜索解耦。

第二个问题是关于搜索结果转化为POJO：

1. 将POJO所有字段存储起来，在完成搜索后将Document转化成POJO，磁盘访问：索引读取一次。
2. 只存储POJO的 class 和 id，在完成搜索后重新从数据库中读数据，磁盘访问：索引读取一次，数据库读取一次。

想请教下各位怎么考虑这个问题。

特邀@红薯 @中山野鬼 ，谢谢

Answer 1

小项目可以考虑用hibernate search，完全面向对象。。

Answer 2

谢过哈

Answer 3

哈， 不好意思哦。这个不懂。

Answer 4

是的，service层专注于业务，耦合也只是业务耦合，数据耦合。而se原则上应该说是独立于业务的，否则我增加一个搜索板块，我就需要去修改一次。这样的方式可能有更好的解决办法，就像你说的消息事件。

Answer 5

耦合度其实不是个事，service层本来就是用来搞耦合的地方

如果还是嫌高，那就加入事件机制，每次添加或更新都触发个事件得了    

Answer 6

谢了，你的建议是个很好的优化方案。可能要解耦还是有些困难

Answer 7

看见别人都是推荐使用solr或elasticSearch，虽然我都不懂得…也可以标记修改过的内容，对应文档id执行update，就不用完全重建索引。索引可以引用多个directory，有内置的class实现了这个功能，于是增量的文档可以暂存到一个小的directory里，再定时合并。然后可以存储多份的directory，来回的dump，其中一份用于搜索，其余的实时增删改。后边的问题看不懂……

Answer 8

看样子要沉了。。。