在同一个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特定的查询。

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

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