在單個應用程序中使用多種數據庫類型對數據進行建模

Question

將應用程序的數據模型分解爲不同的數據庫系統有意義嗎？例如，應用程序將所有用戶數據和關係存儲在圖形數據庫中（理想用於存儲關係），而將其他數據存儲在文檔數據庫中，例如CouchDB或MongoDB？這將要求用戶圖形數據庫引用文檔數據庫中的唯一標識符，反之亦然。

這是否使數據模型和應用程序複雜化？或者，這是否使用這兩種類型的數據庫系統的最佳用途來擴展您的應用程序？

Answer 1

它絕對有意義，完全取決於您的應用程序的要求。如果你可以使用其他數據庫系統來處理他們擅長的事情。

以全文檢索爲例。當然，您可以使用像MySql這樣的關係數據庫進行或多或少複雜的全文搜索。但是有一些系統像例如Lucene/Solr，它們針對這些事情進行了優化，並且可以在數百萬個文檔中快速搜索。所以你可以使用這些系統來完成他們的特殊任務（這裏：做一個漂亮的全文搜索），然後你返回標識符並且可能從RDBMS加載關係結構化數據。

或CouchDB。我在一些項目中使用couchDB作爲緩存系統。與關係數據庫結合使用。當然，我需要關心一致性，但這絕對值得。它推動了項目中的性能，並將服務器上的負載從2降低到了0.2。 :)

Answer 2

像這樣的東西，例如稱爲跨存儲持久性。正如你所提到的，你將存儲在關係數據庫中的某些數據，graphdb中的社交關係，文檔數據庫中的用戶生成數據（文檔）以及用戶提供的多媒體文件（圖片，音頻，視頻），如S3 。

它主要關注用例並確保從任何需要的地方訪問每個商店的「主」或索引鍵（來回）。您可以將實際查找封裝在您的域或dao圖層中。

某些框架（如Spring Data項目）提供了一些初始類型的跨存儲持久性，主要是將JPA與不同的NOSQL數據存儲集成。例如Spring Data Graph允許它的實體存儲在JPA和添加社交圖表或其它高度互連的數據作爲secondary concern，並充分利用了典型的穿越和其他圖形操作的graphdb（如排名，建議等）

Answer 3

的另一個術語爲這是多邊形持久性。

以下是關於這個問題的兩種截然相反的立場：

臨： 「與此相反，我通曉多種語言的持久性的大風扇這只是意味着使用每個usecases右側存儲後端爲。例如文件存儲，SQL，圖形數據庫，數據倉庫，內存數據庫，網絡緩存，NoSQL。現在大多數使用了兩個存儲，文件和SQL數據庫，兩者對於每個用例都不是最優的。

• http://codemonkeyism.com/nosql-polyglott-persistence/

精讀： 「我不認爲我需要說我多語種持久的支持者，我相信，在Unix工具哲學。但是，當你的系統增加更多的組件時，你應該意識到這樣一個系統的複雜性是「爆炸性的」，所以運營成本也會增長（你記得爲什麼Twitter開始使用Cassandra？）。且不說更多的組件系統中有更多的關注和關懷，必須投入搞清楚像系統的整體可用性，延遲，吞吐量和一致性的關鍵環節。」

• http://nosql.mypopescu.com/post/1529816758/why-redis-and-memcached-cassandra-lucene