我只是想知道，如果我們能夠實現Lucene的RDBMS功能。使用Lucene像關係數據庫
例： 1）我有10,000個項目文檔（PDF文件），它必須與他們的內容進行索引，以使其可用於搜索。 2）每個文檔都與單個項目相關。該項目可以包含項目名稱，編號，開始日期，結束日期，位置，類型等詳細信息。
我必須在pdf文件的內容中搜索給定的關鍵字，但顯示結果時我想顯示第（2）點所述的項目元數據。
我的想法是一個叫專案編號字段建立索引時每個PDF文件相關聯。一旦我們得到這些，我們將再次搜索獲取項目元數據。
這種方式，我們可以避免重複數據。另外，如果我們想更新項目元數據，我們將只在單一地點更新。否則，如果我們將這個元數據與所有的pdf doument索引一起存儲，我們將最終更新所有的文檔，這不是我正在尋找的方式。
請指教。
如果我理解正確的話，你有兩個問題：
嗨， 所有索引都只能使用lucene。將不會有任何數據庫通信。但lucene結構會是這樣的。 裝置 1）索引directory1中：將具有用於與產品ID 2）索引文件directory2索引：將具有用於容納產品ID 產品元數據索引這背後的主要思想是降低Lucene索引的大小。意味着這10,000個文檔中的每一個都將具有產品元數據，這是重複的數據，因爲我想要做一個單獨的產品元數據索引，這將在文檔索引中使用產品ID進行調用。 – 2009-05-07 07:15:54
好。您可以支持「給我產品ID爲nnn的所有文檔」或「爲產品id aaa，bbb提供元數據」類型的查詢。您甚至可以進行兩階段查詢，這相當於「給我所有與這些文檔相關的產品的元數據」。這不如RDBMS靈活，但對於您的用例來說似乎已經足夠了。如果你想要範圍查詢，你可能需要用零填充你的ID。 – 2009-05-07 08:46:36
聽起來像是一個非常好的事情。唯一的限制（通過在Lucene中存儲對項目的引用而非項目數據本身）是，您將無法同時查詢文檔文本和項目元數據。例如，「documentText：foo OR projectName：bar」。如果你沒有這樣的要求，那麼看起來就像在Lucene中存儲ID一樣，它指向一個數據庫行是一件很好的事情。
我不知道你的總體格局，但也許Hibernate Search是給你的。它將允許您將關係數據庫的優勢與Lucene等全文搜索引擎的強大功能相結合。元數據可以存在於數據庫中，也可以與原始的pdf文檔一起存在，而Lucene文檔只包含可搜索的數據。
這是絕對有可能的。但總是要意識到你正在使用Lucene來實現它不適用的事實。一般來說，Lucene設計用於全文搜索，而不是映射關係內容。因此，您的關係內容變得越複雜，性能下降得越多。
特別是，有少數地區保持密切關注：
如果你需要一個專門用於處理關係內容更加強大的指標，有層次的索引工具，有（一個由Apache的開發，號稱Jackrabbit）這是值得研究的。
隨着項目的不斷髮展，您還可以查看由Apache開發的Solr，它提供了一些額外的功能，例如多方位搜索。
你可以用那種方式使用Lucene;
優點：
全文搜索是很容易實現，這是不是在RDBMS的情況。
缺點：
參照完整性：你得到它在RDBMS免費的，但在Lucene中，你必須實現它自己。
您是否試圖避免複製來減少重複數據佔用的空間量？還是你想避免保持兩個系統同步的物流？ – 2009-05-07 14:40:00