数据库的全文检索，有什么好的方案？

今天听到一个需求，大致情况如下：

有一张数据库表，有诸如name，size，color，date等各种字段。字段很多，存储的数据量很大，并且时常有增删改的操作。

现在客户希望像google一样，有一个输入框，随便输入关键字，可以检索到相关的记录。比如输入绿色，或者输入10厘米，都能搜索到这张表中的记录。


大家有什么方案提供？一起讨论一下。

lucene

楼上做过？请给出具体方案。数据库不是文本，不要信口开河。

lucene
当对数据库进行create/update/delete的时候，对lucene进行相应的操作，而且如果你用的是Hibernate/JDO/EJB3这种武装到牙齿的ORM，只用写一个通用的Lucene Index Interceptor就可以了，不需要在DAO里面做任何多余的代码。

Readonly的方案我考虑过，我所担心的是并发和效率问题。

比如这张表是经常被增删改的，那在某段时间内可能出现多个进程同时试图修改lucene的反向索引，与此同时，这个索引可能还要被用作搜索，而源数据已经被修改了。

另外就是不清楚反向索引的merge效率，有人有类似的实践经验请赐 教一二。谢谢！

create/update/delete index不需要考虑并发，Inteceptor负责将此类事件丢到一个queue就可以了，异步地执行
但是实际运行中还是会出现稀奇古怪的index文件没有和数据库内容同步情况，所以偶们后来schedule了一个job，定时在系统使用量比较少的情况下做一个full database scan来同步index，比如每周6凌晨4点
这个solution没有任何技术含量的，自己去弄个大数据量的数据库试验一下就知道是否满足用户需求了

可怜的 嘻嘻 幸好我知道它是支持非文本的

有一本关于它的很厚的黄色英文的书(打英文不方便) 说得挺全的

如果数据库是oracle，那么其本身的全文检索功能能很方便的完成你的要求。

如果机器性能够好，可以考虑在RAM Disk存放lucene的索引，lucene只存放索引
lucene可以在更新记录的同时即时更新索引，但它是用文本保存索引的，频繁的更新可能引起密集的I/O，如果硬件条件允许，可以考虑对lucence使用RAM Disk来提高性能，这个要权衡一下数据库本身的大小，如果数据量很大的话，那么产生的索引还是相当可观的

感谢楼上各位的回复，我去做一些实践，再回来和大家继续讨论。