Lucene權限實現

1、權限過濾

Lucene的基於關鍵字的評分機制，適用於基於相關度的過濾和排序。它是基於矢量模型，其中給文檔分配一個相應的分數，分數越高相關的文檔也越多。然而，應用系統有時由於用戶級權限僅需返回相關文檔的子集。

過濾的權限問題其實是查詢時將一個布爾過濾器做用於文檔的廣泛問題的子問題。咱們將探討這種過濾的實現方法。

二、查詢改寫

上述權限過濾明顯的實現方法，就是改寫搜索查詢爲要求某字段包含特定的值。

例如，若是有一個「類別（category）」字段（Field），並假設僅顯示歷史（history）和科學（science）類的文檔，而後對給定的用戶查詢：

<query>

查詢可被改寫爲：

<query>+category:history+category:science

三、查詢過濾器

此種假設對於過濾的字段（Field）多是不適宜或不可行的（也許因爲字段（Field）是易變的和頻繁的變化將致使索引的大量修改）。另外一方法是經過 實現Filter接口建立一個過濾器，只需實現一個方法，即bits()方法，該方法返回BitSet，包含命中的全部容許文檔ID。

在bits()方法中，可以使用TermEnum經過Term篩選（速度慢！），或使用FieldCache檢索字段的全部值（速度快，但爲內存密集型！）。

四、HitCollector + FieldCache

另外一個篩選文檔(Documents)的方法是使用HitCollector而非Hits對象。在collect()方法以文檔（Document）ID和評分（score）做爲參數，能夠此來判斷文檔容許訪問與否。

使用HitCollector有一個小缺點，Hits類中遍歷搜索結果的有用方法都沒有公佈，但解決方法容易。

五、範例

比方說，你有一個多用戶博客程序，並但願讓用戶搜索所有（默認）博客文章，或容許用戶只搜索他發表的博客。博客應用的Lucene模型將每一博客映射爲一Document。

使用查詢改寫方法，能夠輕鬆地爲該查詢附加搜索（條件）子句：

<query>+author:<authorid>

這將只返回做者的文檔。問題解決了。

如今，擴展該示例。假設在應用中存在3種訪問角色：管理員(admin)，編輯(editor)，做家(author)。這些訪問角色的權力是遞減的，所 以一個編輯（editor）對做者的博客有寫（write）權限，但對管理員（admin）的博客無此權限。如何才能讓用戶只搜索他具備寫訪問權限的博客 呢？

該查詢改寫方法可用來爲每一文檔（Document）添加一個「角色（role）」字段（Field），並現場填入做者角色（role）。假設用戶的角色爲編輯（editor），那麼改寫後查詢爲：

<query>+（role：editor role：writer）

這種方法是有效的，但不是最理想的，由於每次做者的角色會改變，就須要更新他所寫全部博客文檔（Documents）。

另外一種使用查詢改寫的方法是得到角色爲編輯（editor）和做者（writer）的全部用戶列表，而後追加到查詢後，以下所示：

<query>+（author:1author:2 author:......)

這方法更好，但龐大的或-查詢子句對於布爾過濾可能會妨礙搜索性能。

實現該功能的第三種方法是獲取指望的用戶列表，如同上前一方法，但不是改寫查詢，而是使用HitCollector + FieldCache的方法，所以只接受所指望的博客。這種方法具備第二種方法的優點但無性能問題。