對於經常變化的文檔的Lucene索引策略

我正在將搜索功能集成到桌面應用程序中，我正在使用vanilla Lucene來執行此操作。該應用程序處理（可能數千個）POJO，每個POJO都有其自己的一組鍵/值屬性。在我的應用程序和Lucene之間映射模型時，我最初想到爲每個POJO分配一個文檔並將屬性添加爲字段。這種方法在索引和搜索方面效果很好，但主要缺點是每當POJO更改其屬性時，爲了更新索引，我必須重新索引所有屬性，即使是沒有更改的屬性。我一直在考慮改變我的方法，而是爲每個屬性創建一個Document，並將相同的ID分配給來自同一個POJO的所有文檔。這樣，當一個POJO屬性發生變化時，我只更新其相應的Document，而不重新索引所有其他未更改的屬性。我認爲圖表db Neo4J在編制索引時採用了類似的方法，但我並不完全確定。任何人都可以評論可能對性能，查詢等造成的影響嗎？對於經常變化的文檔的Lucene索引策略

來源

2011-05-16 teto

我正在努力解決完全相同的問題。你發現了一個更好的解決方案來保持lucene和POJOs同步之間的數據？ – 2014-03-03 09:33:12

它從根本上取決於您想在搜索結果中作爲文檔返回的內容。

但索引是相當便宜。一個變化的POJO是否真的有這麼多的屬性，重新定義它們都是一個主要問題？

來源

2011-05-16 00:32:49 EJP

我只關心檢索一個字段，POJO id，這是唯一實際存儲在索引中的字段，其他所有字段都被分析但不存儲。問題不在於POJO可能有很多屬性（這可能會發生，但不會經常發生），但會更新許多POJO（這肯定會發生）。 – teto 2011-05-16 01:16:58

如果您只在每個搜索請求中搜索一個字段，將一個POJO拆分爲幾個文檔將加速重新索引。但是如果搜索一個多個字段，POJO可能會出現很多次，這會導致另一個問題。其實，我同意EJP，建築指數在小數據集中速度非常快。

來源

2011-05-18 12:37:51 zzzhc

對於經常變化的文檔的Lucene索引策略

回答

相關問題