哪種類型的情況適合使用關系數據庫和NoSQL數據庫？

Question

這不是NoSQL vs. SQL類型的問題。 我對可以使用RDBMS和NoSQL數據庫的組合的場景類型感興趣，並且組合的使用非常適合 。 一般情況下，我明白了“這取決於”手頭上的形勢和任務，但我的想法是，必須有一些普通/通用^1分的情況下這樣的組合是非常有用的。

上述每種類型的解決方案都有自己的優點和缺點 - 我所追求的是可以充分利用和利用兩者優勢的情況/場景。

在我看來，一個可能是電子商務。 RDBMS上的付款，交易等（想想ACID ² ）以及NoSQL數據庫中的產品信息和目錄。 但是，它適合嗎？

應用的橫切關注點，例如。 作為另一個例子，日志記錄可能非常適合NoSQL類型的解決方案。

或者，為什么不組合使用這兩種技術？

編輯：重申一下，我理解SQL和NoSQL都有其固有的優點和缺點，並且某些類型的情況更適合上述數據存儲中的一個。

^1我知道Facebook，谷歌等巨頭可能會使用這些巨頭，但 幾乎 在大多數情況下，我認為大多數SO成員都不會使用這些巨大的解決方案。 更典型的日常類型的東西。

² RavenDB是一種支持ACID事務的NoSQL解決方案

Answer 1

NOSQL可能用於從SQL數據存儲區復制數據。 在這種情況下，我想從移動SQLITE記錄創建文檔，並依賴couch或mongo將其復制到服務器上的nosql。 然后，服務器SQL可以處理傳入的文檔。

Answer 2

一個很好的例子可能是任何分布式數據存儲同時在多個節點上更新，並且需要支持可能復雜的即席查詢。 節點將“最終一致”，這意味着任何特定節點在任何時間點的數據圖像中都可能存在間隙。

這很適合RDBMS，因為間隙可以通過關系之間的“外部”連接非常簡單地處理。 關系模型應該比基於圖形的模型更適合於此，因為圖模型依賴於不同數據元素之間的導航路徑。 如果缺少某個元素，則該圖形將分為兩個圖形，因此任何基於路徑的查詢都可能無效。 關系模型中不存在此問題，因為關系數據庫是非導航的 - 數據元素之間沒有結構“鏈接”，因此針對數據的查詢的“形狀”不需要僅因為數據丟失而更改。

Answer 3

一個明顯的答案可能是報告一個例子，在一個簡單的應用程序中哪一個比另一個更合適。

例如，您可能希望為OLTP工作使用RavenDB或Couch等文檔數據庫，因為它為您提供了保存實體的方法，並將這些實體查詢為跨文檔的平面投影（單查詢視圖）。 （RavenDB比CouchDB更多，但這既不在這里也不在那里;-)）

您還可以將它用於簡單報告，使用Map / Reduce為您提供某些統計信息，以便在某些頁面上顯示（熱門產品，標簽雲等）。

但是，構建了許多報表系統來查詢關系存儲，因此您可能希望將數據復制到報表數據庫中。

例如，在RavenDB中，您可以選擇獲取任何索引，並自動將該索引中的數據復制到關系存儲中。

這是有道理的，因為以關系格式存儲數據意味着您可以執行復雜的跨文檔查詢並與現有報告產品集成 - 而不會妨礙標准OLTP工作或文檔數據庫設計。

這只是眾多問題中的一個答案，因為還有其他一些例子，其中一種特定類型的數據存儲更適合於特定目的，在一天結束時，沒有遠離它。 （除非你相信VoltDB的人）

Answer 4

除非您在關系數據庫根本無法工作的規模下運行，否則NoSQL的一大優勢是易於開發 - 例如不需要ORM或數據庫升級腳本。 一旦開始在系統的一個部分使用SQL，將其用於其他部分只需要很少的額外工作。

在幾乎任何項目中，都會有更適合特定類型數據存儲的組件。 重要的問題是差異是否足以證明使用多個數據存儲的開銷。 通常，這意味着規模，臨時報告和數據結構的組合不能很好地映射到關系數據庫。

Answer 5

這不是一個真正的編程問題，但這就是我的想法。

如果考慮CAP定理http://en.wikipedia.org/wiki/CAP_theorem ，你可以假設Relationnal數據庫集中在一致性和可用性，而NoSQL的專注於可用性和分區耐性（與最終一致性）。

如果您認為SQL查詢真的一致，那么您應該考慮使用RDBMS。 如果它不是先決條件，那么您可以使用NoSQL數據庫。

這就是為什么大多數時候，最好的答案是同時使用兩者，兼顧兩者。