我有一個很好的理由使用MongoDB作爲我的應用程序的一部分。但人們普遍認爲它不適合像交易必須準確/一致等「交易」應用程序。在同一個rails應用程序中使用mongodb和mysql是否有意義？
是否有意義在Rails中拆分模型，並讓它們中的一些使用MySql和其他人mongo？或者這通常會導致更多的問題，而不是它的價值？
我沒有構建銀行應用程序或任何東西，但認爲它可能對我的用戶的表或交易表（記錄收入）在MySql中執行該部分有意義。
這就是我們用CouchDB和PostgreSQL所做的。
我們所有的用戶和組的種類都在postgresql數據庫中。
其他（在我們的例子中，有統計數據的記錄）在couchdb數據庫中。
在我們的例子中，它允許我們爲每個客戶端擁有一個couchdb數據庫（根據用戶的主機，應用程序將自己連接到一個或另一個）。
並且只有一個postgresql數據庫擁有其中的所有用戶。
所以是的，我認爲在同一個應用程序中有一個SQL和一個NOSQL數據庫是一個好主意。
雖然我不排除它，但我會對分離方法保持警惕。
如果您需要MySQL + InnoDB，聽起來像您一樣，我只會介紹MongoDB以獲取更多的隔離部分，這些部分從MongoDB帶來的好處中獲得重要收益，並且與核心MySQL表關係最小。
我目前正在甩同樣的問題，一個在MySQL上有20個表的Rails應用程序。使用MongoDB的將解決一些數據庫設計的困境（嵌套子對象和索引的陣列列特別是），但它是很難證明的額外開銷：沿接縫
我正在爲我們的日誌表推出MongoDB，我將從此處開始。
我想說你已經在這裏回答了你自己的問題。
我有一個很好的理由使用MongoDB的 我的應用程序的一部分。
假設你還有一個很好的理由讓其他部分保存在MySQL中，我會說答案是肯定的。你的問題意味着（至少對我而言）你對各種選擇及其優點和缺點有了很好的深入研究，因此得出了一個明智的結論，即將模型分開是可行的。
假設兩半沒有以某種方式連接（這兩個聲音之間的關係就像後來的疼痛配方），我建議你去找它，並使用每個工具來獲得最佳效果。
可以解決邁克爾用這種方法提出的一些擔憂。由於您專注於使用Rails，因此您可以將ActiveRecord用於基於MySQL的模型，並將基於MongoDb的模型使用MongoMapper。這樣，您就不必處理兩種完全不同的查詢方法，因爲MongoMapper提供了非常活躍的記錄方法。當然，你可以在需要的時候輕鬆地下載到Mongo特定的查詢中。
關於cross-DB關係的問題在我看來是有效的，如果你最終會遇到很多問題，我肯定會建議檢查一下情況以確保這是你樂於生活的東西用。我想你可能會在那個特殊情況下爲以後節省很多痛苦。總之，我建議只要你的兩半彼此相對斷開，一個分裂個性持久層就可以很好地適用於你。
還要考慮耐用性：http://blog.mongodb.org/post/381927266/what-about-durability，例如，當您失去電力（電力）時。
這是許多類型的應用程序的交易斷路器。 Mongo是大量非關鍵數據的絕佳選擇。 –
酷，好點 - –
沒有理由不能讓你的用戶表保留在MongoDB中。無論您是否決定在MongoDB中保留一個交易表，都是另一個問題。如果您需要多對象事務，那麼您必須使用支持事務的關係數據庫。如果你不需要這種風格的交易，那麼使用MongoDB仍然是一個好主意。
請記住，如果您使用MongoDB，我們建議使用複製來運行故障轉移。
需要牢記的一點是，如果由於一致性保證而使用關係數據庫，則仍需確保硬件配置爲利用這些功能。看到這裏的謹慎注意：
http://dev.mysql.com/doc/refman/4.1/en/innodb-configuration.html
如果你不採取這些預防措施，那麼有沒有MongoDB的耐用性和關係數據庫之間的巨大差異。
哇 - 不知道這是在MySql上的情況。謝謝（你的）信息！ –
很感謝真實世界的例子！ –
您是否使用CouchDB連接器，或直接通過REST撥打電話？我有一個使用兩者都有意義的場景，並且我不確定中間的Active Record層是否值得，因爲這些調用將非常複雜並且可以運行。 – eddieroger