Mongodb / Couchdb而不是MySQL(从PHP切换到节点)

我使用后端的PHP / MySQL / Solr和前端的Javascript / jQuery / Backbone完成了我的大部分Web开发工作。

我已经编写了一些Node应用程序,但是使用了MySQL,而不是使用Mongodb / Couchdb,这是很多Node教程/书籍使用的。 你会开始使用Mongo / Couch而不是MySQL,因为大多数开发Node的人都在使用它? MySQL似乎为我工作得很好,我不清楚切换到Mongo / Couch的优势。

现在我开始一个网站,其中“前端”应用程序服务器是PHP / MySQL,并且数字运算服务器在Node中。 我坚持使用PHP来服务“前台”的原因是因为我非常适合在我的PHP框架中开发。

select节点的原因是因为会有大量空闲/等待时间的同时任务以秒为单位。 这必须是高度可扩展的。

将存储在数据库中的东西就像通常的东西,你将存储在MySQL表中

有些事情你需要考虑 –

  1. 缩放是我们搬到mongoDB最重要的原因之一。 分片和复制MongoDB是一件轻而易举的事情。 所以如果你的应用程序需要横向扩展,那么mongoDB就是要走的路。 垂直缩放只能走到尽可能短的硬件限制…再加上在MySQL分拆是一个真正的痛苦。
  2. 其次是数据库模式。 在像我们这样的大多数创业公司,要求和function变化非常迅速。 所以在一段时间内,基于mysql模式的DB可能更像是一种“好习惯”的束缚。 在这种情况下,没有人关心“良好实践”。 所以如果你需要一个无模式的数据库,那么考虑mongoDB。
  3. 所有这一切都有一个免责声明,mongoDB(和其他NoSql解决scheme)是数据库世界中shiny的新玩具。 他们不像MySQL那么成熟。 其中大部分包括mongo都不能很好地处理交易。 所以可以说,你正在build立一个金融交易系统,那么我会告诉你盲目地使用mysql作为符合ACID(读取innodb引擎)的标准。 所以很多这些决定取决于你想要完成的事情

结论: NoSQL的解释

需要指出的是,如果你因为无法select数据库而使得某些超级棒的东西被阻止,那么你就错了。 如果你知道mysql,就使用它。 当你真正需要的时候优化。 使用它像AK / V商店,使用它像一个RDBMS,但为了上帝的缘故, build立你的杀手级应用程序 ! 这对大多数应用程序都无关紧要。 Facebook仍然使用MySQL,很多。 维基百科使用MySQL,很多。 FriendFeed使用MySQL,很多。 NoSQL是一个伟大的工具,但它肯定不会成为你的竞争优势,它不会让你的应用程序变得热门,而且最重要的是, 你的用户不会对这个问题嗤之以鼻

我将如何构build我的下一个应用程序? 可能Postgres。 我会使用NoSQL吗? 也许。 我也可能使用Hadoop和Hive。 我可能会把所有东西都放在平面文件 也许我会开始攻击磁悬浮。 我会使用最好的工作。 如果我需要报告,我不会使用任何NoSQL。 如果我需要caching,我可能会使用东京暴君。 如果我需要ACIDity,我不会使用NoSQL。 如果我需要大量的计数器,我会使用Redis。 如果我需要交易,我会使用Postgres。 如果我有大量单一types的文档,我可能会使用Mongo。 如果我需要每天写10亿个物体,我可能会用Voldemort。 如果我需要全文search,我可能会使用Solr。 如果我需要全文search易失性数据,我可能会使用狮身人面像。

太搞笑了,太相对不要再发布 – MongoDb是Web Scale

在这里输入图像描述

除非你正在严格规范你的数据,使得多个表上的IO成为瓶颈,否则MySQL将正常工作。 没有理由只是因为大多数人使用mongo而使用node.js。

Mongodb / Couchdb / Orientdb最适合存储大量的“文档”对象。 如果您的数据可以适合RDBMS架构,则不需要创build文档。 从我所看到的,在填充数据字段时,创build对象的主要延迟来了。 使用NoSQL DB,您可以一次性获得所有数据,而在规范化的RDBMS中,数据字段将从不同的来源填充,从而导致稍微的延迟。 当然,你可以使用caching来改善。 如果你想在RDBMS中进行可伸缩性,你可以看看NuoDB。

由于您的后端应用程序服务器需要可伸缩性,因此您也可以查看vertx。 根据基准,它似乎超出节点,但它仍然是非常新的。