mongodb 是否适合像 stackoverflow 这样的网站？
最佳答案
简单地说:是的，它可能是。
让我们分解各种页面/功能，看看如何在 MongoDB 中存储/复制它们。
此页面中的全部信息可以存储在questions集合下的单个文档中。这可能包括每个答案的“子文档”，以保持快速检索此页面。
编辑:为@ beagleguy指出，您可以通过这种方式很快达到 4MB 的文档大小限制，因此最好将答案存储在单独的文档中，并通过将 ObjectID 存储在数组中来将它们链接到问题。
votes 可以存储在单独的集合中，其中包含指向问题和投票的用户 的简单链接。一个 db.eval()调用 可以 在添加投票时直接在文档中增加/减少投票计数(尽管它会阻塞所以性能不会很好)，或者 MapReduce可以定期打电话来抵消这项工作。 favourites 的工作方式相同。
诸如“查看”的数字、记录用户的访问时间等通常会使用 modifier operation 来处理。至increment一个柜台。从 v1.3 开始，有一个新的“查找和修改”命令，可以在检索文档时发出更新命令，为您节省额外的调用。
可以使用 MapReduce 收集任何类型的统计数据(例如声誉、徽章、独特标签)并推送到特定的集合。诸如通知之类的东西可以被推送到充当作业队列的另一个集合中，许多工作人员正在监听队列中的新项目(想想徽章通知、自用户上次访问时间以来的新答案等)。
问题页面及其过滤器都可以使用 capped-collections 进行处理，而不是立即查询该数据。
最终，YMMV。与所有工具一样，都有优势和成本。有一些 SO 特性在 RDBMS 中需要大量工作，但在 Mongo 中可以非常简单地处理，反之亦然。
我认为 Mongo 与 RDBMS 相比的主要优势在于无模式方法和复制。在“实时”的基于 RDMBS 的应用程序中定期更改架构可能会很痛苦，如果它大量使用大量数据，甚至是不可能的——这些类型的操作可能会锁定表太久。在 Mongo 中，添加新字段是微不足道的，因为您可能不需要将它们添加到每个文档中。如果您执行相对快速的操作来运行 map/reduce 来更新文档。
在复制方面，Mongo 的优势在于无需暂停数据库即可为从属设备拍摄快照。如果没有这种方法，许多 RDBMS 无法设置复制，这在大型 DB 上会使主服务器停机 很长时间 时间(我在看着你，MySQL!)。这对 StackOverflow 类型的网站来说是一件好事，因为您需要随着时间的推移进行扩展 - 无需在每次需要添加节点时都关闭主节点。
关于mongodb - mongodb 适合像 stackoverflow 这样的网站吗？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/2391204/