我有一个很好的理由使用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