lucene索引文件大小优化小结
1 数值数据类型索引优化
1.1 数值类型索引问题
lucene本质上是一个全文检索引擎而非传统的数据库系统，它基于倒排索引，非常适合处理文本，而处理数值类型却不是强项。
1.2 lucene解决方法
为解决这一问题， Schindler和 Diepenbroek提出了基于trie的解决方法，此方法08年发表在 Computers & Geosciences （地理信息科学sci期刊，影响因子1.9）
1.3 索引文件大小优化方案
我们的应用中很多field都是数值类型，比如id、avescore（评价分）、price（价格）等等，但是用于区间范围查询的数值类型非常少，大部分都是直接查询或者为进行排序使用。
因此优化方法非常简单，将不需要使用范围查询的数字字段设置precisionstep为Intger.max，这样数字写入倒排仅存一个term，能极大降低term数量。
1.4 效果
优化之后效果明显，索引压缩包大小直接减少了一倍。
2 空间数据类型索引优化
2.1 地理数据索引问题
还是一样的话，lucene基于倒排索引，非常适合文本，而对于空间类型数据却不是强项。
举个应用场景，每一个商家都有唯一的经纬度坐标（x, y），用户想筛选附近5千米的商家。
2.2 lucene解决方法
lucene采用geohash的方法对经纬度进行编码（geohash介绍参见：GeoHash）。简单描述下，geohash对空间不断进行划分并对每一个划分子空间进行编码，比如我们整个北京地区被编码为“w”，那么再对北京一分为4，某一子空间编码为“WX”，对“WX”子空间再进行划分，对各个子空间再进行标识，例如“WX4”（简单可以这么理解）。
2.3 索引文件大小优化方案
上述方法本质上也是一种以空间换时间的方法，比如一个经纬度（x，y），只有两个字段，但是以geohash进行编码将产生许多term并写入倒排。
lucene默认最长的geohash长度为24，也就是一个经纬度将以24个字符串的形式来写入到倒排中。最初采用的geohash长度为11，但实际上针对我们的需求，geohash长度为9的时候已经足够满足我们的需求（geohash长度为9大约代表了5*4米的格子）。
2.4 效果
此优化效果结果未做记录，不过经纬度geohash编码占据了term数量的25%，而我们又将geohash长度从11减少到9（降低18%），相当于整个term数量降低了25%*18%=4.5%。
3 只索引不存储
上面两种方法本质上通过减少term数量来减少索引文件大小，下面的方法走的是另一种方式。
从lucene查出一堆docid之后，需要通过docid找出相应的document，并找出里面一些需要的字段，例如id，人均消费等等，然后返回给客户端。但实际上我们只需要获取id，通过这些id再去请求DB/Cache获取额外的字段。
因此优化方法是只存储id等必须的字段，对于大部分字段我们只索引而不存储，通过这种方法，索引压缩文件降低了10%左右。
4 小结
本文基于lucene的一些基础原理以及自身业务，对索引文件大小进行了优化，使得索引文件大小下降了一半多。
此文作为学习笔记记录，感谢原文作者https://www.cnblogs.com/LBSer/p/4068864.html