Mongodb/Couchdb 代替 MySQL（从 PHP 切换到 Node）

Posted 2023-03-07

【中文标题】Mongodb/Couchdb 代替 MySQL（从 PHP 切换到 Node）

【英文标题】：Mongodb/Couchdb instead of MySQL (Switching from PHP to Node)

【发布时间】：2012-12-14 06:34:19

【问题描述】：

我在后端使用 php/mysql/Solr 并在前端使用 javascript/jQuery/Backbone 完成了大部分 Web 开发。

我已经编写了一些 Node 应用程序，但使用 MySQL 而不是许多 Node 教程/书籍使用的 Mongodb/Couchdb。你会开始使用 Mongo/Couch 而不是 MySQL，因为大多数开发 Node 的人都在使用它吗？ MySQL 似乎对我来说工作正常，我不清楚切换到 Mongo/Couch 的优势。

现在我正在启动一个站点，其中“前端”应用程序服务器是 PHP/MySQL，而数字处理服务器在 Node.js 中。我坚持使用 PHP 服务于“前端”的原因是因为我非常喜欢在我的 PHP 框架中进行开发。

选择 Node 的原因是因为会有很多并发任务，空闲/等待时间以秒为单位。这必须是高度可扩展的。

将存储在数据库中的内容就像您将存储在 MySQL 表中的常规内容

【问题讨论】：

如果您对 MySQL 感到满意并且没有任何强烈的转换动机，我建议您坚持使用它。

MySql 在 Node 上运行良好，“mysql”包简单可靠。顺便说一句——你也应该成为“异步”包的好朋友（如果你还没有）。

【参考方案1】：

你需要考虑的一些事情 -

扩展是我们迁移到 mongoDB 的最重要原因之一。对 MongoDB 进行分片和复制是轻而易举的事。因此，如果您的应用程序需要水平扩展，那么 mongoDB 是您的最佳选择。垂直扩展只能达到你很快就会遇到硬件限制的程度......另外，在 mysql 上进行分片是一个真正的痛苦。 其次是数据库模式。在像我们这样的大多数初创公司中，需求和功能变化非常迅速。因此，在一段时间内，基于 mysql 模式的数据库可能更像是一种束缚，而不是“良好实践”。在这种情况下，没有人关心“良好做法”。因此，如果您需要可扩展的无模式数据库，请考虑使用 mongoDB。 所有这些都附带一个免责声明，即 mongoDB（和其他 NoSql 解决方案）是 DB 世界中闪亮的新玩具。它们远没有 MySQL 成熟。他们中的大多数人，包括 mongo 都不能很好地处理交易。所以假设你正在构建一个金融交易系统，那么我会告诉你盲目地使用 mysql 作为其 ACID 兼容（阅读 innodb 引擎）。因此，很多这些决定取决于您要完成的任务...

结论：转述自NoSQL

真正要指出的是，如果你被阻止 做一些超级棒的东西，因为你不能选择数据库， 你做错了。如果你知道mysql，就用它。优化时 你实际上需要。像 k/v 商店一样使用它，像 rdbms 一样使用它， 但看在上帝的份上，构建你的杀手级应用！这些都不重要 大多数应用程序。 Facebook 仍然大量使用 MySQL。***使用 MySQL，一个 很多。 FriendFeed 经常使用 MySQL。 NoSQL 是一个很棒的工具，但它 当然不会成为你的竞争优势，也不会 让您的应用变得热门，最重要的是，您的用户不会在意 任何这些。

我将在什么基础上构建下一个应用程序？可能是Postgres。我会用吗 无SQL？可能是。我也可能使用 Hadoop 和 Hive。我可能会保留 平面文件中的所有内容。也许我会开始在 Maglev 上进行黑客攻击。我会用 任何最适合这份工作的东西。如果我需要报告，我不会使用 任何 NoSQL。如果需要缓存，我可能会使用 Tokyo Tyrant。如果我 需要 ACIDity，我不会使用 NoSQL。如果我需要大量计数器，我会使用 雷迪斯。如果我需要交易，我会使用 Postgres。如果我有一吨 单一类型的文档，我可能会使用 Mongo。如果我需要写 每天 10 亿个物体，我可能会使用伏地魔。如果我需要完整 文本搜索，我可能会使用 Solr。如果我需要全文搜索 不稳定的数据，我可能会使用 Sphinx。

Too Funny & too relavent to NOT Post Again - MongoDb is Web Scale

【参考方案2】：

除非您对数据进行大量规范化，否则多个表上的 IO 会成为瓶颈，否则 MySQL 可以正常工作。没有理由仅仅因为大多数人都在使用 mongo 和 node.js.. 来切换。

Mongodb/Couchdb/Orientdb 最适合存储大量“文档”对象。如果您的数据可以适合 RDBMS 模式，则您不需要创建文档。据我所见，创建对象的主要延迟来自于填充数据字段。使用 NoSQL DB，您可以一次性获取所有数据，而在标准化 RDBMS 中，数据字段将从不同来源填充，从而导致轻微延迟。当然，您可以使用缓存来改进它。 如果你想要 RDBMS 的可扩展性，你可以看看 NuoDB。

由于您的后端应用服务器需要可扩展性，因此您还可以研究 vertx.根据基准，它似乎优于节点，但它仍然是非常新的。