[英]Changes in Lucene Index files when document gets add/update/delete?
我正在研究最新版本的Lucene 4.10.2，它結合了Java作為前端，Oracle 12c作為數據庫。
我已經索引了一個有100萬行的用戶表。 （記住LinkedIn用戶表）
當我們添加文檔/更新文檔/刪除文檔時，任何人都可以解釋我文件夾（文件被索引）的確切變化嗎？
附加樣本圖像：
我正在嘗試理解Lucene文件夾的文件結構，其中放置了所有索引文件。
這只是一對多的關系結構（我們搜索沒有登錄），稍后我會轉到很多關系（連接，連接連接，用戶的1：1索引文件夾）。
如果我的方法是正確/錯誤，請告訴我。
Lucene索引由多個“段”組成。 每個段只能寫一次，無論是當你調用commit()或在commit()被自動調用（通過設置的IndexWriter當內存使用量達到規定的閾值自動提交）。 通常，當您搜索索引時，將按順序搜索每個段，並將結果合並在一起。 Lucene以這種方式工作的原因是修改一個段將是一個非常緩慢的過程。 細分可以合並在一起，以提高搜索效果。 [1]
在您的示例中，以_0開頭的文件是第一個段，以_1開頭的文件是第二個段。 .cfe和.cfs文件是“復合文件”，它們包含該段的所有索引文件（有點像zip文件）。 有關詳細信息，請參閱默認編解碼器的文件擴展名和格式 。
所以你的三個操作是這樣的：
添加：文檔將始終添加到新段中。
刪除：實際上並未從索引中刪除已刪除的文檔。 而是設置一個標志以指示文檔被刪除。 未刪除的文檔稱為“實時文檔”。 已刪除的文檔仍會通過“文檔頻率”字段影響評分，並且在合並段之前不會更新。
更新：更新只是一個原子添加和刪除。
[1] http://blog.trifork.com/2011/11/21/simon-says-optimize-is-bad-for-you/
Lucene 從索引的文檔中更新字段，沒有松散的信息
[英]Lucene update field from document from index without loose information
通過重用文檔和字段實例提高Lucene索引性能時的問題
[英]problems when Improve Lucene Index Performance by reuse Document and Field Instance
聲明:本站的技術帖子網頁，遵循CC BY-SA 4.0協議，如果您需要轉載，請注明本站網址或者原文地址。任何問題請咨詢:yoyou2525@163.com.
