剛剛編譯了一些有關模式的基本solr問題。Solr模式問題
我的情況:以前有一個solr的多核實例,每個核心包含不同的文檔結構。儘管一個核心文檔中的信息與其他不同核心中的文檔相關,但具體的法律約束迫使我們保持獨立實例中的數據。因此,每次發佈對solr實例的請求時,都會查詢幾個核心,並將客戶端應用程序「合併」並構建幾個獨立核心的響應。爲了舉例說明:假設我們是音樂商店,聽起來很愚蠢,我們擁有CD的核心,DVD的核心,磁帶的核心等,每個核心都有自己的不同模式;然後當員工檢查庫存時,所有這些核心都會在員工的計算機中返回應用程序的響應以讀取,處理不同的結構,並將結果作爲一個統一列表呈現。
那麼,法律限制已經解除,我們現在正在將核心合併到一起,到目前爲止,嚴重依賴dynamicFields來實現架構靈活性。然而,這帶來了全新的挑戰以及一些疑惑:
1 - 更好的辦法是減少文件數量,每個文件都有大量的字段(我們正在談論數百個,偶爾有一千個在這裏或那裏,所有索引)或者將信息分散在幾個小尺寸文檔中?從理論上講,第一種方法是可取的,但我認爲任何情況都不會考慮這個數量的字段。
2 - 是否可以執行任何類型的關係搜索?我的意思是一樣的東西具有下列文件:
<doc>
<ID>[email protected]</ID>
<artist_t>Metallica</artist>
<album_t>Saint Anger</album>
</doc>
<doc>
<ID>[email protected]</ID>
<AlbID>[email protected]</AlbID>
<format_t>CD</format_t>
<price_m>8.99</price_m>
</doc>
<doc>
<ID>[email protected]</ID>
<AlbID>[email protected]</AlbID>
<format_t>MP3</format_t>
<price_m>3.99</price_m>
</doc>
,然後在對Metallica的執行搜索已經全部三個文件檢索到的?請記住,將第一個文檔中最後兩個文檔的信息作爲多值存儲的方法並不是一個真正的選擇,因爲據我所知,將無法使用p.e.檢索與價格範圍搜索匹配的正確格式。
3 - 或者,是否有可能將某種子文檔結構定義爲文檔的一部分,就像在多級文檔中一樣?再次,我不是指poly或multiValued字段,因爲據我所知它們不適合更復雜和結構化的信息。是 思維沿着線的東西:
<doc>
<ID>[email protected]</ID>
<artist_t>Metallica</artist>
<album_t>Saint Anger</album>
<formats>
<format_x><ID>[email protected]</ID><AlbID>[email protected]</AlbID><format_t>MP3</format_t><price_m>3.99</price_m></format_x>
<format_x><ID>[email protected]</ID><AlbID>[email protected]</AlbID><format_t>CD</format_t><price_m>8.99</price_m></format_x>
</formats>
</doc>
4 - 一個考慮:當然,這種情況可以通過像2描述建模的模式),並在服務器中執行多個查詢是固定的,但這不是最理想的解決方案。
期待任何評論或建議。抨擊是少受歡迎的,但仍然可以接受,只是容易對我。 ;)如果這些問題聽起來很愚蠢,但真的需要一些幫助,我很抱歉。
非常瞭解Solr Join,從來沒有聽說過它。我一定會考慮一下,即使我認爲沒有機會實施中繼構建。關於您的答案的其餘部分:多值字段不是一種選擇,因爲我的真實生活情況涉及更深層次的幾個級別和非常複雜的結構,所有這些都可以完全搜索。我還想在1)問題中聽到你的意見;我知道沒有字段限制,但想知道什麼是推薦的方法:更少的文檔,每個VS中的大量數據更多的文檔,更小的數據量。 – 12N
再次從我的角度來看,它取決於我想組織的數據更容易符合我的要求。如果收集量小,那麼包含更多字段的文檔可能對您而言效果不錯。但是,如果它是一個休眠集合,則需要檢查FieldCache對象。這些對象緩存索引中可用文檔總數的字段值,並且無法通過Solr配置調整此緩存,這可能會導致內存問題。雖然它不是專家意見,Solr論壇將是獲得這些答案的最佳地點。 – Jayendra
我明白了,謝謝! – 12N