在同一个rails应用程序中使用BOTH mongodb和mysql是否有意义？

Question

我有充分的理由将MongoDB用于我的应用程序的一部分。但人们通常将其描述为不适合“交易”应用程序，例如交易必须精确/一致的银行等。

在Rails中拆分模型是否有意义并且其中一些使用MySql和其他mongo？或者这通常会导致更多的问题而不是它的价值吗？

我不是在构建银行应用程序或其他任何东西，但我认为可能对我的用户的表或事务表（记录收入）在MySql中执行该部分是有意义的。

Answer 1

这就是我们用CouchDB和PostgreSQL做的事情。

我们所有的用户和群组都在postgresql数据库中 其他任何东西（在我们的例子中，一些带有统计数据的记录）都在couchdb数据库中。

在我们的例子中，它允许我们为每个客户端提供一个couchdb数据库（应用程序将自己连接到一个或另一个，具体取决于用户的主机）。
并且只有一个postgresql数据库中包含所有用户。

所以是的，我认为在同一个应用程序中使用SQL和NOSQL数据库是个好主意。

Answer 2

没有理由不能在MongoDB中保留用户表。您是否决定在MongoDB中保留事务表是另一个问题。如果需要多对象事务，则必须使用支持事务的关系数据库。如果您不需要这种交易方式，那么使用MongoDB仍然是一个好主意。

请记住，如果您使用MongoDB，我们建议您使用复制进行故障转移。

要记住的一件事是，如果由于一致性保证而使用关系数据库，则仍需要确保配置硬件以利用这些功能。请参阅此处的注意事项：

http://dev.mysql.com/doc/refman/4.1/en/innodb-configuration.html

如果您没有采取这些预防措施，那么MongoDB的持久性与关系数据库的持久性之间没有太大差异。

Answer 3

还要考虑耐久性：http://blog.mongodb.org/post/381927266/what-about-durability，例如当你失去动力（电力）时。

Answer 4

虽然我不排除它，但我会对分裂方法保持警惕。

如果你需要MySQL + InnoDB并且听起来像你这样做，我只会介绍MongoDB，最好是更加孤立的部分，这些部分可以从MongoDB带来的好处中获得重要的东西，并且与核心MySQL表的关系最小。

我目前正在努力解决同样的问题，一个带有20个MySQL桌面的Rails应用程序。使用Mongodb可以解决一些数据库设计问题（特别是嵌套的子对象和可索引的数组列），但是很难证明额外的开销：

• 2种不同的查询方法
• 沿着相互关联的MySQL / Mongo对象的接缝处的尴尬自定义代码。
• 第二个支持生产的数据库平台。

我正在为我们的日志表推出MongoDB，我将从那里开始。

Answer 5

我说你在这里已经回答了你自己的问题。

  

我有充分的理由使用mongodb   对于我的应用程序的一部分。

假设你也有充分的理由在MySQL中保留其他部分，我会说答案是肯定的。你的问题暗示（至少对我而言）你对各种选择及其优点和缺点有一个良好的，充分研究的理解，因此得出了一个合理的结论，即分裂你的模型是可行的。

假设这两个部分没有以某种方式联系起来（两个声音之间的关系就像以后的疼痛一样），我建议你去寻找并使用每个工具来达到最佳状态。

有可能解决迈克尔用这种方法提出的一些担忧。由于您专注于使用Rails，因此可以将ActiveRecord用于基于MySQL的模型，并将MongoMapper用于基于MongoDb的模型。这样，您就不必处理两种完全不同的查询方法，因为MongoMapper提供了非常ActiveRecordish方法。当然，您可以根据需要轻松地进入Mongo特定的查询。

关于跨DB关系的关注在我看来是有效的，如果这是你最终会有很多的东西，我肯定会建议检查情况，以确保这是你很高兴与之生活在一起的东西。我想你可能会在以后的特殊情况下节省很多痛苦。

总的来说，我建议只要你的两个部分彼此相对脱节，分裂个性持久层就能很好地适合你。