用Lucene做搜索碰到的问题，供大家思考讨论

1.更加实时的数据更新架构设计
我们的网站主要是视频节目的搜索，内容也都是来自用户。
我们提供的功能在搜索结果中，我们会显示播放次数等数据，这些数据的特点是更新非常频繁，
有什么好的方式能够让这种数据更加实时的更新。
还有就是内容都是来自用户，用户无时无刻都在上传节目，而且他们希望能够尽快从搜索中搜索到他们的节目。
问题也是设计怎么样的架构来更实时的索引。
2.索引数据量大的问题
虽然用户量的增大，节目数增长也非常快。单台服务器能够处理的索引大小的上限是多少？达到上线如何处理。
我现在想到的方法就是按照功能先拆分，比如：播客搜索、节目搜索分别放到不同的服务器上。

3.什么样的数据应该做到索引中？
我们现在需要在页面上展示出来的数据、排序要到的数据都会放到索引中。
因为展示的数据比较多，所以，索引的大小增长的非常快。
什么样的数据应该放到索引中？对于控制索引的大小还有什么方法？

4.多线程索引速度会快吗？
就是关于提高索引速度的问题。
我现在发现，做索引的过程是非常耗CPU的。那么单台服务器上做索引，如果使用多线程的方式是不是会快一些。
多线程做索引怎么设计比较好？能够加快多少呢？

5.搜索结果提速：静态化的方案和查询结果缓存的方案
我没有试过Lucene的缓存查询结果，不知道效果如何？特别是在大并发量请求的情况下，会不会占用很大的内存，导致OutOfMemory呢？
还有一种方式就是把查询结果静态化，这样做好吗？静态化后也要考虑更新的问题。

6.数据来源的完整性问题，
现在数据来源都是采用数据库多表关联查询出结果，然后做到索引中。
一次查询大量的数据，数据库的响应比较慢，是否有更好的方式呢？
例如，以XML形式的接口数据？

7.自动提示功能的开发
类似google的那种，在用户输入的时候自动给出很多关键字的提示。

我觉得目前Lucene不适合做实时的，你可以当日的由数据库提供，量不大，对数据库的字段like也可以忍受的。

如果要索引的数据能相对独立地分开来，那就尽快分开来吧！

查一条做一个doc呀，速度还是能匹配的。

我看到的数据是Lucene单个索引的doc数最大值是Integer.MAX_VALUE。

用 compass 吧！

播放次数可以在页面载入后用ajax异步去取一次，很多时候都是这么干的，QQ空间也是……
建索引的瓶颈一般可能是在I/O上吧，调整minMergeDocs试试呢。如果是CPU不行，那多线程也没办法啊。还有就是建索引时很耗DB，用异步方式实时更新索引似乎好一点。

俺也做过这样的一个相关Lucence搜索平台。
其中一个大表的数据有将近一千万。
用lucence索引完这个表就有将近100多兆的索引文件

我也是做视频搜索网站的，有个问题要问的就是贵站预计数据量在多少？半年后是多少？一年后是多少？如果在千万级别以下，用Lucene尚可一搏。
请参考我做的视频搜索http://so.mdbchina.com/video/%E7%BE%8E%E5%A5%B3，我改写了Lucene的核心部分以大幅度提高性能，相关帖子在http://www.javaeye.com/topic/78884，http://www.javaeye.com/topic/80073，并附有源码。
如果超过千万级别，建议用C++实现，或者还用Lucene但要把所有索引文件放入内存。
你提的问题好多好大，能否先去我做的那个看看，有些想法再和我交流交流。

lz碰到的问题应该是你实际中遇到的一些起步问题。随着你深入和涉及面广了，还会有其他问题。

1.更加实时的数据更新架构设计
中间加入一个层来处理实时，建立一套机制将实时和全文检索结合。

2.索引数据量大的问题
lucene的index大小通常在3g左右才有明显效率变化。这在lucene的maillist有讨论。
数据量大的就要做分布式处理。也就是说设计分布式搜索平台。
功能是否拆分，怎么拆分，我觉得应该从应用角度来看，而不是从技术这块来看。


3.什么样的数据应该做到索引中？
索引大小有很多因素，常规看analyzer和mergeFactor，buffer。
如何选择数据，这就看你应用了。

4.多线程索引速度会快吗？
索引本身很耗资源，所以要将索引和搜索分离。
索引速度提升有很多方法，参数调整，索引前数据调整，分布式索引等。

5.搜索结果提速：静态化的方案和查询结果缓存的方案
并发高的，cache很重要，另外一些lucene的参数调整，也能起到很好的优化作用。
静态化方案也可以采用，基于你搜索的更新时间。


6.数据来源的完整性问题，
看你如何设计数据系统。
数据返回可以采用多种方式，我个人偏向json。

7.自动提示功能的开发
这是ajax的应用


从我经验来看，修改lucene的核心代码，很难从根本上解决问题。

从应用角度，从系统分布角度去分析，去测试，才能从根本上解决问题。语言只是个工具，如果无法将复杂的处理分离，那么写的再好，也有它的局限性。

compass我现在也在尝试，感觉很不灵活。动不动就要修改起 源代码

播放次数用ajax调用应该是个不错的方案。不过还有个问题是如果还要按照播放次数排序，那还是要把播放次数放到索引中的。

调整minMergeDocs有没有好的经验呢？多少比较合适呢？

1千万才100多兆？
你的索引中都放的那些数据？需要索引的内容是什么类型的？文章？还是其他的？