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

lucene索引文件大小優化小結