簡體 English 中英

使用 Solr 搜索索引作為數據庫 - 這是否“錯誤”？

[英]Using Solr search index as a database - is this “wrong”?

原文 2010-11-23 16:53:34 9 6 java/ mysql/ database/ solr

我的團隊正在與使用 Solr 作為搜索索引的第三方 CMS 合作。 我注意到作者似乎使用 Solr 作為排序數據庫，因為每個返回的文檔都包含兩個字段：

Solr 文檔 ID（基本上是類名和數據庫 ID）
整個對象的 XML 表示

所以基本上它對 Solr 運行搜索，下載對象的 XML 表示，然后從 XML 實例化對象，而不是使用 id 在數據庫中查找它。

我的直覺告訴我這是一個不好的做法。 Solr 是一個搜索索引，而不是一個數據庫......所以對我來說對 Solr 執行復雜的搜索，獲取文檔 ID，然后從數據庫中提取相應的行更有意義。

當前的實現是否完全合理，或者是否有數據支持重構已經成熟的想法？

編輯：當我說“XML 表示”時 - 我的意思是一個存儲字段，其中包含所有對象屬性的 XML 字符串，而不是多個存儲字段。

6 個解決方案

是的，您可以將 SOLR 用作數據庫，但有一些非常嚴重的警告：

SOLR 最常見的訪問模式，即通過 http 對批量查詢的響應不是特別好。 此外，SOLR 不流式傳輸數據 --- 因此您不能一次懶惰地遍歷數百萬條記錄。 這意味着您在使用 SOLR 設計大規模數據訪問模式時必須非常周到。
盡管 SOLR 性能可以橫向擴展（更多機器、更多內核等）以及縱向（更多 RAM、更好的機器等），但與成熟的 RDBMS 相比，其查詢能力受到嚴重限制。 也就是說，有一些很好的功能，比如字段統計查詢，非常方便。
習慣於使用關系數據庫的開發人員在 SOLR 范式中使用相同的 DAO 設計模式時，經常會遇到問題，因為 SOLR 在查詢中使用過濾器的方式。 將有一個學習曲線來開發正確的方法來構建一個應用程序，該應用程序使用 SOLR 進行部分大型查詢或有狀態修改。
許多高級 Web 框架（Ruby、Hibernate 等）提供的允許高級會話管理和有狀態實體的“企業”工具將不得不完全拋棄。
關系數據庫旨在處理復雜的數據和關系——因此它們伴隨着最先進的指標和自動化分析工具。 在 SOLR 中，我發現自己編寫了這樣的工具並手動進行了很多壓力測試，這可能會浪費時間。
加入：這是大殺手。 關系數據庫支持構建和優化基於簡單謂詞連接元組的視圖和查詢的方法。 在 SOLR 中，沒有任何可靠的方法可以跨索引連接數據。
彈性：為了高可用性，SolrCloud 在底層使用分布式文件系統（即 HCFS）。 該模型與關系數據庫的模型完全不同，關系數據庫通常使用從站和主站或 RAID 等來實現彈性。 因此，如果您希望它具有雲可擴展性和抗性，您必須准備好提供 SOLR 所需的彈性基礎設施。

也就是說 - 對於某些任務，SOLR 有很多明顯的優勢：（參見http://wiki.apache.org/solr/WhyUseSolr ） - 松散查詢更容易運行並返回有意義的結果。 索引是默認完成的，因此大多數任意查詢都非常有效地運行（與 RDBMS 不同，在 RDBMS 中，您通常必須在事后進行優化和反規范化）。

結論：即使您可以將 SOLR 用作 RDBMS，您可能會發現（正如我所知道的）最終“沒有免費的午餐” - 以及超酷的 lucene 文本搜索和高性能內存的成本節省索引，通常是通過降低靈活性和采用新的數據訪問工作流來支付的。

根據您的應用程序，將 Solr 用作數據庫是完全合理的。 事實上，這幾乎就是Guardian.co.uk 正在做的事情。

這本身絕對不是壞習慣。 如果您以錯誤的方式使用它只會很糟糕，就像任何級別的任何其他工具一樣，甚至是 GOTO。

當你說“一個 XML 表示......”時，我假設你在談論有多個存儲的 Solr 字段並使用 Solr 的 XML 格式檢索它，而不僅僅是一個大的 XML 內容字段（這將是 Solr 的一個糟糕的使用） . Solr 使用 XML 作為默認響應格式這一事實在很大程度上無關緊要，您也可以使用二進制協議，因此在這方面它與傳統關系數據庫相當。

最終，這取決於您的應用程序的需求。 Solr的主要是文本搜索引擎，但也可以作為一個NoSQL的數據庫，對於許多應用。

這可能是出於性能原因而完成的，如果它不會引起任何問題，我會不理會它。 與 solr 索引相比，傳統數據庫中應該包含的內容存在很大的灰色區域。 我似乎人們為 UI 演示做了與此類似的事情（通常是鍵值對或 json 而不是 xml），並且只有在需要更新/刪除時才從數據庫中獲取真實對象。 但是所有讀取都只轉到 Solr。

我見過類似的事情，因為它允許非常快速的查找。 我們正在將數據從 Lucene 索引移入快速鍵值存儲，以遵循 DRY 原則並減小索引的大小。 這類事情沒有硬性規定。

添加到@Jayunit100 響應中，使用太陽能作為數據庫，您以一定的一致性為代價獲得可用性和分區容錯性。 在你寫的內容和你什么時候可以讀回來之間會有一個可配置的延遲。

我有類似的想法，就我而言，將一些簡單的 json 數據存儲在 Solr 中，使用 Solr 作為數據庫。 然而，改變我想法的一個重要警告是 Solr 升級過程。

請參閱https://issues.apache.org/jira/browse/LUCENE-9127 。

顯然，過去（v6 之前）建議在主要版本升級后重新索引文檔（不僅僅是使用 IndexUpdater），盡管您不必這樣做來維護功能（我自己不能保證這一點，這是從我讀過的）。 現在，在您升級了 2 個主要版本但沒有在第一次主要版本升級后重新索引（實際上，完全刪除文檔然后索引文件本身）后，您的核心現在無法識別。

特別是在我的情況下，我從 Solr v6 開始。 升級到 v7 后，我運行了 IndexUpdater，所以索引現在是 v7。 升級到 v8 后，核心將無法加載。 我不知道為什么 - 我的索引是 v7，所以滿足 Solr 的 version-minus-1 兼容性聲明，對嗎？ 嗯，沒有 - 錯了。

我做了一個實驗。 我從 v6.6 開始，創建了一個核心並添加了一些文檔。 升級到 v7.7.3 並運行 IndexUpdater，因此該核心的索引現在為 v7.7.3。 升級到v8.6.0，之后核心將無法加載。 然后我重復了相同的步驟，除了在運行 IndexUpdater 之后我還重新索引了文檔。 同樣的問題。 然后我再次重復所有內容，除了我不只是重新編制索引，我從索引中刪除了文檔並刪除了索引文件，然后重新編制了索引。 現在，當我到達 v8.6.0 時，我的核心就在那里，一切正常。

因此，OP 或任何其他考慮這個想法的人（使用 Solr 作為數據庫）的要點是，您必須 EXPECT 和 PLAN 不時重新索引您的文檔/數據，這意味着您必須將它們存儲在其他地方（以前的海報暗示了這個想法），這有點違背了數據庫的概念。當然，除非您的 Solr 核心/索引將是短暫的（不會持續超過一個主要版本的 Solr 升級），否則您永遠不會打算升級 Solr 超過 1 個版本，或者 Solr 開發人員更改此升級限制。 因此，作為存儲在其他地方的數據的索引（並且在必要時可以隨時重新索引），Solr 非常出色。 作為數據本身的數據庫，它強烈地“依賴”。