Boosting特性
luncene对Document和Field提供了一个可以设置的Boosting参数， 这个参数的用处是告诉lucene， 某些记录更重要，在搜索的时候优先考虑他们 比如在搜索的时候你可能觉得几个门户的网页要比垃圾小站更优先考虑
lucene默认的boosting参数是1.0, 如果你觉得这个field重要,你可以把boosting设置为1.5, 1.2....等, 对Document设置boosting相当设定了它的每个Field的基准boosting，到时候实际Field的boosting就是(Document-boosting*Field-boosting)设置了一遍相同的boosting.
似乎在lucene的记分公式里面有boosting参数,不过我估计一般人是不会去研究他的公式的（复杂）,而且公式也无法给出最佳值，所以我们所能做的只能是一点一点的改变boosting, 然后在实际检测中观察它对搜索结果起到多大的作用来调整
一般的情况下是没有必要使用boosting的, 因为搞不好你就把搜索给搞乱了, 另外如果是单独对Field来做Bossting, 也可以通过将这个Field提前来起到近似的效果
Indexing Date
日期是lucene需要特殊考虑的地方之一, 因为我们可能需要对日期进行范围搜索, Field.keyword(string,Date)提供了这样的方法,lucene会把这个日期转换为string, 值得注意的是这里的日期是精确到毫秒的,可能会有不必要的性能损失, 所以我们也可以把日期自行转化为YYYYMMDD这样的形势,就不用精确到具体时间了,通过File.keyword(Stirng,String) 来index, 使用PrefixQuery 的YYYY一样能起到简化版的日期范围搜索(小技巧), lucene提到他不能处理1970年以前的时间,似乎是上一代电脑系统遗留下来的毛病
Indexing 数字
- 如果数字只是简单的数据, 比如中国有56个民族. 那么可以简单的把它当字符处理
- 如果数字还包含数值的意义,比如价格, 我们会有范围搜索的需要(20元到30元之间的商品),那么我们必须做点小技巧, 比如把3,34,100 这三个数字转化为003,034,100 ,因为这样处理以后, 按照字符排序和按照数值排序是一样的,而lucene内部按照字符排序,003->034->100 NOT(100->3->34)
排序
Lucene默认按照相关度(score)排序,为了能支持其他的排序方式,比如日期,我们在add Field的时候,必须保证field被Index且不能被tokenized(分词),并且排序的只能是数字,日期,字符三种类型之一
Lucene的IndexWriter调整
IndexWriter提供了一些参数可供设置，列表如下
| 属性 | 默认值 | 说明 | |
| mergeFactor | org.apache.lucene.mergeFactor | 10 | 控制index的大小和频率,两个作用 |
| maxMergeDocs | org.apache.lucene.maxMergeDocs | Integer.MAX_VALUE | 限制一个段中的document数目 |
| minMergeDocs | org.apache.lucene.minMergeDocs | 10 | 缓存在内存中的document数目，超过他以后会写入到磁盘 |
| maxFieldLength | 1000 | 一个Field中最大Term数目，超过部分忽略，不会index到field中，所以自然也就搜索不到 |
这些参数的的详细说明比较复杂：mergeFactor有双重作用
- 设置每mergeFactor个document写入一个段，比如每10个document写入一个段
- 设置每mergeFacotr个小段合并到一个大段，比如10个document的时候合并为1小段，以后有10个小段以后合并到一个大段，有10个大段以后再合并，实际的document数目会是mergeFactor的指数
把maxMergeDocs设置小，可以强制让达到一定数量的document写为一个段，这样可以抵消部分mergeFactor的作用.
minMergeDocs相当于设置一个小的cache,第一个这个数目的document会留在内存里面，不写入磁盘。这些参数同样是没有最佳值的， 必须根据实际情况一点点调整。
maxFieldLength可以在任何时刻设置， 设置后，接下来的index的Field会按照新的length截取，之前已经index的部分不会改变。可以设置为Integer.MAX_VALUE
RAMDirectory 和 FSDirectory 转化
RAMDirectory(RAMD)在效率上比FSDirectyr(FSD)高不少, 所以我们可以手动的把RAMD当作FSD的buffer,这样就不用去很费劲的调优FSD那么多参数了,完全可以先用RAM跑好了index， 周期性（或者是别的什么算法）来回写道FSD中。 RAMD完全可以做FSD的buffer。
为查询优化索引(index)
Indexwriter.optimize()方法可以为查询优化索引（index），之前提到的参数调优是为indexing过程本身优化，而这里是为查询优化，优化主要是减少index文件数，这样让查询的时候少打开文件，优化过程中，lucene会拷贝旧的index再合并，合并完成以后删除旧的index，所以在此期间，磁盘占用增加， IO符合也会增加，在优化完成瞬间，磁盘占用会是优化前的2倍,在optimize过程中可以同时作search。
并发操作Lucene和locking机制
- 所有只读操作都可以并发
- 在index被修改期间，所有只读操作都可以并发
- 对index修改操作不能并发，一个index只能被一个线程占用
- index的优化，合并，添加都是修改操作
Locing
lucence内部使用文件来locking， 默认的locking文件放在java.io.tmpdir,可以通过-Dorg.apache.lucene.lockDir=xxx指定新的dir，有write.lock commit.lock两个文件，lock文件用来防止并行操作index，如果并行操作， lucene会抛出异常，可以通过设置-DdisableLuceneLocks=true来禁止locking，这样做一般来说很危险，除非你有操作系统或者物理级别的只读保证，比如把index文件刻盘到CDROM上。
调试IndexWriter
IndexWriter 有一个infoStream的变量，调试信息从这里输出。可以把System.out设置给它
269
扫一扫
到【灌水乐园】发言
今天发布一个java火星人搜索引擎，搜索 火星人 正在试用, 你不想试试吗？
http://www.rcomponent.com/se/index.aspx.
请多提意见.
是用java做的， 你相信吗?
现在的bug
1. 生成的url 后多了个引号.
2. 速度有点慢。
来源:http://www.blogjava.net/cap/archive/2005/07/20/8078.aspx