前两天做有关lucene的范围搜索,觉得应该很简单,因为之前做过lucene的排序。但一做就发现不那么回事,做排序程序几乎不需要改动,但范围搜索完全不同。下面就3个方面(整数,浮点数,日期)来说
前提:使用lucene1.9.1,将整数,浮点数和日期全部以如下方式建索引
doc.add(
new
Field(key, value,Field.Store.YES, Field.Index.UN_TOKENIZED));
上文中 Field.Store.YES也可以是 Field.Store.NO,但 Field.Index.UN_TOKENIZED不要改动
1)整数范围搜索
下面是个数据样本1,2,100,150,300,400,1000,如果你将这个数据建在索引库中,那么通过范围搜索,得出的结果就会令人奇怪,比如你搜100到1000,那么150,300,400是出不来,你搜1到2,居然1000也会冒出来,后来才发现,这种范围搜索没有把样本当数字还是当成字符在比较,这和排序完全不同。我没有找到更好的办法,只有将在建索引时前面补0,按照上面的例子我写成0000000001,。。。,0000001001,我把所有的数字变成10位字符,不足前面补0,因为11位是整数(int) 极限,所以我定为10位,而且我感觉超过10位会有问题,虽然我没试,但在下面的将日期变为long型保存时(13位)遇到问题,所以我在此没敢造次。如此这般,整数的问题解决了。
2)浮点数范围搜索
很幸运,我这次没在浮点数上栽跟头,我无意中将样本中浮点数都定为定长了,所以不会有问题。
3)时间范围搜索
在没做任何改动之前我们就是将Date型的数据toString()保存在索引中即yyyy-MM-dd HH-mm-ss.0,这样的话排序是没问题,但范围搜索就出问题了。
后来我先将所有时间变为long型,这样不会有错,因为2000年和3000年之间的所有时间都是13位,而我们的应用范围绝对在此之间,所以我做了这样的选择,但后来发现失败,范围搜索仍然不对,我想也许是溢出?
后来我又将时间定为yyyy-MM-dd的格式,搜索也出了非常奇怪的问题,我想肯定是因为格式带了“-"这样的敏感字符,时间紧迫不得已,我采用yyyyMMdd,这样就好了
前提:使用lucene1.9.1,将整数,浮点数和日期全部以如下方式建索引
![](https://i-blog.csdnimg.cn/blog_migrate/6810355c2f78c12e91b7997a8e8c583a.gif)
上文中 Field.Store.YES也可以是 Field.Store.NO,但 Field.Index.UN_TOKENIZED不要改动
1)整数范围搜索
下面是个数据样本1,2,100,150,300,400,1000,如果你将这个数据建在索引库中,那么通过范围搜索,得出的结果就会令人奇怪,比如你搜100到1000,那么150,300,400是出不来,你搜1到2,居然1000也会冒出来,后来才发现,这种范围搜索没有把样本当数字还是当成字符在比较,这和排序完全不同。我没有找到更好的办法,只有将在建索引时前面补0,按照上面的例子我写成0000000001,。。。,0000001001,我把所有的数字变成10位字符,不足前面补0,因为11位是整数(int) 极限,所以我定为10位,而且我感觉超过10位会有问题,虽然我没试,但在下面的将日期变为long型保存时(13位)遇到问题,所以我在此没敢造次。如此这般,整数的问题解决了。
2)浮点数范围搜索
很幸运,我这次没在浮点数上栽跟头,我无意中将样本中浮点数都定为定长了,所以不会有问题。
3)时间范围搜索
在没做任何改动之前我们就是将Date型的数据toString()保存在索引中即yyyy-MM-dd HH-mm-ss.0,这样的话排序是没问题,但范围搜索就出问题了。
后来我先将所有时间变为long型,这样不会有错,因为2000年和3000年之间的所有时间都是13位,而我们的应用范围绝对在此之间,所以我做了这样的选择,但后来发现失败,范围搜索仍然不对,我想也许是溢出?
后来我又将时间定为yyyy-MM-dd的格式,搜索也出了非常奇怪的问题,我想肯定是因为格式带了“-"这样的敏感字符,时间紧迫不得已,我采用yyyyMMdd,这样就好了