我想使用前端：主干后端：节点制作像 docs.google.com 这样的应用程序（没有它的 api，完全在我自己的服务器上）
你认为哪个数据库更好？mysql还是mongodb？应该支持良好的可扩展性。我熟悉 mysql 和 php，如果答案是 mysql，我会很高兴。但是我看到的很多教程，他们使用的是mongodb，为什么他们使用没有mysql的mongodb？我应该用什么？
谁能给我一些使用主干、节点、mysql（或mongo）构建的示例应用程序（带有源代码）的链接。或至少应用程序。使用 Node 和 mysql
谢谢
使用 MongoDB，您可以只存储JSON 对象并以完整格式检索它们，因此您实际上不需要 ORM 层，并且来回转换数据所花费的 CPU 时间更少。MongoDB 背后的开发人员还使水平扩展数据库具有更高的优先级，并允许您运行任意 Javascript 代码来预处理 DB 端的数据（允许对数据进行 map-reduce 样式过滤）。
但是您会因为这些收益而损失一些：您无法加入记录。实际上，您存储的 JSON 结构只能通过 SQL 中的连接来完成，但在 MongoDB 中，您的数据只有一种结构，而在 SQL 中，您可以以不同的方式查询并以其他方式更容易地表示您的数据，所以如果您需要对您的数据库进行大量分析，MongoDB 会使这变得更加困难。
在我看来，MongoDB 中的查询语言比 SQL 更“粗糙”，部分原因是它不太熟悉，部分原因是查询功能“感觉”很随意，部分是为了使其成为有效的 JSON，部分是因为字面上有一个做同一件事的几种方法，有些是较旧的方法，它们不如其他方法有用或格式不规则。与 SQL 的简单的基于行的设计相比，数组和子对象类型的复杂性增加了，因此语法必须能够处理对包含您定义的某些值的数组的查询，包含您定义的所有值，仅包含您定义的值，并且不包含您定义的值。同样的区别也适用于对象键及其值，这使得查询语法更难掌握。（虽然我可以看到对极端情况的需求，但$where查询参数，它采用一个在数据的每条记录上运行并返回一个布尔值的 javascript 函数，是一首 Siren 歌曲，因为您可以轻松定义您想要的对象是否返回，但它必须在数据库中的每条记录上运行，不能使用索引。）
所以，这取决于你想做什么，但既然你说它是为了一个谷歌文档克隆，你可能不关心任何表示，但文档表示本身，你可能只会根据文档进行查询ID，文件名称，或所有者的 ID/名称，在查询中没有什么太复杂的。
然后，我会说能够获取用户正在编辑的文档的 JSON 表示，并将其放入数据库并让它自动索引这些重要字段，值得学习新数据库的代价。
我也在为这个选择而苦苦挣扎，看看使用 MongoDB 来执行它不是为它构建的任务所创造的炒作。所以我的 2 美分是：
正如 David 所说，在 MongoDB 中存储和检索分层对象（可能是您的文档）更容易。如果你想存储大于 16Mb 的文档，它会变得更加复杂——MongoDB 的答案是 GridFS。
使用 MySQL 将文档组织在文件夹、组中，跟踪哪个用户拥有哪些文档以及他/她提供了对它们的访问权限肯定更容易 - 您拥有强大的 SQL 查询和连接等优势，内置 EXPLAIN 优化、触发器、函数、存储过程等。 MongoDB 远非如此。
那么是什么阻止您使用 MySQL 来组织文档和 MongoDB 来存储一个由 id 标识的文档集合（或多个集合 - 每个文档类型一个）？在我看来，这是最好的选择，并且在一个应用程序中使用两个数据库确实不是问题。
MySQL 将存储用户、组、文件夹、权限——无论你喜欢什么——并且对于每个文档，它将存储对集合的引用和文档 ID（MongoDB 有一种特殊的格式——DBRefs）。MongoDB会将文档本身存储在集合中，如果它们都小于16MB，或者集合中文档的预览和元数据以及GridFS中的整个文档。
大卫提供了一个很好的答案。有几件事要补充。
对于类似 Google Doc 的功能，MongoDB 提供的灵活性和非常丰富的数据结构感觉更合适。
您可以通过搜索 mongoose、node 和 MongoDB 找到一些很好的示例帖子。
这是一个也使用backbone.js并且看起来不错http://mattkopala.com/blog/2012/02/12/getting-started-with-nodejs/